[parisc-linux] long double

[parisc-linux] long double

[Matthew Wilcox]

I searched the mailing list for a discussion of the `long double' problem,
but I didn't find it.  So here we go...

gcc currently thinks that `long double' is 64-bits (the same size
as double).  This is perfectly legitimate, but...
glibc thinks that `long double' is 96-bits.
And HP-UX thinks `long double' is 128-bits.

So any package using long double is probably very broken.  This may
explain some of our bizarre mathematical-related failures.

Our options:
(1) Inform gcc that it's wrong, our long doubles are really 96-bits.
I don't see any way of easily implementing 96-bit floating point numbers
on top of the hardware.  I like this option the least.

(2) Inform glibc that it's wrong, our long doubles are really 64-bits.
This probably fixes most of the problems we're experiencing, but may
break an ABI somewhere?  More investigation required.  This is probably
the easiest of the three options to implement.

(3) Change both gcc and glibc to think that long double is actually
128-bits wide.  This is almost certainly going to break some packages,
and the kernel FP support may have to be enhanced to emulate some
of the opcodes.  The PA-8500 ERS says that it does NOT support `quad
precision' operations in hardware.  This is certainly going to be more
work to implement than option (2), and it may well be slower.  There's a
recommendation that the compiler arrange for a function call to handle
long double instead of issuing the instruction and trapping.

I guess I'm most in favour of option (2), though it means that there's
no 128-bit data type, which sucks a little bit, and HPUX source code is
more difficult to port, which maybe nobody cares about.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] long double

[Ulrich Drepper]

Matthew Wilcox <willy@debian.org> writes:

> (3) Change both gcc and glibc to think that long double is actually
> 128-bits wide.

This is definitely what you should do.  glibc includes now a full set
of 128-bit math functions.  They should be used everywhere the ABI are
not demanding the braindamaged 96-bit format.  Even Alpha, PPC, etc
will change to this when time comes.

> This is almost certainly going to break some packages, and the
> kernel FP support may have to be enhanced to emulate some of the
> opcodes.

Not necessarily.  Look at soft-fp support in glibc.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] long double

[Stan Sieler]

Re:

[(stuff about how big "long double" is)]

> > (3) Change both gcc and glibc to think that long double is actually
> > 128-bits wide.
> 
> This is definitely what you should do.  glibc includes now a full set
> of 128-bit math functions.  They should be used everywhere the ABI are
> not demanding the braindamaged 96-bit format.  Even Alpha, PPC, etc
> will change to this when time comes.


That's why I use: real32, real64, real128 :)

-- 
Stan Sieler                                           sieler@allegro.com
www.allegro.com/sieler/wanted/index.html                  www.sieler.com

Re: [parisc-linux] long double

[John David Anglin]

> gcc currently thinks that `long double' is 64-bits (the same size
> as double).  This is perfectly legitimate, but...

This is only hppa64.  Clearly, this should be 128 bits.  However,
somebody needs to work out the ABI issues and provide a patch to
gcc to support 128 bit long doubles.  At the moment, hppa64 doesn't
even build on the gcc main branch.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)