On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez <al...@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.
Can you explain why the range info is only available in VRP and
not outside, via the get_range_info() API? It sounds as though
the API shouldn't be relied on (it was virtually unused before
GCC 7).
To answer your question, the gimple-ssa-sprintf pass that depends
heavily on ranges would also benefit from having access to the data
computed in the strlen pass that's not available outside it.
The -Wstringop-overflow and -Walloc-size-larger-than warnings depend
on both VRP and tree-object-size.
I have been thinking about how to integrate these passes in GCC 8
to improve the overall quality. (By integrating I don't necessarily
mean merging the code but rather having them share data or be able
to make calls into one another.)
I'd be very interested in your thoughts on this.
Thanks
Martin
