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

[Bas Vermeulen]

Enabling CONFIG_MATH_EMULATION and CONFIG_MATH_EMULATION_HW_UNIMPLEMENTED
configuration options in the kernel fixes this problem without changes to
gcc-7/gcc-8.
This makes unstable run on the e6500 (and probably the e5500 as well)
without a problem.

Sorry about the scare, I should have looked for emulation options earlier.

Bas Vermeulen

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

[Mathieu Malaterre]

On Sun, Feb 11, 2018 at 4:30 AM, Dennis Clarke  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

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

[Dennis Clarke]

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.

Dennis

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

[Gabriel Paubert]

On Sat, Feb 10, 2018 at 04:02:36PM -0500, Dennis Clarke wrote:
> On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:
> > On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
> > > mator on #debian-ports compiled gcc-7 for me with the attached patch.
> > > With the resulting gcc, I compiled glibc and got a library I can use
> > > sqrtf without running into an illegal instruction exception.
> > > 
> > > Would it be possible to get this applied by default? The resulting
> > > binaries work on e6500, and ought to work on all supported CPUs
> > > for the ppc64 port.
> > 
> > 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
> 
> 
> I can take the exact same source of a trivial floating point test and
> drop it on very very old sparc as well as a system running very up to
> date Red Hat Enterprise Linux 7.4 with AMD Opterons.  Also this old mac
> g5 with its PPC970MP processors where I see wildly different results on
> all of them.  When I say "wildly" I mean to say that the in memory data
> isn't even remotely the same given the same constant inputs. I know that
> the x86 hardware is somewhat crippled ( a strange ten byte format ) in
> this regard but I was quite surprised by what happens on the PPC970MP
> processors when compared to sparc.  Regardless what compiler I use on
> the sparc ( very very old Sun and much newer Fujitsu ) with Solaris 10
> I always get nearly perfect results. The Debian PPC970MP produces close
> results but again the in memory data is quite different.
> 
> In any case there are people out there messing with these things for
> various reasons ( educational even in that I do teach ) and it is quite
> weird to have to say to a student that in the year 2018 don't expect
> similar results across different machines when it comes to doing any
> floating point math.
> 
> Dennis
> 
> ps: long boring stuff follows where numbers don't quite work
>  and libquadmath seems to be out of the question.

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.

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). 

For more details, you may have a look at:
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format
there is even a full paragraph on the double-double arithmetic.

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.

Cheers,
Gabriel

