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

[Ian Lance Taylor <iant at google dot com>]

Agner Fog <agner@agner.org> writes:

> On 26-07-2011 16:43, Ian Lance Taylor wrote:
>> int f (int i) { return abs (i) < 0; } 
>
>> with -O2 -Wstrict-overflow I see this warning: foo.c:2: warning:
>> assuming signed overflow does not occur when simplifying comparison
>> of absolute value and zero So I think the compiler does warn about
>> optimizing that comparison away. 
> You are right. I used -Wall. Unfortunately, -Wall sets
> -Wstrict-overflow=1 and you need |-Wstrict-overflow=2 to catch the abs
> example. Too bad that you can't even rely on -Wall to catch such a
> serious problem. I don't see why a+1<a = false should have a different
> warning level from abs(a)<0 = false.

It is uncommon to simply write abs(a) < 0.  It is more common to use
abs(a) in an expression where the compiler can apply an optimization by
assuming that abs(a) is always positive.  It's not clear that all such
cases deserve a warning with -Wall.  The general idea of -Wall is that
it should issue warnings which apply to all code written by all
programmers.  While -Wall may issue false positives, it should only do
so when the code is easy to rewrite to avoid the warning.  I don't think
implicit assumptions that abs(a) is positive rise to that level.  I
concede that there are reasonable counterarguments here.  Arguing about
which warnings should be issued at which levels is a matter of opinion,
not a matter of fact.

In any case, I think the root of your different opinion is one we've
touched on before: you seem to be implicitly assuming that all C/C++
programmers should be security conscious.  I am implicitly assuming that
the choice to use C/C++ means that the compiler should default to
trusting the programmer.  The compiler offers options here, such as
-Wstrict-overflow, for those who want them, but the default is to trust
the programmer.  I think that that default behaviour is closer to the
so-called spirit of C.


> I think that there is a big difference between optimizing a loop with
> an induction variable, as you mention, and optimizing away a
> branch. In a simple for-loop with i++, it is unlikely that the
> programmer intended any wrap-around. But if there is a branch or loop
> that can be optimized away completely, then it is either violating the
> programmer's intentions or the programmer has made a logical error. A
> warning would be in place in either case. In other words, there is a
> difference between (1) "ignoring overflow allows us to optimize an
> arithmetic expression or an induction variable", and (2) "ignoring
> overflow allows us to optimize away a branch". The latter situation
> should be regarded as more serious and therefore give a warning at a
> lower warning-level. Then we would be more likely to catch the
> situation where an intended overflow check is optimized away. I wonder
> if it is possible to make such a distinction in the compiler?

It is very difficult to make this sort of distinction in the compiler,
because these warnings are issued after many optimizations have already
been applied.  You must also consider the effect of preprocessor macros
here: many C/C++ macros are written with the intention that the compiler
simplify them.

However, I would not go so far as to say that the distinction you draw
is impossible, and I would encourage you to experiment to see if it
possible to distinguish these cases in the compiler.

Ian