Re: [Qemu-devel] [PATCH for 2.5] QEMU does not care about left shifts of signed negative values

[Laszlo Ersek <lersek@redhat.com>]

On 11/17/15 12:59, Markus Armbruster wrote:
> Laszlo Ersek <lersek@redhat.com> writes:
> 
>> On 11/17/15 11:28, Paolo Bonzini wrote:
>>>
>>>
>>> On 17/11/2015 11:19, Peter Maydell wrote:
>>>> I think we should only take this patch if you can get a cast-iron
>>>> guarantee from both clang and gcc that they will never use this
>>>> UB to drive optimizations. As you say gcc already say this more or
>>>> less, but clang doesn't, and if they're warning about it that to
>>>> me suggests that they will feel freer to rely on the UB in future.
>>>
>>> If and when this happens we will add "-fno-strict-overflow" for clang,
>>> just like we are using "-fno-strict-aliasing" already.
>>
>> How about adding "-fwrapv -fno-strict-overflow" right now? (Spelling out
>> the latter of those explicitly for pointer arithmetic.)
> 
> One of them, not both.
> 
> Quote gcc manual:
> 
>     Using -fwrapv means that integer signed overflow is fully defined:
>     it wraps.  When -fwrapv is used, there is no difference between
>     -fstrict-overflow and -fno-strict-overflow for integers.  With
>     -fwrapv certain types of overflow are permitted.  For example, if
>     the compiler gets an overflow when doing arithmetic on constants,
>     the overflowed value can still be used with -fwrapv, but not
>     otherwise.
> 
> https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html#index-fstrict-overflow-1050
> 
> For what it's worth, the kernel uses -fno-strict-overflow
> -fno-strict-aliasing.  It doesn't use -fwrapv.  If optimization is good
> enough for the kernel, it's probably good enough for us.  I recommend to
> follow the kernel's lead here.
> 
> Relevant kernel commits:
> 
> commit a137802ee839ace40079bebde24cfb416f73208a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Sun Jul 12 11:25:04 2009 -0700
> 
>     Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x

OMG.

I guess "whatever works" then. :/

Laszlo

>     
>     This causes kernel images that don't run init to completion with certain
>     broken gcc versions.
>     
>     This fixes kernel bugzilla entry:
>     	http://bugzilla.kernel.org/show_bug.cgi?id=13012
>     
>     I suspect the gcc problem is this:
>     	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
>     
>     Fix the problem by using the -fno-strict-overflow flag instead, which
>     not only does not exist in the known-to-be-broken versions of gcc (it
>     was introduced later than fwrapv), but seems to be much less disturbing
>     to gcc too: the difference in the generated code by -fno-strict-overflow
>     are smaller (compared to using neither flag) than when using -fwrapv.
>     
>     Reported-by: Barry K. Nathan <barryn@pobox.com>
>     Pushed-by: Frans Pop <elendil@planet.nl>
>     Cc: Andrew Morton <akpm@linux-foundation.org>
>     Cc: stable@kernel.org
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> commit 68df3755e383e6fecf2354a67b08f92f18536594
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Mar 19 11:10:17 2009 -0700
> 
>     Add '-fwrapv' to gcc CFLAGS
>     
>     This makes sure that gcc doesn't try to optimize away wrapping
>     arithmetic, which the kernel occasionally uses for overflow testing, ie
>     things like
>     
>     	if (ptr + offset < ptr)
>     
>     which technically is undefined for non-unsigned types. See
>     
>     	http://bugzilla.kernel.org/show_bug.cgi?id=12597
>     
>     for details.
>     
>     Not all versions of gcc support it, so we need to make it conditional
>     (it looks like it was introduced in gcc-3.4).
>     
>     Reminded-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> I don't think we care for gcc 4.1.x anymore, but the kernels long use of
> -fno-strict-overflow has provided substantial testing, which -fwrapv may
> not have.
> 
> [...]
>