> 
> - feel free to compile this on anything and show results --
> 
> #define _XOPEN_SOURCE 600
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main (int argc, char* argv[]){
> 
> int j;
> struct utsname uname_data;
> long double theta, pi, approx_pi, one_over_sqrt2, ld_error;
> 
> setlocale( LC_MESSAGES, "C" );
> if ( uname( _data ) < 0 ) {
> fprintf ( stderr,
>  "WARNING : Could not attain system uname data.\n" );
> perror ( "uname" );
> } else {
> printf ("system name = %s\n", uname_data.sysname );
> printf ("  node name = %s\n", 

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

[Dennis Clarke]

On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:

On 02/09/2018 11:30 AM, Bas Vermeulen wrote:

mator on #debian-ports compiled gcc-7 for me with the attached patch.
With the resulting gcc, I compiled glibc and got a library I can use
sqrtf without running into an illegal instruction exception.

Would it be possible to get this applied by default? The resulting
binaries work on e6500, and ought to work on all supported CPUs
for the ppc64 port.


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


I can take the exact same source of a trivial floating point test and
drop it on very very old sparc as well as a system running very up to
date Red Hat Enterprise Linux 7.4 with AMD Opterons.  Also this old mac
g5 with its PPC970MP processors where I see wildly different results on
all of them.  When I say "wildly" I mean to say that the in memory data
isn't even remotely the same given the same constant inputs. I know that
the x86 hardware is somewhat crippled ( a strange ten byte format ) in
this regard but I was quite surprised by what happens on the PPC970MP
processors when compared to sparc.  Regardless what compiler I use on
the sparc ( very very old Sun and much newer Fujitsu ) with Solaris 10
I always get nearly perfect results. The Debian PPC970MP produces close
results but again the in memory data is quite different.

In any case there are people out there messing with these things for
various reasons ( educational even in that I do teach ) and it is quite
weird to have to say to a student that in the year 2018 don't expect
similar results across different machines when it comes to doing any
floating point math.

Dennis

ps: long boring stuff follows where numbers don't quite work
 and libquadmath seems to be out of the question.

- feel free to compile this on anything and show results --

#define _XOPEN_SOURCE 600

#include 
#include 
#include 
#include 
#include 

int main (int argc, char* argv[]){

int j;
struct utsname uname_data;
long double theta, pi, approx_pi, one_over_sqrt2, ld_error;

setlocale( LC_MESSAGES, "C" );
if ( uname( _data ) < 0 ) {
fprintf ( stderr,
 "WARNING : Could not attain system uname data.\n" );
perror ( "uname" );
} else {
printf ("system name = %s\n", uname_data.sysname );
printf ("  node name = %s\n", uname_data.nodename );
printf ("release = %s\n", uname_data.release );
printf ("version = %s\n", uname_data.version );
printf ("machine = %s\n", uname_data.machine );
}
printf ("\n");

/* plenty of digits well past the precision of binary128 */
pi = 3.1415926535897932384626433832795028841971693993751L;

printf("sizeof(long double) = %2i\n", sizeof(long double));
printf("  pi may be %+40.38Lf\n", pi);
printf("reference val = ");
printf("+3.1415926535897932384626433832795028841971693993751\n\n");

printf("%p : ", );
for ( j=0; j

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

[Lennart Sorensen]

On Fri, Feb 09, 2018 at 11:34:12AM +0100, John Paul Adrian Glaubitz 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.
> 
> So, while I'm generally not against such a change, I would like to hear
> some voices first.

Without this change, you have to declare officially that e6500 and e5500
are simply not supported CPUs.

-- 
Len Sorensen

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

[Mathieu Malaterre]

Hi all,

On Fri, Feb 9, 2018 at 1:12 PM, Luuk van Dijk  wrote:
> I apologize for the 'reply in 48 hours' spam my extcontacts mailinglist
> caused for any of you that replied here.  I asked bas to keep us posted but
> i didn't realize it would send this out.  I switched it off.
>
> thanks for all your hard work.
>
> /Luuk
>
> On Fri, Feb 9, 2018 at 12:56 PM Bas Vermeulen  wrote:
>>
>> diff of gcc -dM -E - without and with the patch applied:
>>
>> --- gcc-default 2018-01-28 18:06:14.11600 +
>> +++ gcc-powerpc64 2018-01-28 18:03:06.57200 +
>> @@ -34,7 +34,6 @@
>>  #define __FLT64_DECIMAL_DIG__ 17
>>  #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
>>  #define pixel pixel
>> -#define _ARCH_PPCSQ 1
>>  #define bool bool
>>  #define __UINT_FAST64_MAX__ 0xUL
>>  #define __SIG_ATOMIC_TYPE__ int
>> @@ -78,7 +77,6 @@
>>  #define __USER_LABEL_PREFIX__
>>  #define __STDC_HOSTED__ 1
>>  #define __LDBL_HAS_INFINITY__ 1
>> -#define _ARCH_PWR4 1
>>  #define __builtin_vsx_xvmaddmsp __builtin_vsx_xvmaddsp
>>  #define __CMODEL_MEDIUM__ 1
>>  #define __FLT32_DIG__ 6
>>
>> gcc -Q --help=target (default vs with the patch applied):
>>
>> --- gcc-Q-default 2018-01-28 18:08:29.23200 +
>> +++ gcc-Q-powerpc64 2018-01-28 18:07:39.98400 +
>> @@ -35,7 +35,7 @@
>>-mcmodel=medium
>>-mcmpb  [disabled]
>>-mcompat-align-parm  [disabled]
>> -  -mcpu=  [default]
>> +  -mcpu=  powerpc64
>>-mcrypto[disabled]
>>-mdebug=
>>-mdirect-move[disabled]
>> @@ -70,7 +70,7 @@
>>-mlong-double-128
>>-mlongcall  [disabled]
>>-mlra[enabled]
>> -  -mmfcrf  [enabled]
>> +  -mmfcrf  [disabled]
>>-mmfpgpr[disabled]
>>-mminimal-toc[disabled]
>>-mmodulo[disabled]
>> @@ -89,7 +89,7 @@
>>-mpointers-to-nested-functions [enabled]
>>-mpopcntb[disabled]
>>-mpopcntd[disabled]
>> -  -mpower8-fusion  [enabled]
>> +  -mpower8-fusion  [disabled]
>>-mpower8-fusion-sign[disabled]
>>-mpower8-vector  [disabled]
>>-mpower9-dform  [enabled]
>> @@ -101,9 +101,9 @@
>>-mpower9-vector  [disabled]
>>-mpowerpc
>>-mpowerpc-gfxopt[enabled]
>> -  -mpowerpc-gpopt  [enabled]
>> +  -mpowerpc-gpopt  [disabled]
>>-mpowerpc64  [enabled]
>> -  -mprioritize-restricted-insns= 1
>> +  -mprioritize-restricted-insns= 0
>>-mprofile-kernel[disabled]
>>-mprototype  [disabled]
>>-mquad-memory[disabled]
>> @@ -145,7 +145,7 @@
>>-mtoc[disabled]
>>-mtoc-fusion[disabled]
>>-mtraceback=[default]
>> -  -mtune=  [default]
>> +  -mtune=  powerpc64
>>-muclibc[disabled]
>>-mupdate[enabled]
>>-mupper-regs[enabled]

The diff looks a bit odd to me, I do not understand why we would be
moving away from the default mtune. Anyway you have my vote. I know
Adrian gets sometime inspiration from fedora team, maybe time to reach
a consensus with them also. IBM seems to be going toward ppc64el
anyway, so I believe that should not affect too many people.

2cts,
-M

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

[Bas Vermeulen]

Taking extcont...@daedalean.ai out of the cc list (it has an auto replay I
didn't know about, sorry).

Bas Vermeulen

On Fri, Feb 9, 2018 at 12:56 PM, Bas Vermeulen  wrote:

> diff of gcc -dM -E - without and with the patch applied:
>
> --- gcc-default 2018-01-28 18:06:14.11600 +
> +++ gcc-powerpc64 2018-01-28 18:03:06.57200 +
> @@ -34,7 +34,6 @@
>  #define __FLT64_DECIMAL_DIG__ 17
>  #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
>  #define pixel pixel
> -#define _ARCH_PPCSQ 1
>  #define bool bool
>  #define __UINT_FAST64_MAX__ 0xUL
>  #define __SIG_ATOMIC_TYPE__ int
> @@ -78,7 +77,6 @@
>  #define __USER_LABEL_PREFIX__
>  #define __STDC_HOSTED__ 1
>  #define __LDBL_HAS_INFINITY__ 1
> -#define _ARCH_PWR4 1
>  #define __builtin_vsx_xvmaddmsp __builtin_vsx_xvmaddsp
>  #define __CMODEL_MEDIUM__ 1
>  #define __FLT32_DIG__ 6
>
> gcc -Q --help=target (default vs with the patch applied):
>
> --- gcc-Q-default 2018-01-28 18:08:29.23200 +
> +++ gcc-Q-powerpc64 2018-01-28 18:07:39.98400 +
> @@ -35,7 +35,7 @@
>-mcmodel=medium
>-mcmpb  [disabled]
>-mcompat-align-parm  [disabled]
> -  -mcpu=  [default]
> +  -mcpu=  powerpc64
>-mcrypto[disabled]
>-mdebug=
>-mdirect-move[disabled]
> @@ -70,7 +70,7 @@
>-mlong-double-128
>-mlongcall  [disabled]
>-mlra[enabled]
> -  -mmfcrf  [enabled]
> +  -mmfcrf  [disabled]
>-mmfpgpr[disabled]
>-mminimal-toc[disabled]
>-mmodulo[disabled]
> @@ -89,7 +89,7 @@
>-mpointers-to-nested-functions [enabled]
>-mpopcntb[disabled]
>-mpopcntd[disabled]
> -  -mpower8-fusion  [enabled]
> +  -mpower8-fusion  [disabled]
>-mpower8-fusion-sign[disabled]
>-mpower8-vector  [disabled]
>-mpower9-dform  [enabled]
> @@ -101,9 +101,9 @@
>-mpower9-vector  [disabled]
>-mpowerpc
>-mpowerpc-gfxopt[enabled]
> -  -mpowerpc-gpopt  [enabled]
> +  -mpowerpc-gpopt  [disabled]
>-mpowerpc64  [enabled]
> -  -mprioritize-restricted-insns= 1
> +  -mprioritize-restricted-insns= 0
>-mprofile-kernel[disabled]
>-mprototype  [disabled]
>-mquad-memory[disabled]
> @@ -145,7 +145,7 @@
>-mtoc[disabled]
>-mtoc-fusion[disabled]
>-mtraceback=[default]
> -  -mtune=  [default]
> +  -mtune=  powerpc64
>-muclibc[disabled]
>-mupdate[enabled]
>-mupper-regs[enabled]
>
> Bas Vermeulen
>

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

[Bas Vermeulen]

diff of gcc -dM -E - without and with the patch applied:

--- gcc-default 2018-01-28 18:06:14.11600 +
+++ gcc-powerpc64 2018-01-28 18:03:06.57200 +
@@ -34,7 +34,6 @@
 #define __FLT64_DECIMAL_DIG__ 17
 #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
 #define pixel pixel
-#define _ARCH_PPCSQ 1
 #define bool bool
 #define __UINT_FAST64_MAX__ 0xUL
 #define __SIG_ATOMIC_TYPE__ int
@@ -78,7 +77,6 @@
 #define __USER_LABEL_PREFIX__
 #define __STDC_HOSTED__ 1
 #define __LDBL_HAS_INFINITY__ 1
-#define _ARCH_PWR4 1
 #define __builtin_vsx_xvmaddmsp __builtin_vsx_xvmaddsp
 #define __CMODEL_MEDIUM__ 1
 #define __FLT32_DIG__ 6

gcc -Q --help=target (default vs with the patch applied):

--- gcc-Q-default 2018-01-28 18:08:29.23200 +
+++ gcc-Q-powerpc64 2018-01-28 18:07:39.98400 +
@@ -35,7 +35,7 @@
   -mcmodel=medium
   -mcmpb  [disabled]
   -mcompat-align-parm  [disabled]
-  -mcpu=  [default]
+  -mcpu=  powerpc64
   -mcrypto[disabled]
   -mdebug=
   -mdirect-move[disabled]
@@ -70,7 +70,7 @@
   -mlong-double-128
   -mlongcall  [disabled]
   -mlra[enabled]
-  -mmfcrf  [enabled]
+  -mmfcrf  [disabled]
   -mmfpgpr[disabled]
   -mminimal-toc[disabled]
   -mmodulo[disabled]
@@ -89,7 +89,7 @@
   -mpointers-to-nested-functions [enabled]
   -mpopcntb[disabled]
   -mpopcntd[disabled]
-  -mpower8-fusion  [enabled]
+  -mpower8-fusion  [disabled]
   -mpower8-fusion-sign[disabled]
   -mpower8-vector  [disabled]
   -mpower9-dform  [enabled]
@@ -101,9 +101,9 @@
   -mpower9-vector  [disabled]
   -mpowerpc
   -mpowerpc-gfxopt[enabled]
-  -mpowerpc-gpopt  [enabled]
+  -mpowerpc-gpopt  [disabled]
   -mpowerpc64  [enabled]
-  -mprioritize-restricted-insns= 1
+  -mprioritize-restricted-insns= 0
   -mprofile-kernel[disabled]
   -mprototype  [disabled]
   -mquad-memory[disabled]
@@ -145,7 +145,7 @@
   -mtoc[disabled]
   -mtoc-fusion[disabled]
   -mtraceback=[default]
-  -mtune=  [default]
+  -mtune=  powerpc64
   -muclibc[disabled]
   -mupdate[enabled]
   -mupper-regs[enabled]

Bas Vermeulen

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

[Christian Zigotzky]

We need this change too. We have e5500 CPU’s in our AmigaOnes.

— Christian 

Sent from my iPhone

> On 9. Feb 2018, at 11:34, John Paul Adrian Glaubitz 
>  wrote:
> 
>> On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
>> mator on #debian-ports compiled gcc-7 for me with the attached patch.
>> With the resulting gcc, I compiled glibc and got a library I can use
>> sqrtf without running into an illegal instruction exception.
>> Would it be possible to get this applied by default? The resulting
>> binaries work on e6500, and ought to work on all supported CPUs
>> for the ppc64 port.
> 
> 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.
> 
> So, while I'm generally not against such a change, I would like to hear
> some voices first.
> 
> Thanks,
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

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

[Mathieu Malaterre]

On Fri, Feb 9, 2018 at 11:34 AM, John Paul Adrian Glaubitz
 wrote:
> On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
>>
>> mator on #debian-ports compiled gcc-7 for me with the attached patch.
>> With the resulting gcc, I compiled glibc and got a library I can use
>> sqrtf without running into an illegal instruction exception.
>>
>> Would it be possible to get this applied by default? The resulting
>> binaries work on e6500, and ought to work on all supported CPUs
>> for the ppc64 port.
>
>
> 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.
>
> So, while I'm generally not against such a change, I would like to hear
> some voices first.

uh, could someone please actually list the diff ? I am guessing something like:

$ echo | gcc -dM -E -

or maybe:

$ gcc  -Q --help=target

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

[John Paul Adrian Glaubitz]

On 02/09/2018 11:30 AM, Bas Vermeulen wrote:

mator on #debian-ports compiled gcc-7 for me with the attached patch.
With the resulting gcc, I compiled glibc and got a library I can use
sqrtf without running into an illegal instruction exception.

Would it be possible to get this applied by default? The resulting
binaries work on e6500, and ought to work on all supported CPUs
for the ppc64 port.


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.

So, while I'm generally not against such a change, I would like to hear
some voices first.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Bas Vermeulen]

Hi,

mator on #debian-ports compiled gcc-7 for me with the attached patch. With
the resulting gcc, I compiled glibc and got a library I can use sqrtf
without running into an illegal instruction exception.

Would it be possible to get this applied by default? The resulting binaries
work on e6500, and ought to work on all supported CPUs for the ppc64 port.

Bas Vermeulen


On Tue, Feb 6, 2018 at 7:35 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 02/06/2018 07:29 PM, Bas Vermeulen wrote:
> > I get that. But configure in the gcc sources doesn't actually process
> those. So while they are in rules2, it doesn't actually change anything.
> >
> > See https://github.com/gcc-mirror/gcc/blob/
> da8dff89fa9398f04b107e388cb706517ced9505/configure and search for
> with-cpu (which would catch both --with-cpu-32 and
> > --with-cpu-64), and you won't find it there.
>
> I really don't think that Matthias Klose had put those there without
> testing.
>
> "--with-cpu-*" is a common configure switch supported by gcc across all
> architectures. We use it on sparc64 as well, for example to set the
> default CPU to UltraSPARC for 32-bit sparc.
>
> Also, you're looking at the wrong file. It's in gcc/gcc/config.gcc:
>
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
--- debian/rules2.orig	2018-02-08 13:05:05.493117248 +0100
+++ debian/rules2	2018-02-08 13:04:17.870348206 +0100
@@ -388,6 +388,8 @@
 endif
 ifeq ($(derivative),Ubuntu)
   CONFARGS += --with-cpu-32=power7 --with-cpu-64=power7
+else
+  CONFARGS += --with-cpu-32=powerpc --with-cpu-64=powerpc64
 endif
 endif
 

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

[John Paul Adrian Glaubitz]

On 02/06/2018 07:29 PM, Bas Vermeulen wrote:
> I get that. But configure in the gcc sources doesn't actually process those. 
> So while they are in rules2, it doesn't actually change anything.
> 
> See 
> https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/configure
>  and search for with-cpu (which would catch both --with-cpu-32 and
> --with-cpu-64), and you won't find it there.

I really don't think that Matthias Klose had put those there without testing.

"--with-cpu-*" is a common configure switch supported by gcc across all
architectures. We use it on sparc64 as well, for example to set the
default CPU to UltraSPARC for 32-bit sparc.

Also, you're looking at the wrong file. It's in gcc/gcc/config.gcc:

> https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Bas Vermeulen]

I get that. But configure in the gcc sources doesn't actually process
those. So while they are in rules2, it doesn't actually change anything.

See
https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/configure
and search for with-cpu (which would catch both --with-cpu-32 and
--with-cpu-64), and you won't find it there.

Bas Vermeulen

On Tue, Feb 6, 2018 at 7:25 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 02/06/2018 07:22 PM, Bas Vermeulen wrote:
> > I just checked gcc's configure, and that doesn't take --with-cpu= as an
> argument. It doesn't fail when it has it, but it doesn't actually do
> anything with it
> > either.
> > So my patch would be the correct way to handle this.
>
> That's because you have to use --with-cpu-32 and --with-cpu-64, see:
>
> > https://sources.debian.org/src/gcc-7/7.3.0-1/debian/rules2/#L390
>
> It's in the very same file I linked :).
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

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

[Lennart Sorensen]

On Tue, Feb 06, 2018 at 06:58:55PM +0100, John Paul Adrian Glaubitz wrote:
> It would be nice if anyone who cares about the ppc64 could actually
> post what kind of hardware they have. We should find a consensus on
> where to put the baseline.

Well at least the CPUs listed on https://wiki.debian.org/PPC64 would
be nice.  Either that or make the page match what is really supported.

> Rebuilding the whole archive isn't so much of a problem. We have already
> done that :).

Yeah at least there are some pretty fast PPC64 build boxes.

And it might be possible to scan the binaries for unsupported instructions
and just rebuild those packages, but it might not be worth the bother.

-- 
Len Sorensen

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

[John Paul Adrian Glaubitz]

On 02/06/2018 07:22 PM, Bas Vermeulen wrote:
> I just checked gcc's configure, and that doesn't take --with-cpu= as an 
> argument. It doesn't fail when it has it, but it doesn't actually do anything 
> with it
> either.
> So my patch would be the correct way to handle this.

That's because you have to use --with-cpu-32 and --with-cpu-64, see:

> https://sources.debian.org/src/gcc-7/7.3.0-1/debian/rules2/#L390

It's in the very same file I linked :).

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Bas Vermeulen]

I just checked gcc's configure, and that doesn't take --with-cpu= as an
argument. It doesn't fail when it has it, but it doesn't actually do
anything with it either.
So my patch would be the correct way to handle this.

Bas Vermeulen

On Tue, Feb 6, 2018 at 6:58 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 02/06/2018 06:03 PM, Bas Vermeulen wrote:
> > Mostly because I didn't know/think of that. But you are right, that
> would be better.
>
> So, the file you want to modify is:
>
> > https://sources.debian.org/src/gcc-7/7.3.0-1/debian/rules2/#L380-L392
>
> It would be nice if anyone who cares about the ppc64 could actually
> post what kind of hardware they have. We should find a consensus on
> where to put the baseline.
>
> Rebuilding the whole archive isn't so much of a problem. We have already
> done that :).
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

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

[John Paul Adrian Glaubitz]

On 02/06/2018 06:03 PM, Bas Vermeulen wrote:
> Mostly because I didn't know/think of that. But you are right, that would be 
> better.

So, the file you want to modify is:

> https://sources.debian.org/src/gcc-7/7.3.0-1/debian/rules2/#L380-L392

It would be nice if anyone who cares about the ppc64 could actually
post what kind of hardware they have. We should find a consensus on
where to put the baseline.

Rebuilding the whole archive isn't so much of a problem. We have already
done that :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Bas Vermeulen]

