Re: [RFA][PATCH] Fix tree-optimization/57124

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, May 3, 2013 at 10:46 PM, Jeff Law <law@redhat.com> wrote:
> On 05/02/2013 01:55 AM, Richard Biener wrote:
>>
>> On Wed, May 1, 2013 at 10:26 PM, Jeff Law <law@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