Re: [PATCH] Document arithmetic overflow semantics

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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.

I think that's backwards.  If program in C, C++, or Ada generates an
overflow, that program is undefined.  That means the optimizer can do
anything it wants to the program, which, in turn, means that the optimizer
can assume that overflow *does not* occur, and that allows a lot more
optimizations.

    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.  

Only for erroneous programs, where it's perfectly acceptable to do that.

    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.

Well, obviously we have to test for it!