question float.h & powerpc

question float.h & powerpc

[James Gregurich]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

Hi.

I’m puzzled by the long double settings for powerpc.

bits/float.h has


#define FLT_ROUNDS 1
#define FLT_EVAL_METHOD 0

#define LDBL_TRUE_MIN 4.9406564584124654e-324
#define LDBL_MIN 2.2250738585072014e-308
#define LDBL_MAX 1.7976931348623157e+308
#define LDBL_EPSILON 2.2204460492503131e-16

#define LDBL_MANT_DIG 53
#define LDBL_MIN_EXP (-1021)
#define LDBL_MAX_EXP 1024

#define LDBL_DIG 15
#define LDBL_MIN_10_EXP (-307)
#define LDBL_MAX_10_EXP 308

#define DECIMAL_DIG 17




the clang source code shows

// PPC-LINUX:#define __LDBL_DENORM_MIN__ 4.94065645841246544176568792868221e-324L
// PPC-LINUX:#define __LDBL_DIG__ 31
// PPC-LINUX:#define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L
// PPC-LINUX:#define __LDBL_HAS_DENORM__ 1
// PPC-LINUX:#define __LDBL_HAS_INFINITY__ 1
// PPC-LINUX:#define __LDBL_HAS_QUIET_NAN__ 1
// PPC-LINUX:#define __LDBL_MANT_DIG__ 106
// PPC-LINUX:#define __LDBL_MAX_10_EXP__ 308
// PPC-LINUX:#define __LDBL_MAX_EXP__ 1024
// PPC-LINUX:#define __LDBL_MAX__ 1.79769313486231580793728971405301e+308L
// PPC-LINUX:#define __LDBL_MIN_10_EXP__ (-291)
// PPC-LINUX:#define __LDBL_MIN_EXP__ (-968)
// PPC-LINUX:#define __LDBL_MIN__ 2.00416836000897277799610805135016e-292L


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?

-James

 









