Hi,
On Mon, 23 Jun 2014 16:22:13, Eric Botcazou wrote:
>
>> I noticed that several testcases in the GMP-4.3.2 test suite are failing now
>> which did not happen with GCC 4.9.0. I debugged the first one,
>> mpz/convert, and found the file mpn/generic/get_str.c was miscompiled.
>>
>> mpn/get_str.c.132t.dse2:
>> pretmp_183 = (sizetype) chars_per_limb_80;
>> pretmp_184 = -pretmp_183;
>> _23 = chars_per_limb_80 + 4294967295;
>> _68 = (sizetype) _23;
>> _28 = _68 + pretmp_184;
>>
>> mpn/get_str.c.133t.forwprop4:
>> _28 = 4294967295;
>>
>>
>> That is wrong, because chars_per_limb is unsigned, and it is not zero.
>> So the right result should be -1. This makes the loop termination in that
>> function fail.
>
> Can't we compute the right result in this case? 4294967295 is almost -1.
>
Only if we could somehow rule out that chars_per_limb can be zero.
Then we know for sure that unsigned overflow must happen, and
the only possible result would be -1.
But at this time, both -1 and 4294967295 are possible.
What happened before, is this:
int i;
unsigned int chars_per_limb;
i_79 = __gmpn_bases[base_30(D)].chars_per_limb;
chars_per_limb_80 = (unsigned int) i_79;
so how can we know that chars_per_limb is> 0, here?
In this example probably not, only maybe if someone helps
us and adds an assertion (chars_per_limb> 0); then we could
of course exploit that information....
Bernd.
>> The attached patch fixes these regressions, and because the reasoning
>> depends on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning
>> has to be emitted here, at least for widening conversions.
>
> Saturating, floating-point and fixed-point types are already excluded here,
> see the beginning of the function.
>
> --
> Eric Botcazou
