Re: New no-undefined-overflow branch

[Richard Guenther <rguenther@suse.de>]

On Fri, 27 Feb 2009, Zdenek Dvorak wrote:

> Hi,
> 
> in general, I like this proposal a lot.  However,
> 
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> > 
> > The sizetypes will simply be operated on in no-overflow variants
> > by default (by size_binop and friends).
> > 
> > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR
> > (thus appending V to the first part).

First, for the bikeshedding part I agree that NV is probably a better
idea.

> introducing new codes seems like a bad idea to me.  There are many
> places that do not care about the distinction between PLUS_EXPR and
> PLUSV_EXPR, and handling both cases will complicate the code (see eg.
> the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR
> distinction).  Why not just use a flag to mark the operation as
> non-overflowing?

I obviously thought about this.  The issue with using a flag is
that there is no convenient place to stick it and that it makes
the distinction between the two variants less visible.  Consider
the folding routines that take split trees for a start.

IMHO using new tree-codes is much less complicated than carrying
around flags.  I did consider putting flags on the tree code
itself, but that isn't going to make the changes easier either.

Richard.