Re: [RFC PATCH] Optionally use -mlong-double-128 by default on {powerpc{,64},s390{,x},sparc,alpha}-linux

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jan 31, 2006 at 04:51:02PM +0100, Michael Matz wrote:
> > More controversial is the libstdc++-v3 side.
> 
> Yeah ;)  I'm anyway already nervous enough about the whole series of 
> ldbl-128 patches so late in the process, although I think the gcc and 
> libgcc side might be okay.  But this fragile fiddling of symbols for 
> libstdc++ ... Ugh.  For instance how do you deal with the problem that 
> when a template is instantiated inline providing some of those symbols?
> Ihen it will be unversioned in the executable (and exported).  Depending 
> on how you compile the application it will provide an 64 or 128 bit ldbl, 
> and might clash with either version of the provided libstdc++.

The only problem I see would be when libstdc++.so.6 internally calls some
_Z*e* routine (or accesses _Z*e* object) through a dynamic relocation,
libstdc++.so.6 is relying that it is the TFmode long double version but
it resolves to a DFmode long double version in some other library (or
binary).  But if you don't mix DFmode and TFmode long double libraries in one
application except libgcc_s, lib{c,m} and libstdc++, I believe you should be
fine.  If the app (except those 4 libs that handle both ABIs) is TFmode
compiled/linked, then the app agrees with how libstdc++ is internally
compiled and there shouldn't be issues with that.  If it is DFmode, then
either it won't touch libstdc++ and use its own instantiations etc.
which are all DFmode, or it will call some libstdc++.so.6 functions/methods
with @GLIBCXX_3.4 symver.
Most of them are simple aliases to the double functions/methods and there
are no virtual calls that would allow the app to see the difference.
Then there are the few money_get/money_put/num_get/num_put symbols
that are for @GLIBCXX_3.4 aliased to extra __ methods, but there the
virtual tables have separate DFmode long double and TFmode long double
entries and the @GLIBCXX_3.4 ones call the DFmode ones, while
@@GLIBCXX_LDBL_3.4 ones call the TFmode ones.
I'm of course interested if you can show how exactly this scheme would break
(please look at the patch I posted today rather than the older one).

> Wouldn't it be easier to just admit the fact that it's an ABI change, and 
> multilib libstdc++ ?

By multilibbed libstdc++ you'd mean that on the arches in question
-mlong-double-64 built libstdc++ would have libstdc++.so.6 SONAME and
-mlong-double-128 built libstdc++ would have libstdc++.so.6.1?

>From what I gathered only very few C++ libraries out there (Qt, KDE, ...)
ever touch long double (boost is a big exception), and having just one
library that is compatible with both ABIs has big advantages.

	Jakub