[PATCH] powerpc64: add IEEE binary128 long double support

[PATCH] powerpc64: add IEEE binary128 long double support

[Samuel Holland]

This is added under a new "ieee128" sub-architecture. The 128-bit scalar
floating-point ABI uses the Altivec registers for parameter passing, but
no special instructions; thus, the ABI can be used with any CPU that
supports Altivec. However, hardware instructions to operate on a 128-bit
scalar are only available starting with POWER9. Any older CPU will use
software fp.

With "-mlong-double-128 -mabi=ieeelongdouble", gcc defines both
__LONG_DOUBLE_128__ and __LONG_DOUBLE_IEEE128__. clang, when patched
with "LongDoubleFormat = &llvm::APFloat::IEEEquad();", defines
__LONG_DOUBLE_128__ but not __LONG_DOUBLE_IEEE128__, so we use
__LDBL_MANT_DIG__ to distinguish IEEE binary128 from IBM double-double.
---

So far the suggested ABI names have been "ld128", "ieee128", "ieeequad",
and "f128". "ieee128" is the shortest while still being unambiguous
about which 128-bit FP format is being used.

Ideally we could use __LONG_DOUBLE_IEEE128__ as the preprocessor
condition, but it's not provided by clang. Since we have to check
__LDBL_MANT_DIG__ anyway, is checking __LONG_DOUBLE_128__ redundant?

---
 INSTALL                     |  4 ++--
 arch/powerpc64/bits/float.h | 21 +++++++++++++++++++++
 arch/powerpc64/reloc.h      |  8 +++++++-
 configure                   |  1 +
 4 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/INSTALL b/INSTALL
index a2a142bf..ce08bb17 100644
--- a/INSTALL
+++ b/INSTALL
@@ -76,8 +76,8 @@ and ABI combinations:
 
 * PowerPC64
     * Both little and big endian variants are supported
-    * Compiler toolchain must provide 64-bit long double, not IBM
-      double-double or IEEE quad
+    * Compiler toolchain must provide 64-bit or 128-bit IEEE long
+      double, not IBM double-double
     * Compiler toolchain must use the new (ELFv2) ABI regardless of
       whether it is for little or big endian
 
diff --git a/arch/powerpc64/bits/float.h b/arch/powerpc64/bits/float.h
index c4a655e7..7d282f90 100644
--- a/arch/powerpc64/bits/float.h
+++ b/arch/powerpc64/bits/float.h
@@ -1,5 +1,24 @@
 #define FLT_EVAL_METHOD 0
 
+#if __LONG_DOUBLE_128__ && __LDBL_MANT_DIG__ == 113
+
+#define LDBL_TRUE_MIN 6.47517511943802511092443895822764655e-4966L
+#define LDBL_MIN 3.36210314311209350626267781732175260e-4932L
+#define LDBL_MAX 1.18973149535723176508575932662800702e+4932L
+#define LDBL_EPSILON 1.92592994438723585305597794258492732e-34L
+
+#define LDBL_MANT_DIG 113
+#define LDBL_MIN_EXP (-16381)
+#define LDBL_MAX_EXP 16384
+
+#define LDBL_DIG 33
+#define LDBL_MIN_10_EXP (-4931)
+#define LDBL_MAX_10_EXP 4932
+
+#define DECIMAL_DIG 36
+
+#else
+
 #define LDBL_TRUE_MIN 4.94065645841246544177e-324L
 #define LDBL_MIN 2.22507385850720138309e-308L
 #define LDBL_MAX 1.79769313486231570815e+308L
@@ -14,3 +33,5 @@
 #define LDBL_MAX_10_EXP 308
 
 #define DECIMAL_DIG 17
+
+#endif
diff --git a/arch/powerpc64/reloc.h b/arch/powerpc64/reloc.h
index faf70acd..52daecb2 100644
--- a/arch/powerpc64/reloc.h
+++ b/arch/powerpc64/reloc.h
@@ -6,7 +6,13 @@
 #define ENDIAN_SUFFIX ""
 #endif
 
-#define LDSO_ARCH "powerpc64" ENDIAN_SUFFIX
+#if __LONG_DOUBLE_128__ && __LDBL_MANT_DIG__ == 113
+#define FP_SUFFIX "-ieee128"
+#else
+#define FP_SUFFIX ""
+#endif
+
+#define LDSO_ARCH "powerpc64" ENDIAN_SUFFIX FP_SUFFIX
 
 #define TPOFF_K (-0x7000)
 
