http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #8 from Agner Fog <agner at agner dot org> 2011-07-24 08:16:39 UTC --- Thanks for your comments. Why is the behavior different for signed and unsigned? The expression (a + 5 < a) is reduced to always false when a is signed, but not when a is unsigned. -Wall produces the warning "assuming signed overflow does not occur when assuming that (X + c) < X is always false" in the above example, but there is no warning when it assumes that abs(a) < 0 is always false. I believe that the behavior of a compiler must be predictable. An ordinary programmer would never predict that the compiler can optimize away an explicit check for overflow, no matter how many C++ textbooks he has read. If the compiler can remove a security check without warning then we have a security issue. To say that the behavior in case of overflow is undefined is not the same as denying that overflow can occur. I think we need a sensible compromise that allows the compiler to e.g. optimize a loop under the assumption that the loop counter doesn't overflow, but doesn't allow it to optimize away an explicit overflow check. I know the compiler can't guess the programmers' intentions, but then we must at least have a warning. Any optimization rule that allows the compiler to optimize away an overflow check without warning is unacceptable in my opinion.
