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

[Mark Mitchell]

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

This seems like a dangerous assumption.  In particular, what if
third-party library liba.so was provided last year, with 64-bit long
double, and third-party library libb.so is provided in the future, with
128-bit long double?  We can version the symbols in libc/libstdc++ so
that old binaries call the old functions and new binaries call the new
functions, but we can't go back and version the symbols in other
libraries.  So, even though we're eliminating the need to bump the libc
version number, I don't think we can really claim that people can freely
intermix old and new application code.

I guess that's obvious, and just restating what you said.  Pardon me
while my neurons catch up with yours... :-)

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.

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

I have to admit that would be my inclination as well.  I think libc is a
special case, both in that the ABI is so much simpler than for a C++
library, and in that it's the one library on the system with which
everything is linked, so avoiding having two of them is a big win.  For
libstdc++, my (unexpert) approach would just be to bump the SONAME, in
part because I'd have a hard time being sure that anything else was
really safe, and in part because the more magic we stuff into the
exports file, the harder it is to be sure that everything we do in
future will still work.

My two cents,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713