qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user: Suppress address-of-packed-member w


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH] linux-user: Suppress address-of-packed-member warnings in __get/put_user_e
Date: Tue, 9 Oct 2018 16:57:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

Le 09/10/2018 à 16:52, Peter Maydell a écrit :
> On 9 October 2018 at 12:59, Peter Maydell <address@hidden> wrote:
>> On 5 October 2018 at 17:09, Laurent Vivier <address@hidden> wrote:
>>> Could it be a bug in _Pragma()?
>>
>> I got an f28 VM and can repro this. It looks like the problem
>> only happens when the get_user/put_user stuff is used via some
>> other macro, for some reason -- so the GET_ARG and SET_ARG
>> macros in arm-semi.c and the NEW_AUX_ENT macro in elfload.c
>> cause problems, but less indirect use does not. I'll try to
>> trim this down to a smaller test case somehow...
> 
> I think it is a bug in _Pragma(). I boiled it down to a
> small test case, and tested using the compilers on godbolt.org.
> The test fails with gcc 5, 6, 7 and 8 but works on 4 and on
> gcc trunk.
> 
> Trying to use _Pragma() inside a macro to disable warnings
> seems to be pretty broken. The GCC bugzilla has:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66099
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
> 
> which are various bug reports in this area, with test cases
> which variously are fixed in gcc 8, or fixed not in 8 but
> in trunk, or still broken in trunk. So there isn't a single
> bug here but a cluster of similar ones.
> 
> I think the underlying difficulty is that the compiler decides
> whether to suppress the warning by looking at the source location
> for the warning, and at the source locations of the various
> pragmas, and especially when macro expansion is involved the
> "source location" can be harder to correctly identify.
> 
> I'm not sure if there is some "safe" subset of _Pragma()-in-macro
> use here that will work regardless of compiler version, or if
> we should just give up on it as non-feasible and try to silence
> the warnings some other way.

To keep it simple, and as I have suggested before, perhaps you can use
only the _Pragma() we need to workaround clang bug with clang (#ifde
__clang__)?

Thanks,
Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]