This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Document arithmetic overflow semantics
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: roger at www dot eyesopen dot com
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 13 Feb 03 09:39:59 EST
- Subject: Re: [PATCH] Document arithmetic overflow semantics
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
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
Well, obviously we have to test for it!