[Bug c/49820] Explicit check for integer negative after abs optimized away

["agner at agner dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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.