[PATCH, committed] Fix PowerPC long double bootstrap

[Joseph S. Myers]

On Mon, 22 Jan 2007, David Edelsohn wrote:

> 	I know always including -mlong-double-128 support in libgcc is
> useful and convenient, but is it safe for long-term maintenance.  Why is
> it a good idea effectively to hide a multilib inside libgcc?

The approach for all of glibc, libstdc++ and libgcc does not need a 
multilib here.  The choice of glibc not to use a multilib strongly 
indicates one should not be used for the other libraries, given the 
problems of getting the right shared library multilib of libgcc or 
libstdc++ at runtime if more than one is available with a single glibc.

glibc uses symbol versioning to support both 64-bit and 128-bit long 
double in a single libc.

libstdc++ also uses symbol versioning with the same effect, together with 
different mangling for the two long double widths.  (That part was 
considered not safe enough for 4.1 branch so it only in 4.2 and later, so 
was widely backported.)

libgcc names functions based on the modes involved not on the C types, so 
128-bit long double just adds to the functions available without affecting 
any other functions.  (Where some DF functions in libgcc can use TF 
computation internally, this is explicitly disabled for IBM long double, 
so the availability of TFmode has no effect on the code for those DF 
functions.)

-- 
Joseph S. Myers
joseph@codesourcery.com