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

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 31 Jan 2006, Jakub Jelinek wrote:

> > libstdc++ ... Ugh.  For instance how do you deal with the problem that 
> > when a template is instantiated inline providing some of those symbols?
> 
> 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).

Right, that's what I meant.  Probably there are none such accesses, 
though?  In that case problems could only arise if the application mixes 
TFmode and DFmode code in the same image, where parts are using libstdc++ 
functions, which would resolve to the copy in the binary, which is single 
mode.  As we wouldn't allow/support mixed mode ldbl code this is no issue 
then, as you say.  Fine.

> 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).

With the above constraint (libstdc++ not calling itself such _Z*e* 
functions which could possibly be provided by the binary) I think the 
approach would work.  Although meanwhile (reading downthread) it would 
probably be even nicer to just use a different mangling for the new type 
representation.

> > 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?

I meant that both would have the same SONAME, but the non-default one 
would lie in a different directory, like /usr/lib/ldbl128, and the user 
had to explicitely choose that library to be used.

> 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.

Yes, but if that's only possible with a large amount of non-obvious symbol 
versioning tricks it might offset those advantages.


Ciao,
Michael.