[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Jul 2019 13:42:14 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [GCC PATCH] powerpc64 musl libc support for IEEE
binary128 long double
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
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.
