This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is it OK that gcc optimizes away overflow check?

On Sat, Jul 23, 2011 at 4:13 PM, Agner Fog <> wrote:
> 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
>> >  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 over-pedantic.

Its really too bad that GCC does not offer something for overflow and
carry. There's been a couple of feature requests for overflow and
carry testing when the CPU supports it, but I don't believe its gained
any momentum (what does that say about secure programming practices?):


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]