Re: PATCH RFC: -fstrict-overflow

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:

I'll restate your bullet points more vigorously.  I'll also say things
as statements of fact that are perhaps just my own opinions as to what
these things ought to mean.  Such statements are not meant as edicts;
it's just easier than saying "I think" everywhere.

> * signed overflow wraps (flag_wrapv)

This is both an assumption and a promise: the compiler assumes that
signed operations wrap when arithmetic operations are performed in
hardware, and promises to implement those same semantics at the language
level.  So, for example, constant-folding "INT_MAX + 1" is guaranteed to
give you INT_MIN.  In other words, this is a variant of the language in
which signed arithmetic has the LIA-1 semantics.

> * signed overflow traps (flag_trapv)

Here, we still make a promise, but not an assumption.  The compiler
promises that any overflow will result in a trap.  This is a variant of
the language in which signed arithmetic has defined semantics: it causes
a trap.  (I don't know if we implement this entirely consistently; for
exmaple, I don't know if constant-folding "INT_MAX + 1" is a
compile-time error in this case.)

> * can't assume anything about signed overflow--must let code which may
>   overflow stand as written (flag_wrapv || !flag_strict_overflow)

This is also a promise, but not an assumption.  The compiler promises
that it won't optimize on the basis that signed overflow cannot happen,
but it also doesn't promise that overflow will have any particular
behavior.  For example, on a 1's-complement machine, we could still use
an ordinary add instruction, without worrying about the fact that
INT_MAX + 1 might not have the LIA-1 value.  (In contrast, with -fwrapv,
we'd have to do something special.)

> * may assume that signed overflow is undefined (!flag_wrapv &&
>   flag_strict_overflow)

This is an assumption, but not a promise.  The compiler assumes that
signed overflow is undefined, and it is free to optimize on that basis.
 So, "if (i + 1 < i) foo();" can be optimized away completely, since we
can assume that overflow does not occur.

> It's not clear to me how -ftrapv interacts with signed overflow
> assumptions.  Does -ftrapv mean that signed overflow is undefined?  Or
> does it mean that we may not touch any operation that may overflow?

I suspect -ftrapv is useful for languages that issue exceptions on
overflow.  It does not mean that signed overflow is undefined; rather it
means that is defined, and traps.  So, we must not optimize away "if (i
+ 1 < i) foo();" entirely, but instead can change it into "if (i + 1
overflows) __builtin_trap();".  (We can still optimize away the call to
foo, since either we trap, or i + 1 > i.)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713