Thu, 18 Jan 2007, David Edelsohn wrote:

This patch cloaks the new software emulation part of the
darwin-ldouble.c file if not compiled in long double 128 mode. I
considered always building the file with -mlong-double-128, but if the
rest of the compiler was not configured for long double 128 and configure
did not automatically detect support, this likely will lead to problems,
so better to nip it in the bud.

The whole of libgcc on PowerPC GNU/Linux is meant to be built with
-mlong-double-128, whether or not glibc supports it, so that programs can
be built with this option as long as they don't use libc/libm/libstdc++
long double functions without libc support.

The code to ensure this used to be in t-ppccomm, and still is there on 4.2
branch, adding -specs=ldblspecs where ldblspecs uses -mlong-double-128
unless -msoft-float. With toplevel libgcc, it's now in
libgcc/config/rs6000/t-ldbl128 and checks for whether the compiler defines
_SFT_FLAT. With the soft-float long double support in, this file should
now set HST_LIBGCC2_CFLAGS += -mlong-double-128 unconditionally: the
lines

# Use -mlong-double-128 only when not compiling nof libgcc.
predefined-macros := $(shell true | $(CC) $(CFLAGS) -x c -dD -E -)
ifeq ($(findstring _SFT_FLAT,$(predefined-macros)),)
endif

should be removed.

Sat, 20 Jan 2007, David Edelsohn wrote:

Joseph S Myers writes:

JosephThe whole of libgcc on PowerPC GNU/Linux is meant to be built with
Joseph-mlong-double-128, whether or not glibc supports it, so that programs can
Josephbe built with this option as long as they don't use libc/libm/libstdc++
Josephlong double functions without libc support.

This is an assertion. Why?

I do not believe any of the principles have changed since the previous
thread <#01563>.
Building with -mlong-double-128 makes some additional functions to support
TFmode available in libgcc. It does not affect the functions for DFmode
etc. that are present in any case.

The additional functions only cause problems if they contain undefined
references to functions not in libgcc. That was why Jakub restricted
-mlong-double-128 to hard-float
<>. Now soft-float
long double support is present, the reason for this restriction no longer
applies.

Patches welcome.

I will remove those soft-float checks in t-ldbl128 in a resubmission of my
E500 long double patch to apply to current mainline, which will remove the
last case where long double support can lead to broken libgcc with
undefined references.

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