RE: x86 failure on loop reversal

[Kaz Kylheku <kaz at cafe dot net>]

On Thursday, April 02, 1998 5:13 PM, Joern Rennecke 
[SMTP:amylaar@cygnus.co.uk] wrote:
> The appended tests fails for egcs at -O2.  This is a synthetic test to
> demonstrate a bug I found while looking for some possible improvements
> to check_dbra_loop: when the initial value is normalized, an overflow
> can occur.
> I suggest that if we did a normalisation that results in a negative initial
> value, we change the comparison into an unsigned one.
> Actually, we could do this change always when we erverse the loop, and then
> we could do away with the NONNEG note.  However, changing a signed compare
> into an unsigned compare might fail sometimes (depending on how well we
> can grok the RTL and what the target accepts), so it is better not to have
> to rely on this.
>
> int
> f()
> {
>   int j = 1;
>   int i;
>   for (i = -0x80000000; i < 0x60000000; i += 0x10000000) j <<= 1;
>   return j;
> }

Could you explain in more detail what you are trying to demonstrate?

Assuming 32 bit, two's complement longs, the constant 0x80000000 is simply out
of the range of the long type, which is -0x80000000 to 0x7FFFFFFF. The sign is
not part of the integral constant, what you have is an out-of-range positive 
constant
that is negated. I don't have my copy of the C standard handy today, but I 
would
guess that the effect of writing an out-of-range integral constant is 
undefined.

To create a constant expression which evaluates to the most negative long
value (assuming, again, 32 bit, two's complement), you must write:

	-0x7FFFFFFF - 1

This value has no additive inverse that is representable in a long, and so 
cannot
be formed by negating a positive constant.