Re: [PATCH] Negation related constant folding improvements

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 11 Aug 2003, Richard Henderson wrote:
> On Sun, Aug 10, 2003 at 10:04:31PM -0600, Roger Sayle wrote:
> >       case INTEGER_CST:
> > -     case REAL_CST:
> >         if (! TREE_UNSIGNED (type)
> >   	  && 0 != (tem = fold (build1 (NEGATE_EXPR, type, t)))
> >   	  && ! TREE_OVERFLOW (tem))
> >   	return tem;
> >         break;
> >
> > +     case REAL_CST:
> > +       return fold (build1 (NEGATE_EXPR, type, t));
>
> This is correct only if the fp representation is sign+magnitude.
> This is not true of the C4X format.

I've now investigated the issue a bit further and it appears that
mainline CVS doesn't actually support non sign+magnitude FP formats.

The effect of "fold (build1 (NEGATE_EXPR, type, t))" in the above
code is to call the perform the following actions on line 5444 of
fold-const.c:

  t = build_real (type, REAL_VALUE_NEGATE (TREE_REAL_CST (arg0)));

build_real in tree.c never sets TREE_OVERFLOW.  See line tree.c:483.
The comment in build_real seems to indicate that overflow should now
be checked in real_convert.

The implementation of NEGATE_EXPR in the floating point emulator at
line 1017 of real.c just flips the sign bit and returns, as our internal
representation is sign and magnitude, so perhaps we should be calling
real_convert after negating floating point constants in order to handle
c4x.

However, looking at real_convert, it calls two functions to do the
real work; "round_for_format" and "normalize", and it looks as though
both assume the range of floating point values is symmetric with
respect to zero.  Unless, of course, I'm very much mistaken.


It looks like the only place that we specially handle c4x's two's
complement format is in encode_c4x_{single,double} where it looks
as though we silently misencode the sign-dependent overflow.


I'm quite happy to work to fix this (with help), but the hunk of my
patch that you quote above can't change GCC's current behaviour.

Roger
--