------- Comment #5 from jakub at gcc dot gnu dot org 2006-01-24 16:26 -------
On the Linux architectures that use DFmode long double ATM and want to switch
to some other format in glibc 2.4 (best would be if all are switching
together),
we primarily need GCC 4.1 to actually be able to compile glibc 2.4.
That means supporting -mlong-double-128 option, which doesn't necessarily need
to be the default, supporting the desired long double format with that option
(glibc will support only IEEE quad, XFmode and IBM extended format) and
have libgcc{.a,_s.so} provide long double entry points if needed to compile
glibc (libm uses complex long double multiplication/division, usually e.g.
__multc3/__divtc3 will be needed).
sparc-linux (32-bit) already switched on the glibc side, but unfortunately
I was testing that with GCC 3.4.x where it worked (__multc3/__divtc3 wasn't
present yet), now we have a chicken-and-egg like problem there (glibc
provides _Q_add/_Q_mul etc. routines but needs __multc3/__divtc3, libgcc
can't be built with -mlong-double-128 without glibc 2.4 installed, as
__multc3/__divtc3 etc. implementation in libgcc uses _Q_add/_Q_mul, so this
would be good to solve for GCC 4.1.
ppc64-linux (64-bit) is known to build the soon to be glibc 2.4 out of the box,
for ppc32-linux David Edelsohn posted a patch.
I'd appreciate a lot if s390{,x} in GCC 4.1 could have this level of IEEE quad
support too, it will be far easier to switch all architectures at once.
alpha-linux might want to switch as well, -mlong-double-128 is supported there,
though probably libgcc isn't built with that. Richard, are you still planing
to switch?
glibc 2.4 will support both DFmode and TFmode long double through redirects
in <math.h>, <stdio.h> and other headers (if -mlong-double-64) and symbol
versioning.
Another step is to make -mlong-double-128 the default on those architectures,
if GCC configury detects glibc 2.4 (or is told via some configure option).
Here the biggest problem is libstdc++, which exports some long double templates
and there we don't want to switch SONAME in GCC 4.1. This can be solved
via symbol versioning (like in glibc) and multilibbing libstdc++
(-mlong-double-128 multilib libstdc++.so.6 would be backwards compatible with
-mlong-double-64 one, so that would be the one used at runtime, for link time
we would use the respective multilib).
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org,
| |bkoz at gcc dot gnu dot org,
| |jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
