From: Nick Desaulniers <ndesaulniers@google.com> To: Nathan Chancellor <natechancellor@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, LKML <linux-kernel@vger.kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, "# 3.4.x" <stable@vger.kernel.org> Subject: Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp Date: Wed, 28 Aug 2019 11:01:14 -0700 [thread overview] Message-ID: <CAKwvOdmXbYrR6n-cxKt3XxkE4Lmj0sSoZBUtHVb0V2LTUFHmug@mail.gmail.com> (raw) In-Reply-To: <20190828175322.GA121833@archlinux-threadripper> On Wed, Aug 28, 2019 at 10:53 AM Nathan Chancellor <natechancellor@gmail.com> wrote: > > On Wed, Aug 28, 2019 at 11:43:53PM +1000, Michael Ellerman wrote: > > Nathan Chancellor <natechancellor@gmail.com> writes: > > > > > Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when > > > setjmp is used") disabled -Wbuiltin-requires-header because of a warning > > > about the setjmp and longjmp declarations. > > > > > > r367387 in clang added another diagnostic around this, complaining that > > > there is no jmp_buf declaration. > > > > > > In file included from ../arch/powerpc/xmon/xmon.c:47: > > > ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of > > > built-in function 'setjmp' requires the declaration of the 'jmp_buf' > > > type, commonly provided in the header <setjmp.h>. > > > [-Werror,-Wincomplete-setjmp-declaration] > > > extern long setjmp(long *); > > > ^ > > > ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of > > > built-in function 'longjmp' requires the declaration of the 'jmp_buf' > > > type, commonly provided in the header <setjmp.h>. > > > [-Werror,-Wincomplete-setjmp-declaration] > > > extern void longjmp(long *, long); > > > ^ > > > 2 errors generated. > > > > > > Take the same approach as the above commit by disabling the warning for > > > the same reason, we provide our own longjmp/setjmp function. > > > > > > Cc: stable@vger.kernel.org # 4.19+ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/625 > > > Link: https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07 > > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> > > > --- > > > > > > It may be worth using -fno-builtin-setjmp and -fno-builtin-longjmp > > > instead as it makes it clear to clang that we are not using the builtin > > > longjmp and setjmp functions, which I think is why these warnings are > > > appearing (at least according to the commit that introduced this waring). > > > > > > Sample patch: > > > https://github.com/ClangBuiltLinux/linux/issues/625#issuecomment-519251372 > > > > Couldn't we just add those flags to CFLAGS for the whole kernel? Rather > > than making them per-file. > > Yes, I don't think this would be unreasonable. Are you referring to the > cc-disable-warning flags or the -fno-builtin flags? I personally think > the -fno-builtin flags convey to clang what the kernel is intending to > do better than disabling the warnings outright. The `-f` family of flags have dire implications for codegen, I'd really prefer we think long and hard before adding/removing them to suppress warnings. I don't think it's a solution for this particular problem. > > > I mean there's no kernel code that wants to use clang's builtin > > setjmp/longjmp implementation at all right? > > > > cheers > > I did a quick search of the tree and it looks like powerpc and x86/um > are the only architectures that do anything with setjmp/longjmp. x86/um > avoids this by using a define flag to change setjmp to kernel_setjmp: > > arch/um/Makefile: -Dlongjmp=kernel_longjmp -Dsetjmp=kernel_setjmp \ > > Seems like adding those flags should be safe. > > Cheers, > Nathan -- Thanks, ~Nick Desaulniers
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com> To: Nathan Chancellor <natechancellor@gmail.com> Cc: LKML <linux-kernel@vger.kernel.org>, "# 3.4.x" <stable@vger.kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Paul Mackerras <paulus@samba.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp Date: Wed, 28 Aug 2019 11:01:14 -0700 [thread overview] Message-ID: <CAKwvOdmXbYrR6n-cxKt3XxkE4Lmj0sSoZBUtHVb0V2LTUFHmug@mail.gmail.com> (raw) In-Reply-To: <20190828175322.GA121833@archlinux-threadripper> On Wed, Aug 28, 2019 at 10:53 AM Nathan Chancellor <natechancellor@gmail.com> wrote: > > On Wed, Aug 28, 2019 at 11:43:53PM +1000, Michael Ellerman wrote: > > Nathan Chancellor <natechancellor@gmail.com> writes: > > > > > Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when > > > setjmp is used") disabled -Wbuiltin-requires-header because of a warning > > > about the setjmp and longjmp declarations. > > > > > > r367387 in clang added another diagnostic around this, complaining that > > > there is no jmp_buf declaration. > > > > > > In file included from ../arch/powerpc/xmon/xmon.c:47: > > > ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of > > > built-in function 'setjmp' requires the declaration of the 'jmp_buf' > > > type, commonly provided in the header <setjmp.h>. > > > [-Werror,-Wincomplete-setjmp-declaration] > > > extern long setjmp(long *); > > > ^ > > > ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of > > > built-in function 'longjmp' requires the declaration of the 'jmp_buf' > > > type, commonly provided in the header <setjmp.h>. > > > [-Werror,-Wincomplete-setjmp-declaration] > > > extern void longjmp(long *, long); > > > ^ > > > 2 errors generated. > > > > > > Take the same approach as the above commit by disabling the warning for > > > the same reason, we provide our own longjmp/setjmp function. > > > > > > Cc: stable@vger.kernel.org # 4.19+ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/625 > > > Link: https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07 > > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> > > > --- > > > > > > It may be worth using -fno-builtin-setjmp and -fno-builtin-longjmp > > > instead as it makes it clear to clang that we are not using the builtin > > > longjmp and setjmp functions, which I think is why these warnings are > > > appearing (at least according to the commit that introduced this waring). > > > > > > Sample patch: > > > https://github.com/ClangBuiltLinux/linux/issues/625#issuecomment-519251372 > > > > Couldn't we just add those flags to CFLAGS for the whole kernel? Rather > > than making them per-file. > > Yes, I don't think this would be unreasonable. Are you referring to the > cc-disable-warning flags or the -fno-builtin flags? I personally think > the -fno-builtin flags convey to clang what the kernel is intending to > do better than disabling the warnings outright. The `-f` family of flags have dire implications for codegen, I'd really prefer we think long and hard before adding/removing them to suppress warnings. I don't think it's a solution for this particular problem. > > > I mean there's no kernel code that wants to use clang's builtin > > setjmp/longjmp implementation at all right? > > > > cheers > > I did a quick search of the tree and it looks like powerpc and x86/um > are the only architectures that do anything with setjmp/longjmp. x86/um > avoids this by using a define flag to change setjmp to kernel_setjmp: > > arch/um/Makefile: -Dlongjmp=kernel_longjmp -Dsetjmp=kernel_setjmp \ > > Seems like adding those flags should be safe. > > Cheers, > Nathan -- Thanks, ~Nick Desaulniers
next prev parent reply other threads:[~2019-08-28 18:01 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-12 2:32 [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp Nathan Chancellor 2019-08-12 2:32 ` Nathan Chancellor 2019-08-12 5:37 ` Christophe Leroy 2019-08-12 16:55 ` Nathan Chancellor 2019-08-12 16:55 ` Nathan Chancellor 2019-08-12 17:35 ` Nick Desaulniers 2019-08-12 17:35 ` Nick Desaulniers 2019-08-27 0:12 ` Nathan Chancellor 2019-08-27 0:12 ` Nathan Chancellor 2019-08-28 13:43 ` Michael Ellerman 2019-08-28 13:43 ` Michael Ellerman 2019-08-28 17:53 ` Nathan Chancellor 2019-08-28 17:53 ` Nathan Chancellor 2019-08-28 18:01 ` Nick Desaulniers [this message] 2019-08-28 18:01 ` Nick Desaulniers 2019-08-28 18:45 ` Nathan Chancellor 2019-08-28 18:45 ` Nathan Chancellor 2019-08-28 22:16 ` Nick Desaulniers 2019-08-28 22:16 ` Nick Desaulniers 2019-08-29 8:32 ` Segher Boessenkool 2019-08-29 8:32 ` Segher Boessenkool 2019-08-29 9:59 ` David Laight 2019-09-03 5:55 ` Nathan Chancellor 2019-09-03 5:55 ` Nathan Chancellor 2019-09-03 19:31 ` Segher Boessenkool 2019-09-03 19:31 ` Segher Boessenkool 2019-09-04 0:24 ` Nathan Chancellor 2019-09-04 0:24 ` Nathan Chancellor 2019-09-04 8:16 ` David Laight 2019-09-04 13:01 ` Segher Boessenkool 2019-09-04 13:01 ` Segher Boessenkool 2019-09-04 23:15 ` Nathan Chancellor 2019-09-04 23:15 ` Nathan Chancellor 2019-09-10 18:30 ` Michael Ellerman 2019-09-10 18:30 ` Michael Ellerman 2019-09-10 18:37 ` Nathan Chancellor 2019-09-10 18:37 ` Nathan Chancellor
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAKwvOdmXbYrR6n-cxKt3XxkE4Lmj0sSoZBUtHVb0V2LTUFHmug@mail.gmail.com \ --to=ndesaulniers@google.com \ --cc=benh@kernel.crashing.org \ --cc=clang-built-linux@googlegroups.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=natechancellor@gmail.com \ --cc=paulus@samba.org \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.