From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14343 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Samuel Holland Newsgroups: gmane.linux.lib.musl.general Subject: Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double Date: Mon, 1 Jul 2019 19:48:36 -0500 Message-ID: <9d11aef7-b8c5-7f88-ab2c-e39aae79f01e@sholland.org> References: <20190630193825.65174-1-samuel@sholland.org> <20190630193825.65174-2-samuel@sholland.org> <20190701174214.GV1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31137"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 To: musl@lists.openwall.com Original-X-From: musl-return-14359-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 02 02:48:56 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 1hi6yb-0007uE-6s for gllmg-musl@m.gmane.org; Tue, 02 Jul 2019 02:48:54 +0200 Original-Received: (qmail 1273 invoked by uid 550); 2 Jul 2019 00:48:50 -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 1254 invoked from network); 2 Jul 2019 00:48:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=H MoBBKmtePK8pQSxhNQpw6a4IzZHJcQH/SSbFyxuAvY=; b=YWEMupts+i1gUl/gz rd5bK2il9p5qFL+EgRbsJCsl9B3qeHwUdgYNJNqU5sDyzYh1gEuikas3JVbplzN8 lH3oxhSK+XsqFXp0JrutEhRS8tkdIZrdwtszPTwr3If3O+YWMIOAazteDQDYw5Sk 21N6cpxm0rxEwu4Btk8hj6g5s6oII+1C33Ake+hay3cLlJRWIYN2/N6EScBu7IAE C1al38wYK/7Ei2JST60PmGt0VzQferI9EGmEAoyhySdwSY/oQgm/xtX0Hicztv2L VTKv5lIkOf/+sKjhWbJVjBrgbu4O+ZQ1fAhWYXySjELasW1BMz9KCDgikEWehqTv gCAkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=HMoBBKmtePK8pQSxhNQpw6a4IzZHJcQH/SSbFyxuA vY=; b=Due8zTC+Wj/CAvSz7io00+ZEVbt5PMkXmmuJsj0fjf4j+VxxUO/VSts0/ w8+MnSwahHQCcJOWtRvhpXWEkazJDLhjaSr2n7BPRDU/+Uv8T5ICybba3EQeEC1n H7o5hWxywwn9n4kBTylZLYFvOUrV5AHpevx5t/UdeuaB5PZ6o7RDFl/jWhAKjTzP ef3mR/X5u/d/Ru4jw2R0CB5DxKm2E3OsmU0hB0d7u0myu2qBE9fz0WzFk1UIHwFl BOUyuIjUIf+qslB9tsK4eRCEguao9TOepEX8x/FlAl6+rw6WhuW4unHa2QGLBLU+ BUYQcqv83boW4ZamQStB25wQXUFNQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdejgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomhepufgrmhhuvghlucfjohhllhgrnhguuceoshgrmhhuvghlsehs hhholhhlrghnugdrohhrgheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkph epjedtrddufeehrddugeekrdduhedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghm uhgvlhesshhhohhllhgrnhgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: In-Reply-To: <20190701174214.GV1506@brightrain.aerifal.cx> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:14343 Archived-At: 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 " | 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