On 05/02/2013 01:55 AM, Richard Biener wrote:
On Wed, May 1, 2013 at 10:26 PM, Jeff Law <l...@redhat.com> wrote:
range_fits_type_p erroneously returns true in cases where the range has
overflowed. So for example, we might have a range [0, +INF(OVF)] and
conclude the range fits in an unsigned type.
This in turn can cause VRP to rewrite a conditional in an unsafe way as seen
by the testcase.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
OK for the trunk?
Hmm, actually when [0, +INF(OVF)] appears then it says that the
range is [0, +INF], but we relied on that no undefined overflow happened
when computing it.
So in fact the value must fit, otherwise the program invoked undefined
behavior.
Which means you should at most _warn_, not disable the transform.
In fact the testcase is invalid:
x1 = *p1;
x2 = (int) x1;
x3 = x2 * 65536;
performs 65531 * 65536 which overflows in type int.
You probably should disable the transform with -fno-strict-overflow,
that is, make sure the testcase works at -O1 -ftree-vrp for example.
I'll check the inputs going into the code in 254.gap; the sequence in
the testcase is effectively the computation that's going awry in 254.gap.
Jeff
