[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #22 from Jakub Jelinek --- (In reply to Sergey Fedorov from comment #21) > On ppc64 (970) it probably is supported. No, it is not.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #21 from Sergey Fedorov --- (In reply to Jakub Jelinek from comment #15) > For libquadmath you need a working __float128 support. On x86_64, i686 and > ia64 this is done through a slow software emulation in libgcc. On powerpc*, > there is either a software emulation which requires VSX, or hardware > implementation which requires power9. On ppc64 (970) it probably is supported.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #20 from Michael Meissner ---
I'm sorry long double doesn't seem to work on your system. If your system does
not have the appropriate long double libraries, you probably need to use the
--with-long-double-64 option to make long double use the double type. Or you
(or somebody else using the system) need to submit patches, so the compiler
calls whatever is the names of the long double emulation on your system.
With the current compiler, as has been stated, we cannot build libquadmath
unless __float128 is supported. Right now, the only support is for the
following systems:
1) Little endian power8/9 systems
2) Big endian power7/8/9 systems where you use the --with-cpu= option,
where is power7, power8, or power9.
There just isn't support for a IEEE 128-bit floating point type, unless you
have the VSX (vector scalar extensions) that were first introduced in power7.
The __gcc_q{add,sub,mul,div} come from the libgcc/config/rs6000/ibm-ldouble.c
file. Perhaps it is not configured for your system.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #19 from Dennis Clarke ---
status : RESOLVED FIXED <-- seems to not apply.
For the sake of showing how there really is a problem here, we can
neatly compile some trivial code and get bizarre results simply
because the platform would prefer to use the non-standard IBM long
double data type. Any attempt to "add" two long doubles will result
in a call to _q_add which doesn't exist and ld fails.
ppc64$ cat foo.c
#define _XOPEN_SOURCE 600
#include
#include
#include
#include
#include
int main ( int argc, char *argv[] ) {
int j;
struct utsname uname_data;
long double pi = 3.14159265358979323846264338327950288419716939937510L;
long double one = 1.0L;
long double two = 2.0L;
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");
/* 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 */
printf("\naddr \"pi\" is %p\n", );
printf("\ncontents : " );
for ( j=0; j -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ieeelongdouble -o foo foo.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
ppc64$
ppc64$ ./foo
system name = Linux
node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64
addr "pi" is 0x7fffe4399650
contents : 40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8
+2.07134954084936184770526779175270348787
+3.1415926535897932384626433832795028841971 <- pi
addr "one" is 0x7fffe4399660
contents : 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+1.937500
addr "two" is 0x7fffe4399670
contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+2.00
ppc64$
ppc64$
ppc64$ /usr/local/gcc7/bin/gcc -m64 -std=iso9899:2011 \
> -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ibmlongdouble -o foo foo.c
gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
ppc64$ ./foo
system name = Linux
node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64
addr "pi" is 0x75eef3e0
contents : 40 09 21 fb 54 44 2d 18 3c a1 a6 26 33 14 5c 06
+3.14159265358979323846264338327948122706
+3.1415926535897932384626433832795028841971 <- pi
addr "one" is 0x75eef3f0
contents : 3f f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+1.00
addr "two" is 0x75eef400
contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+2.00
ppc64$
Like you say "...it doesn't work at all unless you provide your own library."
So very true.
Well this has been fun and I think a POWER9 server is needed to do
any real work and certainly the hardware support will be fun.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #18 from Dennis Clarke --- We are saying the same thing here. Those same emulation routines exist elsewhere and are called _Qp_div, _Qp_mul and _Qp_add on Solaris SPARC systems whereas those are implemented into other places with more or less the same names. Let's not go in circles here. I see the issue and the old 970 is a historical artifact.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #17 from Jakub Jelinek ---
(In reply to Dennis Clarke from comment #16)
> It is annoying that the gcc compiler will produce the correct
> assembly for both the IBM long double and the IEEE 754-2008
> type 128-bit floating point. One sort of works and the other
I have no idea what you mean by correct assembly for -mabi=ieeelongdouble.
If you try something as simple as
long double add (long double x, long double y) { return x + y; }
you'll see that it emits the SVR4 ABI calls like _q_add etc. for the software
emulation, but neither glibc nor gcc provides implementation for these.
So it doesn't work at all unless you provide your own library. This isn't some
gap that libquadmath can cover, that library requires that {+,-,*,/} etc. work
and furthermore the type needs to be __float128, not long double.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #16 from Dennis Clarke --- Dear Jakub Jelinek : Exactly. Yes, I think the libmpfr/libgmp seem to work perfectly here but the real issue is that the old 970 and pre Power ISA v.2.03 spec type hardware is a historical artifact like the old DEC Alpha. I see that in gcc 7.3.0 we do get share/info/libquadmath.info installed BUT in gcc 8 we do not. This is good. It is annoying that the gcc compiler will produce the correct assembly for both the IBM long double and the IEEE 754-2008 type 128-bit floating point. One sort of works and the other does not at all. A value for pi becomes 2.0713495408... etc. The gcc manual page for "IBM RS/6000 and PowerPC Options" needs a bit of a re-write to address the strange results one may get from the use of "-mabi" ieeelongdouble or ibmlongdouble. At the very least the "warning" exists to let a user know that something is amiss here and strange results may occur. Dennis Clarke
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #15 from Jakub Jelinek --- For libquadmath you need a working __float128 support. On x86_64, i686 and ia64 this is done through a slow software emulation in libgcc. On powerpc*, there is either a software emulation which requires VSX, or hardware implementation which requires power9. On s390 there is hardware implementation, but long double is already quad, so you don't need libquadmath. For everything else, just use mpfr.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Dennis Clarke changed: What|Removed |Added Known to work|8.0 | --- Comment #14 from Dennis Clarke --- We are going in circles here. Neither libquadmath nor the required header exist nor function on the powerpc64 target wherein the processor is NOT an IBM power type unit. It is NOT known to work with gcc version 8 either as I have tested for that and the answer is a clear no. This is NOT a power8 nor a power7 nor any version thereof. This is the classic IBM PowerPC 970FX processor. This is big endian. There is NOT an option for "VSX by default". The real issue seems to lay down inside glibc, which I was looking at from the very beginning and I had already said the "non-IBM Power variations are simply not supported" and in glibc 2.26 we see : On ia64, powerpc64le, x86-32, and x86-64, the math library now implements 128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE 754-2008) and ISO/IEC TS 18661-3:2015. Contributed by Paul E. Murphy, Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers. To compile programs that use this feature, the compiler must support 128-bit floating point with the type name _Float128 (as defined by TS 18661-3) or __float128 (the nonstandard name used by GCC for C++, and for C prior to version 7). _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ must be defined to make the new interfaces visible. The new functions and macros correspond to those present for other floating-point types (except for a few obsolescent interfaces not supported for the new type), with F128 or f128 suffixes; for example, strtof128, HUGE_VAL_F128 and cosf128. Following TS 18661-3, there are no printf or scanf formats for the new type; the strfromf128 and strtof128 interfaces should be used instead. This was soon followed by 2.27 wherein : On platforms where long double has the IEEE binary128 format (aarch64, alpha, mips64, riscv, s390 and sparc), the math library now implements _Float128 interfaces for that type, as defined by ISO/IEC TS 18661-3:2015. These are the same interfaces added in version 2.26 for some platforms where this format is supported but is not the format of long double. However the gcc version 8 20180415 will compile C source and produce assembly that clearly uses the 128-bit IEEE 754-2008 format for floating point data however the options for -mfloat128 and -mfloat128-hardware clearly won't work here. The manual page is slightly misleading for "RS/6000 and PowerPC" options as really there needs to exist a page for "IBM Power" options. The options for abi ibmlongdouble and ieeelongdouble both work as expected and I have already shown that along with the output assembly wherein we do actually get both 128-bit datatypes : gcc: warning: using IBM extended precision long double cc1: warning: using IBM extended precision long double .quad 0x400921fb54442d18,0x3ca1a62633145c06 $ /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 Regardless how you slice it here and want to say "works in ver 8" it simply does not and I have a powerpc 64-bit big-endian machine right here that bootstraps both version 7.3.0 and the available ver 8 test tarball just fine. Neither can do anything with libquadmath on this architecture as it is clearly not one of the IBM Power variants under Power ISA v.2.07 spec. Perhaps there needs to be a new manual page for "IBM RS/6000 and PowerPC Options" because really there exists the "IBM Power" systems and then the older "IBM RS/6000 and PowerPC Options". That may also cover the whole SoC type chips that we saw so many of from FreeScale and Motorola at one point. Someone, whomever it is, stop flipping this as "known to work on 8" where that just isn't true.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #13 from Michael Meissner --- You can use --with-cpu=power7 as well. But if you only have power8 systems, it is better to use --with-cpu=power8. The little endian PowerPC Linux systems have a minimum cpu base level of power8, so float128 is available on that platform by default.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #12 from Jakub Jelinek --- Or configure the big endian compiler with VSX by default, e.g. --with-cpu=power8 or similar.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #11 from Jakub Jelinek --- You need powerpc64le, big-endian doesn't support __float128.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #10 from Dennis Clarke --- Well, current gcc 8 snapshot doesn't work : nix_$ nix_$ /usr/local/gcc8/bin/gcc --version gcc (genunix Wed Apr 18 19:16:29 GMT 2018) 8.0.1 20180415 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. nix_$ /usr/local/gcc8/bin/gcc -m64 -mcpu=970 -o s s.c s.c:82:10: fatal error: quadmath.h: No such file or directory #include ^~~~ compilation terminated. nix_$
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #9 from Dennis Clarke --- Thank you Sir. I think it best if I stay with the nightly/test tarball found at https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/ and then I won't have to fiddle with automake/reconf etc or be too concerned with configure.am and all that jazz.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Dennis Clarke from comment #6) > Following the instructions at https://gcc.gnu.org/wiki/GitMirror there is > no branch anywhere that claims to be a version 8 type. > > Where is this ver 8 code hidden away ? mkdir gcc; cd gcc git init # By default pulls all heads (trunk, release branches, git-only branches, a few other selected SVN branches) git remote add origin git://gcc.gnu.org/git/gcc.git # Also include all the other SVN branches (adds about 0.2GB) git config --add remote.origin.fetch 'refs/remotes/*:refs/remotes/svn/*' git fetch git checkout -b trunk svn/trunk <- This is 8.0. When 8.1 is released, trunk will become 9.0.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #7 from Dennis Clarke --- found this : https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/ I will give that a try.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #6 from Dennis Clarke --- Following the instructions at https://gcc.gnu.org/wiki/GitMirror there is no branch anywhere that claims to be a version 8 type. Where is this ver 8 code hidden away ?
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Jakub Jelinek changed: What|Removed |Added Known to work||8.0 --- Comment #5 from Jakub Jelinek --- 8.0 marks the development versions of the upcoming 8.1, 8.2 etc. releases, 8.0 will never be released itself. libquadmath is not enabled on sparc64, right now it is just enabled on targets that have a __float128 or similar type, so i?86, x86_64, ia64 and powerpc*. sparc64 should have IEEE754 quad support in glibc already, just use long double.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Dennis Clarke changed: What|Removed |Added Known to work|8.0 | --- Comment #4 from Dennis Clarke --- Why was the "Known to work" changed to "8.0" when no such release exists? I am going to delete that. For the moment it seems that a git pull and build from trunk needs to be done in order to test the "theory" that libquadmath will actually work in various places. This will include sparc64 on both Debian linux and Solaris.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Richard Biener changed: What|Removed |Added Target||powerpc64 Status|UNCONFIRMED |RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Only snapshots though a release (candiate) is not far away.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #2 from Dennis Clarke --- Thank you very much Sir! So then .. where is this gcc 8 that you speak of ? Still just a nightly test release or is there an actual tarball hidden away?
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- If you want libquadmath with powerpc* support, you need GCC 8 or later.
