[PATCH] Document arithmetic overflow semantics

[Joe Buck]

I wrote:

>     In C, it is frequently the case that defining the overflow behavior of
>     signed integer in this way makes more optimizations possible.  For one
>     thing, it makes addition and multiplication associative.  Without such
>     an assumption, you can't turn (a+b)+c into a+(b+c), because the overflows
>     might be different.

On Thu, Feb 13, 2003 at 11:06:39AM -0500, Richard Kenner wrote:
> True, but there are an equal number of simplification that can only be done
> if you are allowed to assume that overflow is undefined.

I doubt it; the reason is that the particular assumption that addition
and multiplication follow the natural two's complement rules gives us
an algebraic ring, which makes many transformations possible.  Any other
assumption would introduce an irregularity that has to be tested for in
each transformation.

> Perhaps an approach might be to say that "we know what overflow
> actually does for this operation, but if it occurs, it's undefined
> semantics".  That's what we actually *implement* right now and would
> give the best of both worlds.  Then there would be a bit that says that,
> in this particular operation, the overflow is *not* undefined.

This corresponds to the view that when the USER enters a + with int
arguments, there are no guarantees, but the COMPILER (in particular, tree
optimizations), has available a + node and a * node for ints that are
associative and distributive.  The fact that some ancient and obsolete
one's complement routine with an overflow trap that can't be turned off
might theoretically exist isn't a good reason for crippling the compiler.

If you want to use a mix, then you need to distinguish between overflows
that are a consequence of what the user entered, and overflows that only
exist because of transformations that the compiler did.