Messages in this thread | | | Date | Thu, 13 Apr 2017 17:23:35 -0700 | From | Matthias Kaehlcke <> | Subject | Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses |
| |
El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit:
> On 04/13/17 16:14, Matthias Kaehlcke wrote: > > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit: > > > >> El Fri, Mar 17, 2017 at 04:50:19PM -0700 hpa@zytor.com ha dit: > >> > >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson <md@google.com> wrote: > >>>> Suppress clang warnings about potential unaliged accesses > >>>> to members in packed structs. This gets rid of almost 10,000 > >>>> warnings about accesses to the ring 0 stack pointer in the TSS. > >>>> > >>>> Signed-off-by: Michael Davidson <md@google.com> > >>>> --- > >>>> arch/x86/Makefile | 5 +++++ > >>>> 1 file changed, 5 insertions(+) > >>>> > >>>> diff --git a/arch/x86/Makefile b/arch/x86/Makefile > >>>> index 894a8d18bf97..7f21703c475d 100644 > >>>> --- a/arch/x86/Makefile > >>>> +++ b/arch/x86/Makefile > >>>> @@ -128,6 +128,11 @@ endif > >>>> KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args) > >>>> endif > >>>> > >>>> +ifeq ($(cc-name),clang) > >>>> +# Suppress clang warnings about potential unaligned accesses. > >>>> +KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) > >>>> +endif > >>>> + > >>>> ifdef CONFIG_X86_X32 > >>>> x32_ld_ok := $(call try-run,\ > >>>> /bin/echo -e '1: .quad 1b' | \ > >>> > >>> Why conditional on clang? > >> > >> My understanding is that this warning is clang specific, it is not > >> listed on https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > Actually this warning affects other platforms besides x86 > > (e.g. arm64), I'll submit a patch that disables the warning on all > > platforms. > > > > Drop the ifeq ($(cc-name),clang). > > You should assume that if you have to add one of those ifeq's then you > are doing something fundamentally wrong.
Thanks, however in the case of the global Makefile it seems we should put it inside the already existing clang section:
http://lxr.free-electrons.com/source/Makefile#L692
Cheers
Matthias
| |