This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC IEEE 128-bit floating point: Internal GCC types


On Tue, 3 Jun 2014, Vincent Lefevre wrote:

> On 2014-06-02 21:20:57 +0000, Joseph S. Myers wrote:
> > ([...] Conversion from __float128 to __ibm128 would presumably be
> > done in the usual way of converting to double, and, if the result is
> > finite, subtracting the double from the __float128 value, converting
> > the remainder, and renormalizing in case the low part you get that
> > way is exactly 0.5ulp of the high part and the high part has its low
> > bit set.)
> 
> This is not as simple, depending on how you decide to handle the
> largest values. This is important if FP-model related data are
> provided, such as LDBL_MANT_DIG (the precision) and LDBL_MAX_EXP
> (the maximum exponent). The __ibm128 implementation as long double
> is currently buggy / inconsistent, and I've reported the following
> bug:

There are lots of bugs (some of which may get addressed through a 
configure option to enable slower but better behaved versions of the 
relevant libgcc functions, intended for uses such as running the glibc 
testsuite and not for distribution of binaries configured in that way).  
One reason I find attractive the approach of having separate glibc 
libraries, with any given glibc build only supporting one long double 
format (plus the case of long double = double, for old binaries using the 
old symbol versions or via libnldbl_nonshared.a) is that it allows for a 
deprecation path for the old long double format (i.e. saying that after a 
certain point glibc no longer supports builds for the old format and so 
all the complications relating to it can be removed) - although that would 
require a new ABI variant for 32-bit, not just for 64-bit, and may not be 
workable in practice with existing users.  (You also avoid other 
complications relating to the two versions coexisting in a single 
library.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]