On 08/21/2017 01:51 AM, Richard Biener wrote:
On Sat, 19 Aug 2017, Andreas Schwab wrote:
On Aug 17 2017, Richard Biener <rguent...@suse.de> wrote:
I was notifed I broke proper handling of undefined overflow in
multiplicative ops handling. The following resurrects previous
behavior (and adds a testcase).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
This breaks gfortran.dg/alloc_comp_auto_array_2.f90 on aarch64 with
-mabi=ilp32 (only for -O3):
FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g (test for excess errors)
Excess errors:
/opt/gcc/gcc-20170818/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90:33:0:
Warning: '__builtin_memcpy' specified size between 2147483648 and 4294967295
exceeds maximum object size 2147483647 [-Wstringop-overflow=]
I believe this is an issue that went latent when I broke VRP earlier.
I have opened PR81908, will amend with some initial analysis.
FWIW, the core of the problem is that the warning tends to either
expose limitations in optimizations that were not written to make
use of range information, or indicate additional optimization
opportunities due to range information. In this case, since
the only valid value in the range the memcpy argument is in (i.e.,
~[0, INT_MAX]) is zero, the call could be eliminated. But this
isn't noticed by any pass until the expander checks the call for
validity.
It seems to me that this could be handled by enhancing gimple-fold
in two ways: 1) fold arguments whose range contains only one valid
value into constants, and 2) transform calls with one or more
arguments entirely in invalid ranges into __builtin_unreachable.
I have been thinking prototyping this solution for a while but
haven't gotten around to it yet so I can't say what problems it
might run into.
Martin
