Re: [PATCH] Document arithmetic overflow semantics

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

On Thu, 13 Feb 2003, Richard Kenner wrote:
>     At the GCC internal level there should be no such thing as undefined
>     behaviour, this is a front-end concept.
>
> I disagree.  As I said, it's quite valuable to be able to know that we
> don't care, for optimization purposes, if an overflow has or has
> not occurred.

The problem is that this cuts both ways.  Yes, at the moment we may
legitimately replace an expression that overflows with one that doesn't
by invoking the "undefined behaviour" clause.  However, it prohibits
use from optimizing an expression that doesn't orginally overflow, with
an equivalent expression that may.

Currently, GCC's middle-end expands integral PLUS_EXPR using add?i3.
The same addsi3 pattern is used in the back-ends for unsigned arithmetic
as for signed arithmetic, and the behaviour of overflow with both is the
usual two's-complement semantics.  A front-end accepts that an expression
will be evaluated this way when it decides to pass a PLUS_EXPR to the
middle-end.

If a front-end wished to use saturating arithmetic overflow, they would
use the appropriate tree nodes that GCC's middle-end would expand using
ss_plus and us_plus RTL patterns.  Doing a grep in the GCC source code,
the only reference to SS_PLUS is in simplify-rtx.c, which is currently a
place holder as GCC currently performs no simplifications of SS_PLUS,
US_PLUS, SS_MINUS or US_MINUS.


> Nope.  Lots of places in the optimizer assume that overflow signed
> integers are undefined.  Your proposed documentation doesn't mention that.

I'm prepared to drop this entire argument if you can find me just one
(that doesn't already have a GNATS PR).


In return, I'll draw your attention to the following patch, that is
an optimization that we're currently unable to perform because of GCC's
poorly defined semantics.
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00028.html
Note that several rival C/C++ compilers do happily perform this
transformation, for example Microsoft's Visual C.  You might want
to check whether any of the commercial Ada compilers do too.


If you really believe PLUS_EXPR should have undefined overflow semantics
for signed overflow, then do something about it and document that thats
the intended behaviour.  In which case, the Java front-end will have to
introduce a new tree node with PLUS_EXPR's current semantics.


May I also remind you of the catastrophe of leaving the semantics of
paradoxical subregs undefined in GCC's RTL.  Fortunately, for 3.3 and
3.4 their interpretation was decided upon, but gcc 3.2.2 still has PRs
on Sparc, PA-Risc, IA-64 and PowerPC.  Let's document what we intend!

Roger
--