diff --git a/configure b/configure
index 60e0b1fc..6d196570 100755
--- a/configure
+++ b/configure
@@ -652,6 +652,7 @@ test "$ARCH" = "microblaze" && trycppif __MICROBLAZEEL__ "$t" \
 if test "$ARCH" = "powerpc64" ; then
 trycppif "_CALL_ELF == 2" "$t" || fail "$0: error: unsupported powerpc64 ABI"
 trycppif __LITTLE_ENDIAN__ "$t" && SUBARCH=${SUBARCH}le
+trycppif "__LONG_DOUBLE_128__ && __LDBL_MANT_DIG__ == 113" "$t" && SUBARCH=${SUBARCH}-ieee128
 trycppif _SOFT_FLOAT "$t" && fail "$0: error: soft-float not supported on powerpc64"
 fi
 
-- 
2.21.0

[GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Samuel Holland]

---

This works properly with multiarch and -m64/-m32:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64-gentoo-linux-musl/8.3.0/lto-wrapper
Target: powerpc64-gentoo-linux-musl
Configured with: /tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/configure
--host=powerpc64-gentoo-linux-musl --build=powerpc64-gentoo-linux-musl
--prefix=/usr --enable-languages=c,c++,ada --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--enable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-multilib --disable-altivec
--disable-fixed-point --enable-libgomp --disable-libmudflap --disable-libmpx
--disable-systemtap --disable-vtable-verify --disable-libvtv
--disable-libquadmath --enable-lto --without-isl --disable-libsanitizer
--enable-default-pie --enable-default-ssp --enable-multiarch
--with-linker-hash-style=both --disable-decimal-float --enable-secureplt
--with-abi=elfv2 --with-cpu=power9 --with-long-double-128
--with-long-double-format=ieee
Thread model: posix
gcc version 8.3.0 (Gentoo Hardened 8.3.0-r1 p1.1) 
$ gcc -m64 tests/hello.c -o hello
$ file hello
hello: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-powerpc64-ieee128.so.1, not stripped
$ readelf -aW hello | tail -n2
File Attributes
  Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
$ ./hello 
Hello, world!
$ gcc -m32 tests/hello.c -o hello
$ file hello
hello: ELF 32-bit MSB pie executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-powerpc.so.1, not stripped
$ readelf -aW hello | tail -n2
File Attributes
  Tag_GNU_Power_ABI_FP: hard float, 64-bit long double
$ ./hello 
Hello, world!

---
 gcc/config/rs6000/linux.h   |  3 ++-
 gcc/config/rs6000/linux64.h | 11 +++++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
index 96b97877989b..439b5179b172 100644
--- a/gcc/config/rs6000/linux.h
+++ b/gcc/config/rs6000/linux.h
@@ -139,8 +139,9 @@
 #define POWERPC_LINUX
 
 /* ppc linux has 128-bit long double support in glibc 2.4 and later.  */
+/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
 #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
-#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
+#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)
 #endif
 
 /* Static stack checking is supported by means of probes.  */
diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
index 5380f6a6a6f1..2b76255f7673 100644
--- a/gcc/config/rs6000/linux64.h
+++ b/gcc/config/rs6000/linux64.h
@@ -447,12 +447,18 @@ extern int dot_symbols;
 ":%(dynamic_linker_prefix)/lib64/ld64.so.1}"
 #endif
 
+#ifdef TARGET_DEFAULT_LONG_DOUBLE_128
+#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-64:;:-ieee128}"
+#else
+#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-128:-ieee128}"
+#endif
+
 #undef MUSL_DYNAMIC_LINKER32
 #define MUSL_DYNAMIC_LINKER32 \
   "/lib/ld-musl-powerpc" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
 #undef MUSL_DYNAMIC_LINKER64
 #define MUSL_DYNAMIC_LINKER64 \
-  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
+  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E MUSL_DYNAMIC_LINKER_FP ".so.1"
 
 #undef  DEFAULT_ASM_ENDIAN
 #if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
@@ -628,8 +634,9 @@ extern int dot_symbols;
 #define POWERPC_LINUX
 
 /* ppc{32,64} linux has 128-bit long double support in glibc 2.4 and later.  */
+/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
 #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
-#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
+#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL && !TARGET_64BIT ? 64 : 128)
 #endif
 
 /* Static stack checking is supported by means of probes.  */
-- 
2.21.0

Re: [PATCH] powerpc64: add IEEE binary128 long double support

[Szabolcs Nagy]

