From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9293 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl libc for PPC64 Date: Tue, 9 Feb 2016 02:42:54 +0100 Message-ID: <20160209014254.GK9915@port70.net> References: <20160208165143.GA9349@brightrain.aerifal.cx> <20160208201802.GB9349@brightrain.aerifal.cx> <20160208225921.GD9349@brightrain.aerifal.cx> <20160208232945.GE9349@brightrain.aerifal.cx> <20160208234831.GI9915@port70.net> <20160209010336.GJ9915@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1454982193 12897 80.91.229.3 (9 Feb 2016 01:43:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 01:43:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9306-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 09 02:43:12 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aSxKg-0005Zp-Ky for gllmg-musl@m.gmane.org; Tue, 09 Feb 2016 02:43:10 +0100 Original-Received: (qmail 11631 invoked by uid 550); 9 Feb 2016 01:43:08 -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 11607 invoked from network); 9 Feb 2016 01:43:06 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9293 Archived-At: * David Edelsohn [2016-02-08 20:16:25 -0500]: > On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy wrote: > > * Szabolcs Nagy [2016-02-09 00:48:31 +0100]: > >> * Rich Felker [2016-02-08 18:29:45 -0500]: > >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote: > >> > > I'm not sure what you mean. The software emulation assumes the > >> > > hardware support is not present. It doesn't mirror back the state to > >> > > the processor in 64 bit mode. But the emulation is fully IEEE128 > >> > > compliant. > >> > > >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still > >> > rounds to nearest, that's not IEEE compliant. > >> > > >> > The big obstacle to having fenv with softfloat on fully-softfloat > >> > archs is the lack of register state for the rounding mode and > >> > exception flags, so it should be possible to do this right as long as > >> > the cpu has status/mode registers for single/double, which the > >> > soft-quad code can then access/set. If this isn't done right already > >> > we could either try to get it fixed in libgcc or punt and go with > >> > ld64. > >> > > >> > >> it seems to be supported > >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107 > >> > >> so we can implement iso c annex f with 128 bit long doubles. > > > > hm it seems, this is only for the __float128 type > > which will be new in gcc-6. > > > > i don't see how to configure gcc with ieee128 long double. > > (other than using the debug option -mabi=ieeelongdouble) > > > > so if musl goes with ieee128 long double abi then it will > > only work with latest gcc. > > The musl libc dynamic linking support only was added to the latest GCC. > musl has a gcc wrapper that changes the specs file and then it works even with gcc-3 (on x86 and glibc host without c++). we also have patches for gcc releases going back to gcc-4.7 so powerpc64 would be the only arch that depends on features from the latest gcc and that is new situation for musl. (this is mostly interesting because there are historical powerpc64 machines with older toolchains wich might work with musl with minor tweaks if we choose 64bit long double) but if new hw adds ieee128 instructions then i guess that's the right choice.