PATCH RFC: -Wstrict-overflow

[Alexandre Oliva]

On Feb  5, 2007, Ian Lance Taylor <iant@google.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:

>> Erhm...  I'd rather the warning was something along the lines of
>> "assuming absence of signed overflow" instead of "assuming signed
>> overflow is undefined", because the former is more meaningful, but now
>> I can't quite figure out whether this is indeed the case for the
>> snippet above.

> I don't know, "assuming signed overflow is undefined" seems right to
> me.

What disturbs me is that you don't have to *assume* that, it is
*true*.  "taking advantage of undefinedness of signed overflow" would
fix that, but it's too verbose and just as confusing IMHO.

> I could change it to "assuming signed overflow does not occur", I
> suppose.

This sounds much better to me.

> The subtraction is irrelevant here.

Err...  Surely you're not telling me that the code below invokes
undefined behavior:

int f(int x, int y) { return x - y; }
int main() { return f(INT_MIN, INT_MIN); }

Because if you say the subtraction is irrelevant, it appears to me
that you're saying the compiler is permitted to convert x-y to x+(-y)
and trap if -y overflows.  I wouldn't have thought so.

I don't see any indication in C99-TC2 that this would be so.  In fact,
what I see (6.5.6/6) is an indication that it should *not* be so.
This transformation x-y=>x+(-y) is precisely based on the argument
I've exposed in my previous message, that even though it technically
may introduce overflow, the compiler can still perform it when it
knows the end result is the same and the overflow won't be visible.

> In this case the transformation
> is from - (A / B) to (A / - B).

Given 6.5.6/6, no, this is not what the transformation is about.  What
the user wrote was C - (A / B), not C + (- (A / B)), so assuming it
was the latter and propagating the overflow on the grounds that the
original program would trigger it is faulty, because the original
program wouldn't.  The first transformation is only valid when it does
not visibly affect the result, but if we proceed to the second
transformation, then it does.  So the transformation is invalid,
should be avoided, and the warning is undeserved.

> This shows a general principle with -Wstrict-overflow: we warn when we
> make any transformation which would not be permitted if we were using
> -fwrapv.

I guess this warning has exposed a bug in the compiler, then?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}