* Samuel Holland <samuel@sholland.org> [2019-06-30 14:38:24 -0500]:
> This is added under a new "ieee128" sub-architecture. The 128-bit scalar
> floating-point ABI uses the Altivec registers for parameter passing, but
> no special instructions; thus, the ABI can be used with any CPU that
> supports Altivec. However, hardware instructions to operate on a 128-bit
> scalar are only available starting with POWER9. Any older CPU will use
> software fp.
> 
> With "-mlong-double-128 -mabi=ieeelongdouble", gcc defines both
> __LONG_DOUBLE_128__ and __LONG_DOUBLE_IEEE128__. clang, when patched
> with "LongDoubleFormat = &llvm::APFloat::IEEEquad();", defines
> __LONG_DOUBLE_128__ but not __LONG_DOUBLE_IEEE128__, so we use
> __LDBL_MANT_DIG__ to distinguish IEEE binary128 from IBM double-double.
> ---
> 
> So far the suggested ABI names have been "ld128", "ieee128", "ieeequad",
> and "f128". "ieee128" is the shortest while still being unambiguous
> about which 128-bit FP format is being used.
> 
> Ideally we could use __LONG_DOUBLE_IEEE128__ as the preprocessor
> condition, but it's not provided by clang. Since we have to check
> __LDBL_MANT_DIG__ anyway, is checking __LONG_DOUBLE_128__ redundant?

i'd only check __LDBL_MANT_DIG__ since that's what
is used internally in musl where this matters.

Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Szabolcs Nagy]

* Samuel Holland <samuel@sholland.org> [2019-06-30 14:38:25 -0500]:
>  gcc/config/rs6000/linux.h   |  3 ++-
>  gcc/config/rs6000/linux64.h | 11 +++++++++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
> index 96b97877989b..439b5179b172 100644
> --- a/gcc/config/rs6000/linux.h
> +++ b/gcc/config/rs6000/linux.h
> @@ -139,8 +139,9 @@
>  #define POWERPC_LINUX
>  
>  /* ppc linux has 128-bit long double support in glibc 2.4 and later.  */
> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)

configuring 32bit ppc with 128bit long double is unsupported in musl

i think reporting an error in config.gcc is better than trying to fix
it up later.

OPTION_MUSL can handle -mmusl cflag, not just the configured libc, but
i think that's unreliable for other reasons anyway.

> --- a/gcc/config/rs6000/linux64.h
> +++ b/gcc/config/rs6000/linux64.h
> @@ -447,12 +447,18 @@ extern int dot_symbols;
>  ":%(dynamic_linker_prefix)/lib64/ld64.so.1}"
>  #endif
>  
> +#ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-64:;:-ieee128}"
> +#else
> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-128:-ieee128}"
> +#endif
> +
>  #undef MUSL_DYNAMIC_LINKER32
>  #define MUSL_DYNAMIC_LINKER32 \
>    "/lib/ld-musl-powerpc" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
>  #undef MUSL_DYNAMIC_LINKER64
>  #define MUSL_DYNAMIC_LINKER64 \
> -  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
> +  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E MUSL_DYNAMIC_LINKER_FP ".so.1"

why did the -sf disappear?
only do this if we are sure we never want to support such abi in musl

otherwise keep it with some easy to remember ordering for the extension
suffixes (e.g. alphabetical)

>  /* ppc{32,64} linux has 128-bit long double support in glibc 2.4 and later.  */
> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL && !TARGET_64BIT ? 64 : 128)
>  #endif

same as above, this looks ugly.

Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Samuel Holland]

On 6/30/19 5:29 PM, Szabolcs Nagy wrote:
> * Samuel Holland <samuel@sholland.org> [2019-06-30 14:38:25 -0500]:
>>  gcc/config/rs6000/linux.h   |  3 ++-
>>  gcc/config/rs6000/linux64.h | 11 +++++++++--
>>  2 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
>> index 96b97877989b..439b5179b172 100644
>> --- a/gcc/config/rs6000/linux.h
>> +++ b/gcc/config/rs6000/linux.h
>> @@ -139,8 +139,9 @@
>>  #define POWERPC_LINUX
>>  
>>  /* ppc linux has 128-bit long double support in glibc 2.4 and later.  */
>> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
>> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)
> 
> configuring 32bit ppc with 128bit long double is unsupported in musl
> 
> i think reporting an error in config.gcc is better than trying to fix
> it up later.

