Re: rs6000 LDBL_MAX converts to infinity

[Alan Modra <amodra at bigpond dot net dot au>]

On Wed, Mar 03, 2004 at 08:32:48AM +0000, Richard Sandiford wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00073.html touched this
> > area, with Richard noting
> >
> >> While there, I noticed that the code didn't deal correctly with normal
> >> values of the form 0x1.FFFFFFFFFFFFFx....P1023, where the high bit of "x"
> >> is set.  The high part double will round to infinity, and so the extended
> >> precision number will also be infinite.  However, at the moment, the low
> >> part of this number will have a nonzero (negative) lowpart.
> > [...]
> > LDBL_MAX is a number of the above form, in fact x.... is a bunch of
> > F's.  It's obvious that gcc's own value for LDBL_MAX ought to convert to
> > a finite number!  So either LDBL_MAX needs adjusting or
> > encode_ibm_extended needs to convert these numbers to finite values.
> > I think the latter is the correct course.
> 
> Dunno about powerpc, but I think the first is right for MIPS.  According
> to math(5), the low-part double is supposed to be within 0.5ULP of the
> high part.  No special exception is given for the highest exponent.

Since you reckon LDBL_MAX ought to change, perhaps you'd like to submit
a patch.  :)

> Indeed, SGI's float.h definition of LDBL_MAX is:
> 
> 1.797693134862315807937289714053023E+308
> 
> == 0x1.FFFFFFFFFFFFF7FFFFFFFP1023L.  Try a higher number and MIPSpro cc
> reports an error.

Curious.  I'd have expected 0x1.FFFFFFFFFFFFF7FFFFFFFFFFFF8P1023L

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre