On 27 April 2017 at 17:32, Jeff Law <l...@redhat.com> wrote:
> 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
Hi,
This patch (r247495) causes regressions in fortran on aarch64/arm:
- PASS now FAIL [PASS => FAIL]:
Executed from: gfortran.dg/dg.exp
gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times
original "_gfortran_caf_lock \\(caf_token.., \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[0\\].lbound\\) \\+
\\(integer\\(kind=4\\)\\) MAX_EXPR <\\(parm...dim\\[0\\].ubound -
parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[1\\].lbound\\), 0, 0B, &ii, 0B,
0\\);|_gfortran_caf_lock \\(caf_token.1, \\(3 -
parm...dim\\[0\\].lbound\\) \\+ MAX_EXPR <\\(parm...dim\\[0\\].ubound
- parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
parm...dim\\[1\\].lbound\\), 0, 0B, &ii, 0B, 0\\);" 1
gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times
original "_gfortran_caf_unlock \\(caf_token.., \\(2 -
\\(integer\\(kind=4\\)\\) parm...dim\\[0\\].lbound\\) \\+
\\(integer\\(kind=4\\)\\) MAX_EXPR <\\(parm...dim\\[0\\].ubound -
parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[1\\].lbound\\), 0, &ii, 0B,
0\\);|_gfortran_caf_unlock \\(caf_token.., \\(2 -
parm...dim\\[0\\].lbound\\) \\+ MAX_EXPR <\\(parm...dim\\[0\\].ubound
- parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
parm...dim\\[1\\].lbound\\), 0, &ii, 0B, 0\\);" 1
Thanks,
Christophe