I don't think that's possible, but I'm happy to be proven wrong. gcc accepts a
single gcc_cv_target_ldbl128, which is applied everywhere with
multilib/multiarch/--enable-targets=all. So even if --with-long-double-128 was
made an error for powerpc-linux-musl, the logic still has to work for
powerpc64-linux-musl, where it can't be an error.

> OPTION_MUSL can handle -mmusl cflag, not just the configured libc, but
> i think that's unreliable for other reasons anyway.

That also has to work: --target=powerpc-linux-gnu --with-long-double-128, and
then powerpc-linux-gnu-gcc -mmusl, will do the wrong thing unless it's fixed up
at runtime.

>> --- a/gcc/config/rs6000/linux64.h
>> +++ b/gcc/config/rs6000/linux64.h
>> @@ -447,12 +447,18 @@ extern int dot_symbols;
>>  ":%(dynamic_linker_prefix)/lib64/ld64.so.1}"
>>  #endif
>>  
>> +#ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-64:;:-ieee128}"
>> +#else
>> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-128:-ieee128}"
>> +#endif
>> +
>>  #undef MUSL_DYNAMIC_LINKER32
>>  #define MUSL_DYNAMIC_LINKER32 \
>>    "/lib/ld-musl-powerpc" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
>>  #undef MUSL_DYNAMIC_LINKER64
>>  #define MUSL_DYNAMIC_LINKER64 \
>> -  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E "%{msoft-float:-sf}.so.1"
>> +  "/lib/ld-musl-powerpc64" MUSL_DYNAMIC_LINKER_E MUSL_DYNAMIC_LINKER_FP ".so.1"
> 
> why did the -sf disappear?
> only do this if we are sure we never want to support such abi in musl

Because powerpc64 sf support doesn't exist on the musl side. I'll put it back.

> otherwise keep it with some easy to remember ordering for the extension
> suffixes (e.g. alphabetical)

Should there be a dash between "ieee128" and "sf"?

>>  /* ppc{32,64} linux has 128-bit long double support in glibc 2.4 and later.  */
>> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
>> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL && !TARGET_64BIT ? 64 : 128)
>>  #endif
> 
> same as above, this looks ugly.

Same as above, I don't think it's avoidable.

Cheers,
Samuel

Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Szabolcs Nagy]

* Samuel Holland <samuel@sholland.org> [2019-06-30 19:59:28 -0500]:
> >> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> >> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)
> > 
> > configuring 32bit ppc with 128bit long double is unsupported in musl
> > 
> > i think reporting an error in config.gcc is better than trying to fix
> > it up later.
> 
> I don't think that's possible, but I'm happy to be proven wrong. gcc accepts a
> single gcc_cv_target_ldbl128, which is applied everywhere with
> multilib/multiarch/--enable-targets=all. So even if --with-long-double-128 was
> made an error for powerpc-linux-musl, the logic still has to work for
> powerpc64-linux-musl, where it can't be an error.
> 
> > OPTION_MUSL can handle -mmusl cflag, not just the configured libc, but
> > i think that's unreliable for other reasons anyway.
> 
> That also has to work: --target=powerpc-linux-gnu --with-long-double-128, and
> then powerpc-linux-gnu-gcc -mmusl, will do the wrong thing unless it's fixed up
> at runtime.

what i'm saying is that this is not a supportable usage so there
is no point adding musl specific hacks to gcc internals which
wont work anyway.

if somebody uses -mmusl on a toolchain with default 128bit ldbl
then it's their responsibility to pass correct abi flags.
but it still wont work if the target libs like libgcc depend on
those abi flags: there will be no target libs with the right abi.

> > otherwise keep it with some easy to remember ordering for the extension
> > suffixes (e.g. alphabetical)
> 
> Should there be a dash between "ieee128" and "sf"?

well you defined the extension as -foo, i prefer using _foo
not to confuse target triplet parsers, but since -sf is already
there -foo is probably better.

Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Rich Felker]

On Sun, Jun 30, 2019 at 02:38:25PM -0500, Samuel Holland wrote:
> This works properly with multiarch and -m64/-m32:

musl doesn't support multilib or gcc style multiarch (sharing same
include path for multiple musl archs), so that's not a constraint
anyway.

> diff --git a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
> index 96b97877989b..439b5179b172 100644
> --- a/gcc/config/rs6000/linux.h
> +++ b/gcc/config/rs6000/linux.h
> @@ -139,8 +139,9 @@
>  #define POWERPC_LINUX
>  
>  /* ppc linux has 128-bit long double support in glibc 2.4 and later.  */
> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)
>  #endif

