https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Bug ID: 85440
Summary: libquadmath and quadmath.h do not exist on ppc64
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Seems fairly clear that while the info file does get installed
into share/info/libquadmath.info the actual lib and header do
not exist.
Could be bug 55821 here again.
You can see the testsuite report at :
https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01351.html
The ramifications here seem to be that one can not compile much of
anything that uses the new 128-bit IEEE 754-2008 datatypes on this
platform and any attempt to do so results in :
foo.c:3:10: fatal error: quadmath.h: No such file or directory
#include <quadmath.h>
^~~~~~~~~~~~
compilation terminated.
Any attempt to use the -mabi=ieeelongdouble option results in horrific
results that are no where even remotely close to correct :
nix$ cat ld.c
#define _XOPEN_SOURCE 600
#include <stdio.h>
#include <stdlib.h>
int main ( int argc, char *argv[] ) {
int j;
/* correct 128 bit big endian hex representation of pi is
* 0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */
long double pi = 3.14159265358979323846264338327950288419716939937510L;
printf("\nstack address of variable \"pi\" is %p\n", &pi );
printf("\ncontents : 0x" );
for ( j=0; j<sizeof(long double); j++ )
printf("%02x ", ((unsigned char *)&pi)[j] );
printf("\n" );
printf("%+42.38Lf\n", pi );
printf(" +3.1415926535897932384626433832795028841971 <- pi\n" );
return (EXIT_SUCCESS);
}
nix$
nix$ /usr/local/gcc7/bin/gcc -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970
-maltivec -mfull-toc -mregnames -mabi=ieeelongdouble -o ld ld.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
nix$ ./ld
stack address of variable "pi" is 0x7ffffa5fb8c0
contents : 0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8
+2.07134954084936184770526779175270348787
+3.1415926535897932384626433832795028841971 <- pi
nix$
We can see the obvious error from printf here as well as the
two different representations in the assembly from the use of
the -mabi=ieeelongdouble versus the -mabi=ibmlongdouble :
nix$
nix$ /usr/local/gcc7/bin/gcc -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970
-maltivec -mfull-toc -mregnames -mabi=ibmlongdouble -S -o ld.s ld.c ; grep
"quad" ld.s | grep "0x"
gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
.quad 0x400921fb54442d18,0x3ca1a62633145c06
nix$
nix$ /usr/local/gcc7/bin/gcc -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970
-maltivec -mfull-toc -mregnames -mabi=ieeelongdouble -S -o ld.s ld.c ; grep
"quad" ld.s | grep "0x"
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
.quad 0x4000921fb54442d1,0x8469898cc51701b8
nix$
One of those is clearly correct and the other clearly wrong.
libquadmath was designed to address these sort of cross platform
bizarre issues and gnu libc has implementations for various issues.
Is the real problem gnu libc ?
The GNU C Library version 2.26 is now available
https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
The GNU C Library version 2.27 is now available
https://sourceware.org/ml/libc-announce/2018/msg00000.html
Or perhaps non-IBM Power variations are simply not supported?
