From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14321 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [GCC PATCH] powerpc64 musl libc support for IEEE binary128 long double Date: Mon, 1 Jul 2019 09:17:50 +0200 Message-ID: <20190701071750.GE21055@port70.net> References: <20190630193825.65174-1-samuel@sholland.org> <20190630193825.65174-2-samuel@sholland.org> <20190630222904.GD21055@port70.net> 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="173380"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14337-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 09:18:05 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 1hhqZg-000izr-SN for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 09:18:04 +0200 Original-Received: (qmail 13587 invoked by uid 550); 1 Jul 2019 07:18:02 -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 13569 invoked from network); 1 Jul 2019 07:18:01 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14321 Archived-At: * Samuel Holland [2019-06-30 19:59:28 -0500]: > >> -#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. what i'm saying is that this is not a supportable usage so there is no point adding musl specific hacks to gcc internals which wont work anyway. if somebody uses -mmusl on a toolchain with default 128bit ldbl then it's their responsibility to pass correct abi flags. but it still wont work if the target libs like libgcc depend on those abi flags: there will be no target libs with the right abi. > > 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"? well you defined the extension as -foo, i prefer using _foo not to confuse target triplet parsers, but since -sf is already there -foo is probably better.