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 jos...@codesourcery.com
