This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com, wschmidt at gcc dot gnu dot org, bergner at gcc dot gnu dot org, pthaugen at us dot ibm dot com, sjmunroe at us dot ibm dot com, libc-alpha at sourceware dot org
- Date: Fri, 02 May 2014 07:47:44 -0500
- Subject: Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC
- Authentication-results: sourceware.org; auth=none
- References: <20140429223032 dot GA21674 at ibm-tiger dot the-meissners dot org> <20140502101355 dot GY1817 at tucnak dot redhat dot com>
- Reply-to: munroesj at us dot ibm dot com
On Fri, 2014-05-02 at 12:13 +0200, Jakub Jelinek wrote:
> 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
> 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.