Mostly because I didn't know/think of that. But you are right, that would
be better.

Bas Vermeulen

On Tue, Feb 6, 2018 at 5:48 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

>
>
> On Feb 6, 2018, at 5:26 PM, Bas Vermeulen  wrote:
>
> I am evaluating the following patch to gcc-7 to fix the problem. It's
> currently building, I'll follow up when I know it works. The patch is added
> to debian/rules.patch to get it included.
>
>
> Why do you want to patch the upstream sources when you could just modify
> debian/rules2 to pass the proper “—with-cpu=powerpc64” to gcc’s configure
> script?
>
> Adrian
>
> Bas Vermeulen
>
> On Tue, Feb 6, 2018 at 5:16 PM, Lennart Sorensen <
> lsore...@csclub.uwaterloo.ca> wrote:
>
>> On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
>> > I am trying to run the ppc64 unstable on a Freescale T2080, which uses
>> the
>> > e6500 CPU. Running python (or any other application using sqrt or sqrtf)
>> > will cause an illegal instruction exception, because the sqrtf opcode is
>> > not supported on the e6500.
>> >
>> > This seems to be caused by gcc compiling for power4 by default
>> > (_ARCH_PWR4=1 and _ARCH_PPCSQ=1 set in gcc -E -mD - < /dev/null),
>> although
>> > jrtc27 on #debian-ports pointed to
>> > https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107
>> e388cb706517ced9505/gcc/config/rs6000/default64.h#L30
>> > which sets MASK_PPC_GPOPT by default (which includes fp sqrt).
>> >
>> > What would be the best way to solve this problem?
>>
>> Why is the default not powerpc64 instead of power4?  After all that is
>> the setting for generic 64 bit bit endian powerpc as far as I know.
>>
>> It seems the e6500 is missing quite a few floating point instructions
>> from the Power ISA so targeting power4 (which is I believe full Power
>> ISA 2.01) is likely to cause issues.
>>
>> --
>> Len Sorensen
>>
>
> 
>
>

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

