Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

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.