On 01/19/2017 05:17 AM, Aldy Hernandez 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?
Yes this is another case where we're hoping that Andrew's work can help
significantly. The recorded range for n_9 is the range that appplies
over the entire function, when we really want the range for n_9 that
occurs within the TRUE arm of the conditional.
jeff
