Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500

[Mathieu Malaterre <malat@debian.org>]

On Sun, Feb 11, 2018 at 4:30 AM, Dennis Clarke <dc@oetec.com> wrote:
>
>>>> This is something that needs to be discussed. A single user alone
>>>> shouldn't
>>>> warrant such major change in a port. You always have to keep in mind
>>>> that
>>>> changing the default compiler options also has potential impact on the
>>>> performance on more modern ppc64 systems like Apple Macintosh.
>>>
>>>
>>>
>>> Not sure how modern an Apple Mac is but here is a photo I took only a
>>>   few minutes ago:
>>>
>>>      https://i.imgur.com/6UbviKb.jpg
>>>
>>>
>>> I have this old Mac G5 running as a fine example of a big-endian machine
>>> and the PPC970MP processors in it seem to work very well. However it is
>>> certainly becoming difficult to get results from it that can compare to
>>> what I get from some other machines like Fujitsu SPARC for example. The
>>> biggest complaint is with floating point wherein the data representation
>>> may be actual IEEE 754-2008 style or some new IBM variant that I am not
>>> at all familiar with. In fact, some code, trivial, won't compile at all
>>> if I try to use "IEEE extended precision long double" with very few ways
>>> to get around that :
>>>
>>> gcc -mcpu=970 -mno-altivec -m64 -std=iso9899:1999 -Wfatal-errors \
>>>     -pedantic-errors -mabi=ieeelongdouble  ...
>>>
>>> The gcc that I am using claims to be :
>>>
>>>    GNU C99 (Debian 7.2.0-17) version 7.2.1 20171205 (powerpc64-linux-gnu)
>>>          compiled by GNU C version 7.2.1 20171205, GMP version 6.1.2,
>>>           MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP
>>>
>>> ... snip ...
>
>
>> This is quite well known, for a long time, IBM on Power (not on
>> mainframes) used a non IEEE format for long doubles. Actually these are
>> two IEEE doubles "concatenated", so:
>> - the mantissa is somewhat less precise, 2 times 53 bits instead of 112
>> - the exponent range is way smaller, in powers of 10 the range is
>>    roughly ±308 (same as double) instead of ±4932.
>
>
> That seems to make sense looking at the in memory values. I can't make
> heads or tails out of it in terms of IEEE754-2008 formats. As for the
> IBM mainframes, well gee, that is a long lost love of mine as I was an
> IBM systems admin for the 3090 MVS/ESA systems and they were a real joy
> with Fortran IV.  A million years ago.
>
>>
>> The fact the the in memory representation is completely different is not
>> surprising when you take this into account.
>>
>> This was somewhat faster than a full emulation of IEEE quad math, but
>> now IBM has switched to real IEEE quad (in hardware even on Power9, I
>> suspect most Sparc do it in software).
>
>
> I can assure you that every sparc does it in software emulation. The
> 64-bit floating point is pure hardware and works very well.
>
>> I'm away from my Power machine right now and it is switched off, so I
>> can't try your code and play with compiler options.
>>
>
> Thank you for getting back to me and I look forwards to seeing what your
> IBM Power system has to say from that code snippit.

One shorted example from SO recently:

const constexpr long double DEGREE_TO_RAD =
0.0174532925199432954743716805978693;
const constexpr long double RAD_TO_DEGREE = 1. / DEGREE_TO_RAD;


https://stackoverflow.com/questions/48553127/error-with-long-doubles-on-powerpc-when-compiling-with-gcc