On Wed, Sep 04, 2019 at 08:16:45AM +0000, David Laight wrote:
From: Nathan Chancellor [mailto:natechancellor@gmail.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
On Wed, Sep 04, 2019 at 08:01:35AM -0500, Segher Boessenkool wrote:
On Wed, Sep 04, 2019 at 08:16:45AM +0000, David Laight wrote:
From: Nathan Chancellor [mailto:natechancellor@gmail.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>).
It does not fix the warning, I tested your patch.
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)?
It does fix this warning because -ffreestanding implies -fno-builtin, which also solves the warning. LLVM has supported -ffreestanding since at least 3.0.0. There are some parts of the kernel that are compiled with this and it probably should be used in more places but it sounds like there might be some good codegen improvements that are disabled with it:
https://lore.kernel.org/lkml/CAHk-=wi-epJZfBHDbKKDZ64us7WkF=LpUfhvYBmZSteO8Q...
Cheers, Nathan
Nathan Chancellor natechancellor@gmail.com writes:
On Wed, Sep 04, 2019 at 08:01:35AM -0500, Segher Boessenkool wrote:
On Wed, Sep 04, 2019 at 08:16:45AM +0000, David Laight wrote:
From: Nathan Chancellor [mailto:natechancellor@gmail.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>).
It does not fix the warning, I tested your patch.
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)?
It does fix this warning because -ffreestanding implies -fno-builtin, which also solves the warning. LLVM has supported -ffreestanding since at least 3.0.0. There are some parts of the kernel that are compiled with this and it probably should be used in more places but it sounds like there might be some good codegen improvements that are disabled with it:
https://lore.kernel.org/lkml/CAHk-=wi-epJZfBHDbKKDZ64us7WkF=LpUfhvYBmZSteO8Q...
For xmon.c and crash.c I think using -ffreestanding would be fine. They're both crash/debug code, so we don't care about minor optimisation differences. If anything we don't want the compiler being too clever when generating that code.
cheers
On Wed, Sep 11, 2019 at 04:30:38AM +1000, Michael Ellerman wrote:
Nathan Chancellor natechancellor@gmail.com writes:
On Wed, Sep 04, 2019 at 08:01:35AM -0500, Segher Boessenkool wrote:
On Wed, Sep 04, 2019 at 08:16:45AM +0000, David Laight wrote:
From: Nathan Chancellor [mailto:natechancellor@gmail.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>).
It does not fix the warning, I tested your patch.
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)?
It does fix this warning because -ffreestanding implies -fno-builtin, which also solves the warning. LLVM has supported -ffreestanding since at least 3.0.0. There are some parts of the kernel that are compiled with this and it probably should be used in more places but it sounds like there might be some good codegen improvements that are disabled with it:
https://lore.kernel.org/lkml/CAHk-=wi-epJZfBHDbKKDZ64us7WkF=LpUfhvYBmZSteO8Q...
For xmon.c and crash.c I think using -ffreestanding would be fine. They're both crash/debug code, so we don't care about minor optimisation differences. If anything we don't want the compiler being too clever when generating that code.
cheers
I will send a v2 later today along with another patch to fix this warning and another build error.
Cheers, Nathan
linux-stable-mirror@lists.linaro.org
-
Michael Ellerman -
Nathan Chancellor -
Segher Boessenkool