64-bit long double support.

["Carlos O'Donell" <carlos at systemhalted dot org>]

The HP-PARISC processor has no 128-bit hardware floating point
support. In HPUX the 128-bit long double support is all in software.
After years of trying we have come to the conclusion that the HPUX
128-bit long double support will never be released into the public.

It was the conclusion of the community that we would use 64-bit long
double, a type which would be identical to double.

The goal is to get `long double' fixed for hppa-linux. You might ask
what is broken?

1. GCC at one point assumed `long double' was 96-bits (fixed, 64-bits)
2. GLIBC at one point asumed `long double' was 128-bits (fixed, 64-bits)
3. GLIBC headers do not export `xxxxl' (long double) variants of the
math functions.
    = The fix is to undef __NO_LONG_DOUBLE_MATH in your own version
of mathdefs.h
4. GLIBC doesn't test `long double' support.
    = Hack up math/Makefile to have a finer control over building and
testing long doubles.

I have patches for 3, and 4. The patch for 3 will "turn on" 64-bit
`long double' math functions in our headers. The patch for 4 will
reveal that "lrintl" and "lroundl" are probably broken in some
rounding cases.

There was mention of using gcc to support "double double" and use 2x
64-bit doubles. Unfortunately I think this road would be paved with
lots of debugging, a new ABI, and more headaches for little reward.
Remember our goal "fix long double support."

Is there any opposition to checking in the fix for 3?
Speak now or forever hold your peace.

... or until Kyle writes the 128-bit long double support library,
makes it fast, and we transition our ABI (there are provisions for
this already).

Cheers,
Carlos.