[John Paul Adrian Glaubitz]

> On Feb 6, 2018, at 5:26 PM, Bas Vermeulen  wrote:
> 
> I am evaluating the following patch to gcc-7 to fix the problem. It's 
> currently building, I'll follow up when I know it works. The patch is added 
> to debian/rules.patch to get it included.

Why do you want to patch the upstream sources when you could just modify 
debian/rules2 to pass the proper “—with-cpu=powerpc64” to gcc’s configure 
script?

Adrian

> Bas Vermeulen
> 
>> On Tue, Feb 6, 2018 at 5:16 PM, Lennart Sorensen 
>>  wrote:
>> On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
>> > I am trying to run the ppc64 unstable on a Freescale T2080, which uses the
>> > e6500 CPU. Running python (or any other application using sqrt or sqrtf)
>> > will cause an illegal instruction exception, because the sqrtf opcode is
>> > not supported on the e6500.
>> >
>> > This seems to be caused by gcc compiling for power4 by default
>> > (_ARCH_PWR4=1 and _ARCH_PPCSQ=1 set in gcc -E -mD - < /dev/null), although
>> > jrtc27 on #debian-ports pointed to
>> > https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/gcc/config/rs6000/default64.h#L30
>> > which sets MASK_PPC_GPOPT by default (which includes fp sqrt).
>> >
>> > What would be the best way to solve this problem?
>> 
>> Why is the default not powerpc64 instead of power4?  After all that is
>> the setting for generic 64 bit bit endian powerpc as far as I know.
>> 
>> It seems the e6500 is missing quite a few floating point instructions
>> from the Power ISA so targeting power4 (which is I believe full Power
>> ISA 2.01) is likely to cause issues.
>> 
>> --
>> Len Sorensen
> 
> 

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

