Laszlo Ersek <ler...@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 <torva...@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
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 <bar...@pobox.com>
Pushed-by: Frans Pop <elen...@planet.nl>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
commit 68df3755e383e6fecf2354a67b08f92f18536594
Author: Linus Torvalds <torva...@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 <a...@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torva...@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.
[...]
