Re: [PATCH] Document arithmetic overflow semantics

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

> I agree.  Which is why I'm in favor of adding flags to tree nodes that say
> whether the operation:
>
> (a) has undefined behavior
> (b) has defined overflow behavior, documented for the tree node in question
> (c) will trap on overflow.

At the GCC internal level there should be no such thing as undefined
behaviour, this is a front-end concept.  There should be tree nodes for
overflow behaviour A, overflow behaviour B or overflow behaviour C.
A front-end that says behaviour is undefined, is then free to use
whichever tree node is sees fit.  The middle-end should never be left
to guess what the front-end intended.

As for trap on overflow, that is currently supported and honored in
the middle-end, by flag_trapv and flag_non_call_exceptions.


You may have noticed that my original patch, was a simple documentation
patch that just described what GCC currently does, and what is assumed
at several points in the code.  Naturally, it doesn't require any source
code changes and/or regression testing on multiple platforms.

Should we decide to change GCC's implementation at some point in the
future, naturally we'll have to amend the documentation to reflect that.


Feel free to submit patches to implement you proposed semantics.  It
should have no effect on whether the proposed documentation is accurate
and/or appropriate.

Roger
--