Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.