[PATCH] Document arithmetic overflow semantics

[Joseph S. Myers]

On Thu, 13 Feb 2003, Roger Sayle wrote:

> 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

Undefined behaviour needs to be explicitly modelled in any formal model of
C (see e.g. Norrish's thesis).  It is entirely reasonable to pass it down 
to the middle end.  A C program has a family of possible semantics, some 
of which involve undefined behaviour for some or all input; if we pass 
down information about the family of semantics (rather than unique 
semantics), as constrained by GCC's implementation-defined choices only, 
the middle end can make whichever choices are best for the given code on 
the given machine.  (For example, it can choose the order in which 
function arguments are computed to be what is best for a given function 
call, although what happens with undefined code changing the same object 
in multiple function arguments may vary on different machines.  Scheduling 
can move computations that are not separated by a sequence point past each 
other, when only in undefined code could they change the same variable.  
Having generated code for a+b, the compiler can use the condition codes 
left by that operation for a subsequent check on the value of a+b, even 
though they might be wrong for the check had overflow occurred (this has 
been mentioned as an underlying reason for signed integer arithmetic being 
undefined - the original C compilers having made such assumptions).)

In practice, it may be difficult for the middle-end representation to
encode all the information about the family of program semantics permitted
by the language standard and the implementation-defined behaviour, but
where it can be represented and used it is reasonable to do so.

-- 
Joseph S. Myers
jsm28@cam.ac.uk