http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999
--- Comment #13 from Paulo J. Matos <pa...@matos-sorge.com> ---
(In reply to Richard Biener from comment #12)
>
> Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
> i++ is really i = (short)((int) i + 1) and thus only the operation in
> type 'int' is known to not overflow and thus the IV in short _can_
> overflow and the loop can loop infinitely for example for loopCount
> == SHORT_MAX + 1.
>
> The fix to SCEV analysis was to still be able to analyze the evolution at
> all.
>
> The testcase is simply very badly written (unsigned short upper bound,
> signed short IV and IV comparison against upper bound in signed int).
I thought any signed operation cannot overflow, independently on its width,
therefore (short) (int + 1) shouldn't overflow.
I agree with you on the testcase, however, that's taken from customer code and
it's even if badly written, it's acceptable C. GCC 4.5.4 generates the scalar
evolution for the integer variable: {1, +, 1}_1 without the casts (therefore a
simple_iv). This allows GCC to use an int for an IV which helps discard the
sign extend in the loop body and later on allows the zero overhead loop being
generated. This case happens again and again and causes serious performance
regression on customer code.