[Lennart Sorensen]

On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
> I am trying to run the ppc64 unstable on a Freescale T2080, which uses the
> e6500 CPU. Running python (or any other application using sqrt or sqrtf)
> will cause an illegal instruction exception, because the sqrtf opcode is
> not supported on the e6500.
> 
> This seems to be caused by gcc compiling for power4 by default
> (_ARCH_PWR4=1 and _ARCH_PPCSQ=1 set in gcc -E -mD - < /dev/null), although
> jrtc27 on #debian-ports pointed to
> https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/gcc/config/rs6000/default64.h#L30
> which sets MASK_PPC_GPOPT by default (which includes fp sqrt).
> 
> What would be the best way to solve this problem?

Why is the default not powerpc64 instead of power4?  After all that is
the setting for generic 64 bit bit endian powerpc as far as I know.

It seems the e6500 is missing quite a few floating point instructions
from the Power ISA so targeting power4 (which is I believe full Power
ISA 2.01) is likely to cause issues.

-- 
Len Sorensen

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

[Bas Vermeulen]

I am evaluating the following patch to gcc-7 to fix the problem. It's
currently building, I'll follow up when I know it works. The patch is added
to debian/rules.patch to get it included.

Bas Vermeulen

On Tue, Feb 6, 2018 at 5:16 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
> > I am trying to run the ppc64 unstable on a Freescale T2080, which uses
> the
> > e6500 CPU. Running python (or any other application using sqrt or sqrtf)
> > will cause an illegal instruction exception, because the sqrtf opcode is
> > not supported on the e6500.
> >
> > This seems to be caused by gcc compiling for power4 by default
> > (_ARCH_PWR4=1 and _ARCH_PPCSQ=1 set in gcc -E -mD - < /dev/null),
> although
> > jrtc27 on #debian-ports pointed to
> > https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706
> 517ced9505/gcc/config/rs6000/default64.h#L30
> > which sets MASK_PPC_GPOPT by default (which includes fp sqrt).
> >
> > What would be the best way to solve this problem?
>
> Why is the default not powerpc64 instead of power4?  After all that is
> the setting for generic 64 bit bit endian powerpc as far as I know.
>
> It seems the e6500 is missing quite a few floating point instructions
> from the Power ISA so targeting power4 (which is I believe full Power
> ISA 2.01) is likely to cause issues.
>
> --
> Len Sorensen
>
--- a/src/gcc/config/rs6000/default64.h 2018-02-06 15:52:53.0 +
+++ b/src/gcc/config/rs6000/default64.h 2018-02-06 15:53:10.0 +
@@ -27,5 +27,5 @@
 #define TARGET_DEFAULT (ISA_2_7_MASKS_SERVER | MASK_POWERPC64 | MASK_64BIT | 
MASK_LITTLE_ENDIAN)
 #else
 #undef TARGET_DEFAULT
-#define TARGET_DEFAULT (MASK_PPC_GFXOPT | MASK_PPC_GPOPT | MASK_MFCRF | 
MASK_POWERPC64 | MASK_64BIT)
+#define TARGET_DEFAULT (MASK_PPC_GFXOPT | MASK_POWERPC64 | MASK_64BIT)
 #endif