[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190904130135.GN9749@gate.crashing.org>
Date: Wed, 4 Sep 2019 08:01:35 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: David Laight <David.Laight@...lab.com>
Cc: "'Nathan Chancellor'" <natechancellor@...il.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
"# 3.4.x" <stable@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Paul Mackerras <paulus@...ba.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp
On Wed, Sep 04, 2019 at 08:16:45AM +0000, David Laight wrote:
> From: Nathan Chancellor [mailto:natechancellor@...il.com]
> > Fair enough so I guess we are back to just outright disabling the
> > warning.
>
> Just disabling the warning won't stop the compiler generating code
> that breaks a 'user' implementation of setjmp().
Yeah. I have a patch (will send in an hour or so) that enables the
"returns_twice" attribute for setjmp (in <asm/setjmp.h>). In testing
(with GCC trunk) it showed no difference in code generation, but
better save than sorry.
It also sets "noreturn" on longjmp, and that *does* help, it saves a
hundred insns or so (all in xmon, no surprise there).
I don't think this will make LLVM shut up about this though. And
technically it is right: the C standard does say that in hosted mode
setjmp is a reserved name and you need to include <setjmp.h> to access
it (not <asm/setjmp.h>).
So why is the kernel compiled as hosted? Does adding -ffreestanding
hurt anything? Is that actually supported on LLVM, on all relevant
versions of it? Does it shut up the warning there (if not, that would
be an LLVM bug)?
Segher
Powered by blists - more mailing lists