On 11/17/15 12:59, Markus Armbruster wrote: > 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
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 <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. > > [...] >
