On Fri, 2014-05-02 at 12:13 +0200, Jakub Jelinek wrote: > Hi! > > On Tue, Apr 29, 2014 at 06:30:32PM -0400, Michael Meissner wrote: > > This patch adds support for a new type (__float128) on the PowerPC to allow > > people to use the 128-bit IEEE floating point format instead of the > > traditional > > IBM double-double that has been used in the Linux compilers. At this time, > > long double still will remain using the IBM double-double format. > > > > There has been an undocumented option to switch long double to to IEEE > > 128-bit, > > but right now, there are bugs I haven't ironed out on VSX systems. > > > > In addition, I added another type (__ibm128) so that when the transition is > > eventually made, people can use this type to get the old long double type. > > > > I was wondering if people had any comments on the code so far, and things I > > should different. Note, I will be out on vacation May 6th - 14th, so I > > don't > > expect to submit the patches until I get back. > > For mangling, if you are going to mangle it the same as the -mlong-double-64 > long double, is __float128 going to be supported solely for ELFv2 ABI and > are you sure nobody has ever used -mlong-double-64 or > --without-long-double-128 configured compiler for it?
> What is the plan for glibc (and for libstdc++)? > Looking at current ppc64le glibc, it seems it mistakenly still supports > the -mlong-double-64 stuff (e.g. printf calls are usually redirected to > __nldbl_printf (and tons of other calls). So, is the plan to use > yet another set of symbols? For __nldbl_* it is about 113 entry points > in libc.so and 1 in libm.so, but if you are going to support all of > -mlong-double-64, -mlong-double-128 as well as __float128, that would be far > more, because the compat -mlong-double-64 support mostly works by > redirecting, either in headers or through a special *.a library, to > corresponding double entry points whenever possible. > So, if you call logl in -mlong-double-64 code, it will be redirected to > log, because it has the same ABI. But if you call *printf or nexttowardf > etc. where there is no ABI compatible double entrypoint, it needs to be a > new symbol. > But with __float128 vs. __ibm128 and long double being either of those, > you need different logl. > Yes and we will work on a plan to do this. But at this time and near future there is no performance advantage to __float128 over IBM long double. > Which is why it is so huge problem that this hasn't been resolved initially > as part of ELFv2 changes. Because it was a huge problem and there was no way for the required GCC support to be available in time for GLIBC-2.19. So we will develop a orderly, step by step transition plan. This will take some time.
