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

[Jakub Jelinek]

On Tue, Jan 31, 2006 at 11:11:21PM -0800, Mark Mitchell wrote:
> > 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.
> 
> I guess that's obvious, and just restating what you said.  Pardon me
> while my neurons catch up with yours... :-)

Yes, you basically restated what I said.  I only stressed that most apps
don't use long double in C++ code, especially on platforms where double was
the same as long double, so for most libraries and binaries it is an
unimportant change.

> For C++, have you considered changing the mangling for long double?  The
> Itanium ABI uses "e" for long double (which it assumes is 80 bits) and
> "g" for __float128.  HP interpreted this as meaning that if long double
> happens to be 128 bits, you should use "g" for that, and "e" for
> __float80; GCC interpreted the ABI more literally, and always uses "e"
> for long double, independent of size.  I wonder if we ought to adopt the
> HP interpretation for those targets that are adding 128-bit long double,
> i.e., use "g" for that type, and keep "e" as the current long double
> type.  That would prevent mislinking of C++ applications.

If we could use "g" for TFmode long double on the architectures in question
(powerpc*-*-linux*, sparc{,v7,v8,v9}-*-linux*, s390*-*-linux* and
alpha*-*-linux*), I'm all for that.  It would certainly help a lot for
coexistence of C++ code with different long doubles in one app
(of course you still can't call a long double referencing routine/method/etc.
between differently built objects/libraries, but if C++ library A uses
TFmode long double internally and not on its public interfaces and
C++ library B uses DFmode long double internally, things still ought to work
correctly and when you try to call void foo (long double); between
differently built objects, you'd even get link time errors).
And it would certainly simplify the libstdc++ patch a lot as well
and make it easier to prove that it works correctly with both "e"
and "g" long double.

	Jakub