This is the mail archive of the
mailing list for the GCC project.
Re: Simplify FP conversions
> On Sun, Feb 09, 2003 at 07:14:31PM +0100, Jan Hubicka wrote:
> > >
> > > Hi,
> > > this patch fixes two problems in nullstone.
> > > I am not 100% sure about the first conversion. Is overflow in
> > > float_truncate defined differently from overflow in float?
> > Oops, in the second case forgot to check that intermediate conversion
> > won't cause rounding.
> I think there's a similar problem with the float_truncate case.
> Consider a DI->DF->SF conversion sequence. As written, you'll
> get a double rounding, which will give different results under
> some inputs.
I was thinking about this on the way to Prague. There is same bug in
the convert.c change.
Question is, whether there is double rounding case that corresponds to
integer number? Probably yes.
What then? Can we enable it at unsafe-math at least?
I also seem to dimply recall that certain combination of modes won't
cause double rounding.
> > + case FLOAT_EXTEND:
> > + /* (float_extend (float_extend x)) is (float_extend x) */
> > + if ((GET_CODE (XEXP (x, 0)) == FLOAT_EXTEND
> > + || GET_CODE (XEXP (x, 0)) == FLOAT)
> > + && (GET_MODE_SIZE (GET_MODE (XEXP (x, 0))
> > + > GET_MODE_SIZE (GET_MODE (XEXP (XEXP (x, 0), 0))))))
> (float_extend (float_extend x)) doesn't need this check.
It will always pass here.
> (float_extend (float x)) needs a different check. The
> size of the fp mode isn't as relevant as the size of its
> significand. Consider SI->SF. In this case we've got
> two 32-bit operands, but there's still a rounding.
> The value you want is significand_size(mode).
Hmm, I was looking for this function and then noticed some other code
that simply assumed that when size is bigger, it fits.
I will send updated patch for both this and convert.c change.