[-- Attachment #2: Type: text/html, Size: 5700 bytes --]

Re: question float.h & powerpc

[Rich Felker]

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

Re: question float.h & powerpc

[James Gregurich]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

thanks for the info.

I’m researching the clang docs right now to see how to do it. I don’t understand why the ellcc guys wouldn’t have addressed this already, but I haven’t asked them yet.

Fortunately, I doubt our codebase actually uses double-double, but the toolchain still needs to build correctly so I don’t want to hack it.

On Nov 15, 2013, at 1:42 PM, Rich Felker <dalias@aerifal.cx> wrote:

> GCC has options to easily switch the compiler to using 64-bit long
> double on powerpc. I'm not sure about clang, though.


[-- Attachment #2: Type: text/html, Size: 2316 bytes --]

Re: question float.h & powerpc

[James Gregurich]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]


After digging through llvm source code all day and finding

    if (getTriple().getOS() == llvm::Triple::FreeBSD ||
        getTriple().getVendor() == llvm::Triple::ELLCC) {
      LongDoubleWidth = LongDoubleAlign = 64;
      LongDoubleFormat = &llvm::APFloat::IEEEdouble;
    }


I believe the answer to my question is to build my own llvm 3.4 rather than using Apple’s clang which is based on llvm 3.3 and probably doesn’t have this code in it.




On Nov 15, 2013, at 1:47 PM, James Gregurich <bayoubengal@mac.com> wrote:

> thanks for the info.
> 
> I’m researching the clang docs right now to see how to do it. I don’t understand why the ellcc guys wouldn’t have addressed this already, but I haven’t asked them yet.
> 
> Fortunately, I doubt our codebase actually uses double-double, but the toolchain still needs to build correctly so I don’t want to hack it.
> 
> On Nov 15, 2013, at 1:42 PM, Rich Felker <dalias@aerifal.cx> wrote:
> 
>> GCC has options to easily switch the compiler to using 64-bit long
>> double on powerpc. I'm not sure about clang, though.
> 


[-- Attachment #2: Type: text/html, Size: 3858 bytes --]

Re: question float.h & powerpc

[Szabolcs Nagy]

* James Gregurich <bayoubengal@mac.com> [2013-11-15 16:30:22 -0600]:
> After digging through llvm source code all day and finding
> 
>     if (getTriple().getOS() == llvm::Triple::FreeBSD ||
>         getTriple().getVendor() == llvm::Triple::ELLCC) {
>       LongDoubleWidth = LongDoubleAlign = 64;
>       LongDoubleFormat = &llvm::APFloat::IEEEdouble;
>     }
> 
> 
> I believe the answer to my question is to build my own llvm 3.4 rather than using Apple?s clang which is based on llvm 3.3 and probably doesn?t have this code in it.
> 

seems so, but this is ugly

almost surely there is some configuration method for llvm
and that should have been used to select this option (and
then have different config on freebsd and ellcc)

i think it's wrong of llvm and clang to try to know about
all the users and toolchains of their code and hard-wire
special cases for them (i've seen hacks like that for
emscripten in clang too)

Re: question float.h & powerpc

[James Gregurich]

Sent from my iPad

> On Nov 15, 2013, at 3:42 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> 
> * James Gregurich <bayoubengal@mac.com> [2013-11-15 16:30:22 -0600]:
>> After digging through llvm source code all day and finding
>> 
>>    if (getTriple().getOS() == llvm::Triple::FreeBSD ||
>>        getTriple().getVendor() == llvm::Triple::ELLCC) {
>>      LongDoubleWidth = LongDoubleAlign = 64;
>>      LongDoubleFormat = &llvm::APFloat::IEEEdouble;
>>    }
>> 
>> 
>> I believe the answer to my question is to build my own llvm 3.4 rather than using Apple?s clang which is based on llvm 3.3 and probably doesn?t have this code in it.
> 
> seems so, but this is ugly
> 
> almost surely there is some configuration method for llvm
> and that should have been used to select this option (and
> then have different config on freebsd and ellcc)
> 
> i think it's wrong of llvm and clang to try to know about
> all the users and toolchains of their code and hard-wire
> special cases for them (i've seen hacks like that for
> emscripten in clang too)


 I dug deep for one and finally started going through the source code to find an answer. That is all I found.

He probably should have made the triplet based on musl rather than ell cl..it he changes his c library to one that can handle the double doubles, then he has to change llvm again.

Re: question float.h & powerpc

[Szabolcs Nagy]

* James Gregurich <bayoubengal@mac.com> [2013-11-16 00:56:49 -0800]:
> > i think it's wrong of llvm and clang to try to know about
> > all the users and toolchains of their code and hard-wire
> > special cases for them (i've seen hacks like that for
> > emscripten in clang too)
> 
> 
>  I dug deep for one and finally started going through the source code to find an answer. That is all I found.
> 
> He probably should have made the triplet based on musl rather than ell cl..it he changes his c library to one that can handle the double doubles, then he has to change llvm again.

no, this is llvm's fault (if this is in the upstream repo)

it should be a build time config option so the functionality
can be requested without editing the version controlled source

you should report the bug to them

Re: question float.h & powerpc

[James Gregurich]

Actually, i looked in the version of the code they supplied...not in the official source. I don't know if it is part of he official code base. 

Sent from my iPad

> On Nov 16, 2013, at 4:37 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> 
> * James Gregurich <bayoubengal@mac.com> [2013-11-16 00:56:49 -0800]:
>>> i think it's wrong of llvm and clang to try to know about
>>> all the users and toolchains of their code and hard-wire
>>> special cases for them (i've seen hacks like that for
>>> emscripten in clang too)
>> 
>> 
>> I dug deep for one and finally started going through the source code to find an answer. That is all I found.
>> 
>> He probably should have made the triplet based on musl rather than ell cl..it he changes his c library to one that can handle the double doubles, then he has to change llvm again.
> 
> no, this is llvm's fault (if this is in the upstream repo)
> 
> it should be a build time config option so the functionality
> can be requested without editing the version controlled source
> 
> you should report the bug to them