long double 64->128 transition (was Re: ppc warnings)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Sep 02, 2002 at 11:52:56PM -0700, Ulrich Drepper wrote:
> Jakub Jelinek wrote:
> 
> > Well, if you could send me your comments about
> > http://sources.redhat.com/ml/libc-hacker/2002-08/msg00102.html
> > I could try to finish it this or next week...
> 
> I thought I already did.
> 
> The long double problem should be know for all the time and if somebody 
> used long double on these architectures it is the programmer's fault. 
> Jumping through hoops to enable binary compatibility is nothing I would 
> consider.

Well, there are 2 different thing.
One is binary compatibility with previously compiled
binaries/libraries (against glibc 2.2.x and earlier) and one is the ability
to pick 64-bit or 128-bit long double for newly compiled programs/libraries.

The former is IMHO necessary and with a few exceptions it is something we
get for free (ie. in most cases it is just about adding
compat_symbol(libm, exp, expl, GLIBC_2_1);
stuff). The exceptions are *printf and *scanf family
plus nexttowardf compatibility alias.

The latter is questionable. Either we allow it and need lots of ugly stuff
like is in the patch, or we simply say if you want to use glibc 2.3+ on
sparc32 (or powerpc32), you simply has to ensure you're using 128-bit long
double. This could be done e.g. for sparc by changing <bits/wordsize.h>
to read:
/* Determine the wordsize from the preprocessor defines.  */

#if defined __arch64__ || defined __sparcv9
# define __WORDSIZE     64
#else
# define __WORDSIZE     32
# ifndef __LONG_DOUBLE_128__
#  error GLIBC 2.3 supports only 128-bit long double for newly compiled
#  error programs. You must ensure -mlong-double-128 is passed to the
#  error compiler. This can be either passed on the command line,
#  error or better changed during compiler compilation or in
#  error in gcc's specs file by adding %{!mlong-double*:-mlong-double-128}
#  error to cc1 and cpp_options.
# endif
#endif

gcc 3.2.1+ could for native builds check glibc version and for 2.3+ default
to -mlong-double-128 instead of -mlong-double-64 automatically.

> Are you sure we can remove NO_LONG_DOUBLE support from the ldbl-96 code? 
>   Maybe there'll be some architecture where gcc is not prepared for 
> 128-bit long double.

I'm sure. NO_LONG_DOUBLE means no long double type is available, thus
neither ldbl-96 or ldbl-128 directories are used (just dbl-64 with its
aliases).

> The ldbl-64-128 code seems to duplicate the 64-bit functions so that 
> they can be aliased.  Correct?  The duplications shouldn't be necessary 
> but I won't object.  In any case, the ldbl-64-128 directory needs a 
> README file explaining the purpose.

Well, it was not duplicating them, instead including the actual dbl-64
or generic implementations and adding the aliases. If you want the macros
in generic and dbl-64 files instead, it can be changed.

> > It shouldn't have any impact on ports other than sparc/sparc32
> 
> Except uglifying some public headers.

See above, if we only support TFmode long double for future compilations,
this is not necessary.
For SPARC distributions switching to GLIBC 2.3 and GCC 3.2+ this should be
trivial, as they will recompile everything anyway.
For those who play on their own it is their problem.

	Jakub