Re: rs6000 LDBL_MAX converts to infinity

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar  2, 2004, Alan Modra <amodra@bigpond.net.au> wrote:

> While looking at this code, I noticed that the value is rounded to
> double after the high double has been subtracted.  I think this is
> unnecessary since real_to_target_fmt rounds before calling the
> encode function.

The fact that the incoming long double is properly rounded doesn't
imply the result of additional arithmetic is properly rounded,
especially considering that the result might not be representable as a
double.

What you're doing seems to work, but I don't see that it's correct.
It violates the invariant that encode functions are always passed
values that are already rounded.  This is clearly not the case if you
pass it something that overflows after rounding.

> No other encode_* function does this rounding.

No other encode_* function performs (emulated) FP arithmetic on incoming
values, and no other encode_* function has to represent the value it
gets using narrower FP formats.

What we used to do was to

  clear_significand_below (&u, SIGNIFICAND_BITS - 53);

so it wouldn't overflow.  Geoff significantly simplified this function
on Jan 9, but this presumably LDBL_MAX on powerpc-ibm-aix,
mips-sgi-irix6 and powerpc64-linux.

Geoff, how come this doesn't break Darwin?  What does LDBL_MAX look
like for you?  How about LDBL_MIN?

It appears to me that the right solution is to attempt rounding, like
we have now, but, if that turns out to be an infinity while the
incoming value was not, we clear the significand as above, and use
that as `u' instead.  This should work for aix and irix6.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}