This is the mail archive of the
mailing list for the GCC project.
Re: rs6000 LDBL_MAX converts to infinity
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Geoff Keating <geoffk at geoffk dot org>,aoliva at redhat dot com
- Date: Wed, 3 Mar 2004 22:58:42 +1030
- Subject: Re: rs6000 LDBL_MAX converts to infinity
- References: <20040303011040.GA2553@bubble.modra.org> <email@example.com>
On Wed, Mar 03, 2004 at 08:32:48AM +0000, Richard Sandiford wrote:
> Alan Modra <firstname.lastname@example.org> 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:
> == 0x1.FFFFFFFFFFFFF7FFFFFFFP1023L. Try a higher number and MIPSpro cc
> reports an error.
Curious. I'd have expected 0x1.FFFFFFFFFFFFF7FFFFFFFFFFFF8P1023L
IBM OzLabs - Linux Technology Centre