This looks uncontroversial, but since this is only for the 32-bit case
I don't think it needs comments about musl ppc64.

Also, as I'm trying to roll the release in the next few days and this
is a somewhat questionable change I don't yet understand, it won't be
in musl 1.1.23.

>  /* Static stack checking is supported by means of probes.  */
> diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
> index 5380f6a6a6f1..2b76255f7673 100644
> --- a/gcc/config/rs6000/linux64.h
> +++ b/gcc/config/rs6000/linux64.h
> @@ -447,12 +447,18 @@ extern int dot_symbols;
>  ":%(dynamic_linker_prefix)/lib64/ld64.so.1}"
>  #endif
>  
> +#ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-64:;:-ieee128}"
> +#else
> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-128:-ieee128}"
> +#endif

I'm not a fan of the "ieee128" naming, simply because "ieee128"
presumably is the name of some unrelated ieee document and doesn't
suggest it's got anything to do with floating point except to someone
who assumes ieee means ieee754. My first thought would have been
"quad" or "qf" or even "ieeequad". But this is a relatively minor
issue.

>  /* ppc{32,64} linux has 128-bit long double support in glibc 2.4 and later.  */
> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL && !TARGET_64BIT ? 64 : 128)
>  #endif

Default ABI for musl should not be changed. I guess this default
wasn't being used anyway and was set by configure's logic for musl (or
for !glibc?) but it was decided very intentionally when musl's ppc64
port was added that the ABI would be ld64 because that was the only
thing that non-bleeding-edge tooling could support, and we didn't want
to mandate gcc8+ or whatever version would have been needed (maybe 7+?
not sure) to build ppc64.

Beyond that, before we move further with this I want to understand the
motivation for it. If it's just that clang doesn't presently support
ld64 (not clear if that's true but it looked like it might be from
some comments I saw on #musl), this is not going upstream in musl
unless/until clang supports ld64. What I absolutely *don't* want is to
make it so there are two separate ABIs for musl-ppc64 that are "the
standard/gcc ABI" and "the clang/gcc8+ ABI". That's just creating
tooling fragmentation hell.

If the motivation is that there are musl-ppc64 users who really want
quad math, and want to use it via long double rather than _Float128
for whatever reason, then the idea behind adding a second ABI here is
at least reasonable. I wish it could be supported in old gcc too, but
I'm told the patch to add quad support was very invasive and hard to
backport, so I'm guessing that's not happening.

Rich

Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double

[Samuel Holland]

On 7/1/19 12:42 PM, Rich Felker wrote:
> On Sun, Jun 30, 2019 at 02:38:25PM -0500, Samuel Holland wrote:
>> This works properly with multiarch and -m64/-m32:
> 
> musl doesn't support multilib 

I know that.

> or gcc style multiarch

[citation needed]

> (sharing same include path for multiple musl archs),

"gcc style multiarch" adds the multiarch triple as a suffix to the include path,
and only uses the (shared) unsuffixed path as a fallback:

$ gcc -m64 -v -xc /dev/null |& grep /usr/include
 /usr/include/powerpc64-linux-musl
 /usr/include
$ gcc -m32 -v -xc /dev/null |& grep /usr/include
 /usr/include/powerpc-linux-musl
 /usr/include

Unfortunately, software that installs headers into ${includedir}/${pkgname}
tends to have reverse dependencies that hardcode /usr/include/${pkgname} in
their configuration scripts. So it's much easier to leave includedir as
/usr/include and only move the arch-specific headers to the arch-specific header
directory (which my current distro has machinery to do already):

$ gcc -E -xc - <<< "#include <stdio.h>" | grep include


# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "/usr/include/stdio.h" 1 3 4
# 1 "/usr/include/features.h" 1 3 4
# 9 "/usr/include/stdio.h" 2 3 4
# 26 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 1 3 4
# 6 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 3 4
# 88 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 3 4
# 103 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 3 4
# 190 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 3 4
# 348 "/usr/include/powerpc64-linux-musl/bits/alltypes.h" 3 4
# 27 "/usr/include/stdio.h" 2 3 4
# 54 "/usr/include/stdio.h" 3 4

So no, multiarch is not multilib. And yes, multiarch does exactly what you wish
multilib did. And yes, I've explained this before. Several times!

> so that's not a constraint anyway.

The "musl doesn't support multilib" trope is unhelpful when it's used as an
excuse to hand-wave away all forms of compiler multitargeting, especially ones
that currently work.

>> diff --git a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
>> index 96b97877989b..439b5179b172 100644
>> --- a/gcc/config/rs6000/linux.h
>> +++ b/gcc/config/rs6000/linux.h
>> @@ -139,8 +139,9 @@
>>  #define POWERPC_LINUX
>>  
>>  /* ppc linux has 128-bit long double support in glibc 2.4 and later.  */
>> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
>> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL ? 64 : 128)
>>  #endif
> 
> This looks uncontroversial, but since this is only for the 32-bit case
> I don't think it needs comments about musl ppc64.

