------- Comment #13 from rguenth at gcc dot gnu dot org 2006-02-28 17:21 ------- The following
----------- Only the edge from block #14 is executable, so the result of the PHI will be equivalent to the current range for last_15. The range we record is [0, 0x7fffffff]. We then proceed to the uses of last_148. One of which is: lastD.2483_86 = lastD.2483_148 + 1; Now for the first "oddity". If we look at the underlying type for last we have a type "natural___XDLU_0__2147483647". What's interesting about it is that it has a 32bit type precision, but the min/max values only specify 31 bits. ie, the min/max values are 0, 0x7fffffff. So anyway, we proceed to add the current range for last_148 [0, 0x7fffffff] to the constant 1. This results in [1, 0x80000000]. Second oddity. This is clearly outside the type's min/max values, but because the value is inside the type's precision, no overflow is signaled and no bits are zero'd out. ----------- sounds odd - adding 1 to the range [0, 0x7fffffff] for a type with the said min/max value should result in [1, 0x7fffffff], not [1, 0x80000000]. Why is the resulting range not clipped to the types min/max value? I can see no difference with this "special" case specifying 31bit precision to any other "non-special" min/max range like [5, 8]. But I must miss something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
