Bug#895452: gcc-7: libquadmath is disabled for gcc 7.3.0 on powerpc64-linux-gnu
Package: gcc-7 Version: 7.3.0-15 Severity: important Dear Maintainer, * What led up to the situation? Attempt to compile a trivial code test that uses #include as well as _Float128 datatype and quadmath_snprintf() call fails with fatal error: quadmath.h: No such file or directory * What exactly did you do (or not do) that was effective (or ineffective)? Wrote a trivial piece of test code and then issued a compile : $ gcc -mcpu=970 -mno-altivec -g -m64 -std=c99 -pedantic-errors -o s s.c s.c:82:10: fatal error: quadmath.h: No such file or directory #include ^~~~ compilation terminated. * What was the outcome of this action? Compile can not proceed. * What outcome did you expect instead? Expected a trivial to compile to generate pre-processed intermediate file and then assembly and then an object file and then a final ELF executable file that runs as expected. -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: ppc64 Kernel: Linux 4.15.0-2-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_CA:en (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-7 depends on: ii binutils 2.30-15 ii cpp-7 7.3.0-15 ii gcc-7-base7.3.0-15 ii libc6 2.27-3 ii libcc1-0 8-20180402-1 ii libgcc-7-dev 7.3.0-15 ii libgcc1 1:8-20180402-1 ii libgmp10 2:6.1.2+dfsg-3 ii libisl19 0.19-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.1-1 ii libstdc++68-20180402-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.27-3 Versions of packages gcc-7 suggests: pn gcc-7-doc pn gcc-7-locales ii gcc-7-multilib7.3.0-15 pn libasan4-dbg pn libatomic1-dbg pn libcilkrts5-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information
Bug#895452: gcc-7: libquadmath is disabled for gcc 7.3.0 on powerpc64-linux-gnu
On 11/04/18 04:52 PM, Matthias Klose wrote: On 11.04.2018 19:04, Dennis Clarke wrote: Package: gcc-7 Version: 7.3.0-15 Severity: important Dear Maintainer, * What led up to the situation? Attempt to compile a trivial code test that uses #include as well as _Float128 datatype and quadmath_snprintf() call fails with fatal error: quadmath.h: No such file or directory I have dark memories, that quadmath didn't build. Please could you check that again with a native build and a cross build, if you have access to a ppc64 platform? I am working on it. I need to get past some new silly dependency that makes little sense given that the bootstrap fails in stage 3 of all places : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 So I should ( in theory ) be able to build the gc code in place and in the tree in the same manner as gmp, mpfr, mpc and isl. So I am working on that but it just isn't working. In any case I'll get the sources from http://www.hboehm.info/gc/ and keep hacking at this on ppc64. Dennis
Bug#895452: libquadmath and quadmath.h do not exist on ppc64
New GCC bigid is being flipped around by Jakub Jelinek ( Red Hat ) who claims this issue is fixed for ppc64 in GCC version 8 that does not exist anywhere. Not even in the git repo. I am trying to figure out what is going on here. see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 What a mess .. seems like a new secret gcc codebase exists somewhere and no one can see it. Dennis
Bug#895452: libquadmath and quadmath.h do not exist on ppc64
I will test gcc-8-20180415 and see what results I get.
Bug#895452: some progress bootstrap completes for gcc 7.3.0
Managed a bootstrap that didn't blow up. At the moment the assembly output from a trivial test shows that the IBM extended precision long double type is the default unless one actually asks for the IEEE754-2008 128-bit datatype. dclarke@nix:~/pgm/C/ieee754$ PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH xgcc -I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc -mregnames -mabi=ieeelongdouble -S -o ld.s ld.c xgcc: warning: using IEEE extended precision long double cc1: warning: using IEEE extended precision long double dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x" .quad 0x4000921fb54442d1,0x8469898cc51701b8 That data is correct. dclarke@nix:~/pgm/C/ieee754$ PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH xgcc -I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc -mregnames -mabi=ibmlongdouble -S -o ld.s ld.c xgcc: warning: using IBM extended precision long double cc1: warning: using IBM extended precision long double dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x" .quad 0x400921fb54442d18,0x3ca1a62633145c06 That is a whole other beast of a different colour. dclarke@nix:~/pgm/C/ieee754$ PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH xgcc -I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc -mregnames -S -o ld.s ld.c dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x" .quad 0x400921fb54442d18,0x3ca1a62633145c06 dclarke@nix:~/pgm/C/ieee754$ So the default is the IBM type. No idea on the libquadmath yet. I should have more info on this issue in another 16 or 20 hours. Dennis
