This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Document arithmetic overflow semantics
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Roger Sayle <roger at www dot eyesopen dot com>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, <gcc-patches at gcc dot gnu dot org>, <gcc at gcc dot gnu dot org>
- Date: Thu, 13 Feb 2003 16:45:31 +0000 (GMT)
- Subject: Re: [PATCH] Document arithmetic overflow semantics
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