Re: New no-undefined-overflow branch

[Richard Guenther <rguenther at suse dot de>]

On Fri, 27 Feb 2009, Zdenek Dvorak wrote:

> Hi,
> 
> > > 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.
> 
> OK, then what about this: introduce accessor functions like
> 
> tree_code get_operation_semantics (tree_code)
>   -- returns PLUS_EXPR for PLUS_EXPR and PLUSNV_EXPR, etc.
> bool get_operation_overflow (tree_code)
>   -- obvious
> tree_code operation_code (tree_code, bool)
>   -- PLUS_EXPR, false -> PLUS_EXPR
>   -- PLUS_EXPR, true -> PLUSNV_EXPR
>   -- PLUSNV_EXPR, * -> abort
>   etc.
> 
> (possibly with more clear names), and change the code to always
> use them?

Yes.  In playing with an initial patch I see the need for these
kind of helpers.  Sofar I tried to limit myself to PLUS_EXPR_P ()
covering both kinds, but that certainly is not enough.

So I see the need for at least

  tree_code strip_nv (tree_code);
   -- returns PLUS_EXPR for PLUS_EXPR and PLUSNV_EXPR, etc.

I didn't yet come along a need for your last one. Maybe similar to the
second one is the requirement to somehow have a test when we want
to emit strict-overflow warnings - which we want for the NV codes
operating on signed types, possibly using TREE_NO_WARNING for
avoiding warnings for NV codes that value-range analysis inserted
(and, unfortunately there's no suitable place to put TREE_NO_WARNING
on fold arguments ... :/).

As of using them always - I will see how it works out.  For a start
I am able to miscompile gcc after just minimal fold surgery... :/

Thanks,
Richard.