Re: [PATCH] Remove -fstrict-overflow, default to undefined signed integer and pointer overflow

[Jeff Law <law@redhat.com>]

On 04/26/2017 05:31 AM, Richard Biener wrote:
> 
> The following removes the third state we had apart from signed integer
> overflow wrapping and being undefined.  It makes signed integer overflow
> undefined, consistently at all optimization levels.  -fno-strict-overflow
> stays as a backward compatible way to avoid optimizations that rely on
> signed integer overflow being undefined by making it wrapping
> (this is also the reason of using !flag_wrapv in
> POINTER_TYPE_OVERFLOW_UNDEFINED rather than a new option, for now).
> 
> Surprisingly there's no UBSAN integer overflow testsuite fallout,
> foldings that happen before instrumentation (which is done after
> into-SSA) and rely on signed integer overflow being undefined will
> cause false negatives.  If that turns out to be a problem the
> flag_strict_overflow flag can be re-introduced (not that this would
> be my preference) and it can be unset after UBSAN instrumentation
> is finished.
> 
> The main motivation for aliasing -fstrict-overflow to -f[no-]wrapv
> is that with -fno-strict-overflow (and thus -O1 at the moment) you get
> the worst of both worlds, you can't optimize based on the undefinedness
> but you also cannot rely on wrapping behavior (to know that
> re-association will not introduce undefined behavior).  Using -fwrapv
> for -fno-strict-overflow makes it clear what the semantics are.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> I opened PR80525 for the appearant mishandling of (a + 1) && (a + 1)
> with -Wlogical-op when overflow is undefined.
> 
> If there are no further comments I plan to install this after 7.1
> is released.  I consider the Ada FE change obvious.
> 
> The next step is to get rid of all that ugly -Wstrict-overflow code
> in VRP.  strict-overflow warnings from folding were already
> detoriating with moving stuff to match.pd where it isn't easy to
> preserve those.  Ripping those out can be done later, it's not
> blocking other stuff, and eventually somebody picks up -Wstrict-overflow
> to warn for some cases from the FEs.
> 
> changes.html/porting_to.html will need to have instructions how to
> use ubsan to get at the real problems in code.
This all sounds good to me.

jeff