From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14334 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double Date: Mon, 1 Jul 2019 13:42:14 -0400 Message-ID: <20190701174214.GV1506@brightrain.aerifal.cx> References: <20190630193825.65174-1-samuel@sholland.org> <20190630193825.65174-2-samuel@sholland.org> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153375"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14350-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 19:42:31 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hi0Jx-000dgz-J2 for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 19:42:29 +0200 Original-Received: (qmail 15818 invoked by uid 550); 1 Jul 2019 17:42:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15793 invoked from network); 1 Jul 2019 17:42:26 -0000 Content-Disposition: inline In-Reply-To: <20190630193825.65174-2-samuel@sholland.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14334 Archived-At: 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