On Fri, May 3, 2013 at 10:46 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Thanks - it's not the first time that GCC hits undefined C code in SPEC CPU. Generally we make sure that a workaround exists, like -fno-strict-overflow. Richard. > Jeff
