On Thu, 14 Nov 2013, Alan Modra wrote: > On Tue, Nov 12, 2013 at 10:33:46PM +0000, Joseph S. Myers wrote: > > On Tue, 12 Nov 2013, Ulrich Weigand wrote: > > > Well, we had been thinking about this, but right now it seems we're not > > > going to be able to make that change throughout the ecosystem quickly > > > enough, so for now, it'll probably have to remain the IBM long double. > > > > What's the difficulty? GCC is supposed to support IEEE binary128 long > > double already for Power, and IEEE binary128 works much better than IBM > > long double in glibc. The time a new ABI is being introduced is the time > > to get things right rather than suggesting yet another ABI change in > > future. > > The major difficulty is that we don't want to use the existing > powerpc32 parameter passing and return scheme for ieee128 (ie. pass > pointers to memory). The thought was to pass ieee128 in vsx > registers. This means work in gcc, in glibc, in gdb, and likely other > places, and as Uli has already said, we have time and resource > constraints.
Thanks for the explanation. Unfortunately it seems such constraints mean the IBM long double support in libgcc and glibc is also undermaintained compared to that for all IEEE floating-point formats as used by other architectures (see the large pile of glibc libm test failures resulting from libgcc bugs, or missing features such as fmal). (Although in theory you could use long double the same as double until there's time to implement binary128 support, I wouldn't really recommend doing that. It's very likely new symbols involving long double have been added to the glibc ABI since 2.4 without the required special handling for symbol versioning compatibility for architectures changing long double format, and doing another long double transition would require identifying all such symbols.) -- Joseph S. Myers jos...@codesourcery.com
