This is the mail archive of the
mailing list for the GCC project.
Is it OK that gcc optimizes away overflow check?
- From: Agner Fog <agner at agner dot org>
- To: gcc-help at gcc dot gnu dot org
- Date: Sat, 23 Jul 2011 22:13:38 +0200
- Subject: Is it OK that gcc optimizes away overflow check?
I have a program where I check for integer overflow. The program failed,
and I found that gcc has optimized away the overflow check. I filed a
bug report and got the answer:
Integer overflow is undefined. You have to check before the fact, or compile( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820 )
> with -fwrapv.
I disagree for several reasons:
1). It is often easier and more logical to check for overflow after it
happens than before. It can be quite complicated to write a code that
predicts an overflow before it happens, in a portable way that works
with all integer sizes. Checking for overflow after it happens is the
only way that is sure to work in a hypothetical system that uses
something else than 2's complement representation.
2). This is a security problem. It takes a very twisted mind to predict
that your code is not safe when you are actually checking for overflow.
3). I think that you are interpreting the C/C++ standard in an
over-pedantic way. There are good reasons why the standard says that the
behavior in case of integer overflow is undefined. 2's complement
wrap-around is not the only possible behavior in case of overflow. Other
possibilities are: saturate, signed-magnitude wrap-around, reserve a bit
pattern for overflow, throw an exception. If a future implementation
uses internal floating point representation for integers then an
overflow might variously cause loss of precision, INF, NAN, or throw an
exception. I guess this is what is meant when the standard says the
behavior is undefined. What the gcc compiler is doing is practically
denying the existence of overflow (
) to the point where it can optimize away an explicit check for
overflow. I refuse to believe that this is what the standard-writers
intended. There must be a sensible compromize that allows the optimizer
to make certain assumptions that rely on overflow not occurring without
going to the extreme of optimizing away an overflow check.
4). The bug in my case disappears if I compile with -fwrapv or
-fno-strict-overflow or without -O2, but this is not my point. My point
is that gcc should be useful to a programmer with average skills.
5). I have tested many different C++ compilers, and gcc turned out to be
the one that optimizes best. You guys are doing a fantastic job! Gcc has
the potential to beat the expensive commercial compilers. But one
obstackle to its use is that it has a well-deserved reputation for being