Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

[hpa]

On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke <mka@xxxxxxxxxxxx> wrote:
>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@xxxxxxxxx ha dit:
>> >>
>> >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson
><md@xxxxxxxxxx> 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@xxxxxxxxxx>
>> >>>> ---
>> >>>> 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

We shouldn't, unless it will actively break non-clang builds...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.