Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

[Jeff Law <law at redhat dot com>]

On 01/19/2017 05:45 AM, Richard Biener wrote:
> On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> > In the attached testcase, we have a clearly bounded case of alloca which is
> > being incorrectly reported:
> >
> > void g (int *p, int *q)
> > {
> >    size_t n = (size_t)(p - q);
> >
> >    if (n < 10)
> >      f (__builtin_alloca (n));
> > }
> >
> > The problem is that VRP gives us an anti-range for `n' which may be out of
> > range:
> >
> >   # RANGE ~[2305843009213693952, 16140901064495857663]
> >    n_9 = (long unsigned int) _4;
> >
> > We do a less than stellar job with casts and VR_ANTI_RANGE's, mostly because
> > we're trying various heuristics to make up for the fact that we have crappy
> > range info from VRP.  More specifically, we're basically punting on an
> > VR_ANTI_RANGE and ignoring that the casted result (n_9) has a bound later
> > on.
> >
> > Luckily, we already have code to check simple ranges coming into the alloca
> > by looking into all the basic blocks feeding it.  The attached patch delays
> > the final decision on anti ranges until we have examined the basic blocks
> > and determined for that we are definitely out of range.
> >
> > I expect all this to disappear with Andrew's upcoming range info overhaul.
> >
> > OK for trunk?
>
> I _really_ wonder why all the range consuming warnings are not emitted
> from VRP itself (like we do for -Warray-bounds).  There we'd still see
> a range for the argument derived from the if () rather than needing to
> do our own mini-VRP from the needessly "incomplete" range-info on
> SSA vars.
Blame me.

My thinking was that the warnings themselves are just part of what we 
want to be doing.  We ought to be warning *and* doing erroneous path 
isolation when we find these out of bounds situations.  I felt that VRP 
was already complex and big enough that adding the additional code to do 
the path specific bounds checking and path isolation wasn't appropriate.

The downside is that we lose a lot of valuable information when we leave 
VRP -- essentially what's left attached to a given SSA_NAME is a 
conservative range that applies in all contexts where the SSA_NAME is 
used.  And that is usually too imprecise to give the warnings we want.

jeff