This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix fallout from VRP strict-overflow changes
On Mon, 21 Aug 2017, Martin Sebor wrote:
> On 08/21/2017 01:51 AM, Richard Biener wrote:
> > On Sat, 19 Aug 2017, Andreas Schwab wrote:
> >
> > > On Aug 17 2017, Richard Biener <rguenther@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.
Well, there will always be missed optimizations so the correct fix
for this is to not warn about memcpy with size == 0.
Sure, folding can be improved but the get_size_range code is broken
and has to be fixed.
Richard.