[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e748d6c5-d063-f312-72e8-924d71fbf1aa@sholland.org>
Date: Sun, 30 Jun 2019 19:59:28 -0500
From: Samuel Holland <samuel@...lland.org>
To: musl@...ts.openwall.com
Subject: Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128
long double
On 6/30/19 5:29 PM, Szabolcs Nagy wrote:
> * Samuel Holland <samuel@...lland.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
