Re: [PATCH] Document arithmetic overflow semantics

[Roger Sayle <roger at www dot eyesopen dot com>]

Hi Richard,
> I *really* don't like defining the tree operations as having this overflow
> behavior.    I have three major problems with it:
>
> (1) It removes the potential of optimizations that assume such overflow
>     cannot occur in languages where it is undefined (C, C++, and Ada).

The fact that the behaviour of overflow is undefined in C, C++ and Ada
does not mean that "overflow cannot occur".  Quite clearly overflows do
occur, and the optimizers are paralyzed by the semantics in this event.

Leaving behaviour undefined actually limits more optimizations than it
helps.  Any optimization that concerns overflow will assume a behaviour
upon overflow.  If the behaviour assumed is anything other than the
two's-complement overflow, then the optimization is "unsafe" and will
produce different results to not performing the optimization, as the
RTL will use two's-complement overflow at run-time.  And as has been
demonstrated recently, even if the optimization assumes these overflow
semantics, people will argue that it relies on "undefined" behaviour.

I suggest people pay attention to what "undefined" and "implementation
defined" really mean in the ISO C/C++ standards.


> (2) It represents an implementation difficulty and perhaps cost on machines
>     where this behavior is not present (for example, where it traps).
> (3) It does not allow representing trapping arithmetic in the three.

I would suggest that the lines I've added say nothing of whether these
operations trap or not, via "-ftrapv" or "-fnon-call-exceptions".  If
someone else would like to document that behaviour, please feel free
to add a paragraph or two in these locations.

> My suggestion is to use a bit in either the type (my preference) or the
> operation to say whether overflow is defined or not.  There can be a bit
> in the operation to require that it trap if it overflow.

I'm not opposed to either adding a bit to the tree structure, or
introducing a new tree node for trapping arithmetic.  However the
existing infrastructure is currently sufficient for all of GCC's
front-ends and back-ends without modification.  Being pragmatic I
can't see how adding a bit would help, if we never set or never
test for it.

Roger
--