Okay, that makes sense; I'll remove the comment here.

> Also, as I'm trying to roll the release in the next few days and this
> is a somewhat questionable change I don't yet understand, it won't be
> in musl 1.1.23.

Sure, and I haven't sent this patch to GCC yet either. When that happens, I'll
fill in whatever the version ends up being. I was trying to be consistent with
the glibc comment, and it seemed helpful information to have.

>>  /* Static stack checking is supported by means of probes.  */
>> diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
>> index 5380f6a6a6f1..2b76255f7673 100644
>> --- a/gcc/config/rs6000/linux64.h
>> +++ b/gcc/config/rs6000/linux64.h
>> @@ -447,12 +447,18 @@ extern int dot_symbols;
>>  ":%(dynamic_linker_prefix)/lib64/ld64.so.1}"
>>  #endif
>>  
>> +#ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-64:;:-ieee128}"
>> +#else
>> +#define MUSL_DYNAMIC_LINKER_FP "%{mlong-double-128:-ieee128}"
>> +#endif
> 
> I'm not a fan of the "ieee128" naming, simply because "ieee128"
> presumably is the name of some unrelated ieee document and doesn't
> suggest it's got anything to do with floating point except to someone
> who assumes ieee means ieee754. My first thought would have been
> "quad" or "qf" or even "ieeequad". But this is a relatively minor
> issue.

And I like my bikeshed blue. As I mentioned in the other patch:
> So far the suggested ABI names have been "ld128", "ieee128", "ieeequad",
> and "f128".

Can we please pick something so I can stop recompiling my entire system :)

>>  /* ppc{32,64} linux has 128-bit long double support in glibc 2.4 and later.  */
>> +/* musl supports 128-bit long double in 1.1.23 and later on powerpc64 only.  */
>>  #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>> -#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
>> +#define RS6000_DEFAULT_LONG_DOUBLE_SIZE (OPTION_MUSL && !TARGET_64BIT ? 64 : 128)
>>  #endif
> 
> Default ABI for musl should not be changed. I guess this default
> wasn't being used anyway and was set by configure's logic for musl (or
> for !glibc?) but it was decided very intentionally when musl's ppc64
> port was added that the ABI would be ld64 because that was the only
> thing that non-bleeding-edge tooling could support, and we didn't want
> to mandate gcc8+ or whatever version would have been needed (maybe 7+?
> not sure) to build ppc64.

This isn't changing the *default* default long double size. This is only
modifying the runtime default in the case gcc was configured with
--with-long-double-128. In rs6000.c theres:

#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE
#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64
#endif

The ultimate default (with no ./configure option) is still 64 bits.

> Beyond that, before we move further with this I want to understand the
> motivation for it. If it's just that clang doesn't presently support
> ld64 (not clear if that's true but it looked like it might be from
> some comments I saw on #musl), this is not going upstream in musl
> unless/until clang supports ld64. What I absolutely *don't* want is to
> make it so there are two separate ABIs for musl-ppc64 that are "the
> standard/gcc ABI" and "the clang/gcc8+ ABI". That's just creating
> tooling fragmentation hell.

Clang requires patching in either case, since it's hardcoded to 128-bit IBM
double-double[1] and not configurable. This patch has nothing at all to do with
clang. And nowhere have I suggested that the default ABI would change.

[1]:
https://github.com/llvm/llvm-project/blob/745379a0af74a37465f616b99c10a09b4f0d2add/clang/lib/Basic/Targets/PPC.h#L78

> If the motivation is that there are musl-ppc64 users who really want
> quad math, and want to use it via long double rather than _Float128
> for whatever reason, then the idea behind adding a second ABI here is
> at least reasonable. I wish it could be supported in old gcc too, but
> I'm told the patch to add quad support was very invasive and hard to
> backport, so I'm guessing that's not happening.

The support was added in GCC 7 (which is already two years old). Considering
that the GCC 6 branch is closed, I highly doubt anything will be backported.

> Rich

Samuel