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

Submitted by Samuel Holland on June 30, 2019, 7:38 p.m.

Details

Message ID 20190630193825.65174-2-samuel@sholland.org
State New
Series "powerpc64: add IEEE binary128 long double support"
Headers show

Commit Message

Samuel Holland June 30, 2019, 7:38 p.m.
---

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(-)

Patch hide | download patch | download mbox

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.  */

Comments

Szabolcs Nagy June 30, 2019, 10:29 p.m.
* 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.
Samuel Holland July 1, 2019, 12:59 a.m.
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
Szabolcs Nagy July 1, 2019, 7:17 a.m.
* 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.
Rich Felker July 1, 2019, 5:42 p.m.
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
Samuel Holland July 2, 2019, 12:48 a.m.
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