[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131115194225.GD24286@brightrain.aerifal.cx>
Date: Fri, 15 Nov 2013 14:42:25 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: question float.h & powerpc
On Fri, Nov 15, 2013 at 12:25:07PM -0600, James Gregurich wrote:
> Hi.
>
> I’m puzzled by the long double settings for powerpc.
>
> bits/float.h has
> [...]
>
> I believe that LDBL_MANT_DIG of 53 is for an 8 byte long double, but
> powerpc uses 16 byte long doubles and has a LDBL_MANT_DIG value of
> 106. Why is there a discrepancy? I note that the i386 value is
> correct at 64. What do I need to do to reconcile this difference to
> allow the library’s configure script to complete the long double
> test correctly?
This is a complex issue. There are multiple powerpc ABIs; at one point
in the not-so-distant past, everyone was using long double == double
on powerpc. GCC then added an IBM double-double ABI (presumably to
match IBM) and glibc adopted it. musl, however, uses the old long
double definition.
The reasoning behind this is fairly simple: musl aims to always
provide IEEE floating point semantics, and internally _depends_ on
long double having IEEE semantics. IBM double-double, on the other
hand, behaves very badly and does not conform to IEEE requirements. So
supporting the double-double version of 128-bit long double was out of
the question. The alternative, which was considered, was supporting
IEEE quad, which is also 128 bits but has a different representation.
Unfortunately, there's essentially no hardware support for this
format, so it would end up being soft-float, and this would in turn
end up pulling 128-bit (heavy) soft-float code into every single
static binary using printf. Aside from that, the feeling of most
people who contributed to the decision making at the time was that it
only makes sense to have long double larger than double when the
_hardware_ actually provides a floating point type larger than IEEE
double. Using long double as a slow emulated type was deemed a poor
choice. (Note that IBM double-double is also an emulated type, but
it's optimized for being easy to emulate at the expense of providing
correct floating-point semantics.)
In addition to that, I was already diverging musl from the glibc ABI
on powerpc by not supporting the old insecure (runtime-generated code
in writable memory) PLT format for dynamic linking, and only
supporting the new "secure PLT" mode. So being different elsewhere in
the ABI was low-cost.
GCC has options to easily switch the compiler to using 64-bit long
double on powerpc. I'm not sure about clang, though.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
