Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Jan 27, 2006 at 04:24:30PM -0800, Mark Mitchell wrote:
> Andrew Pinski wrote:
> 
> > Try three months since a week is not going to be enough to really test this
> > big of a patch.  Can we raise this to the SC, even though I already know what
> > their answer is going to be (yes)? 
> 
> You can certainly raise this issue with the SC if you like.
> 
> I have not made a decision on this issue, and I am indeed concerned
> about its late date and large impact.
> 
> However, my understanding is that the PowerPC GNU/Linux community has
> decided this is functionality they really want.  I have indicated that I
> think the old behavior should be the default for any 4.1 patch.

There are 2 kinds of patches.  The ones that add support for optional
-mlong-double-128 (and add new *tf*/*tc* exported symbols to libgcc{,-s}):

[ppc32] http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01907.html
[s390,s390x] http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01953.html
[sparc32] The configure bits from my "Optionally use -mlong-double-128 by
	  default" patch, but not used to set -mlong-double-128 as default,
	  rather just build libgcc with -mlong-double-128.
	  Though ATM the only symbols needed from libgcc to actually
	  build glibc is __multc3/__divtc3, so maybe we are going to
	  work around this by linking glibc's copy of these 2 functions
	  into libm if they are missing in libgcc.a, at which point
	  no change would be necessary on sparc32.
[alpha] Not sure, either something like sparc32 needs, or simply
	TARGET_LIBGCC2_CFLAGS += -mlong-double-128, depending on whether
	such libgcc is self-contained or not.

Without these patches it is not possible to compile glibc 2.4 on those
architectures and the patches shouldn't have effect on code compiled
by default (unless you explicitly use -mlong-double-128).  The only
package that would use this switch by default would be glibc, and glibc
build can be tested satisfactorily within days (we already build ppc{32,64}
glibc that way, are going to do the same with s390{,x} glibc during this
weekend), especially because glibc has quite good testsuite.
As the patches affect symbol versioning of libgcc, it is really desirable
to have them in GCC 4.1, otherwise which symbol version to use is unclear.

Another thing is the
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01958.html
incomplete patch.  I'm NOT proposing this one for GCC 4.1, only for 4.2
and agreement on the symbol versioning, so that interested parties
can use backports of these changes on their branches and they are ABI
compatible.  This patch affects libstdc++.so.6's symbol versioning, but
introduces a separate namespace for the symbol versions, parallel to
the normal versions that increment in (almost) each release.

	Jakub