https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Dennis Clarke <dclarke at blastwave dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work|8.0 |
--- Comment #14 from Dennis Clarke <dclarke at blastwave dot org> ---
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.
