From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9291
Path: news.gmane.org!not-for-mail
From: Szabolcs Nagy <nsz@port70.net>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Re: musl libc for PPC64
Date: Tue, 9 Feb 2016 02:03:36 +0100
Message-ID: <20160209010336.GJ9915@port70.net>
References: <CAGWvnyk53uRfMe406GG=Ly07U-5Ze5vOkgjPd4JnL=oUbw9MBg@mail.gmail.com>
 <20160208161758.GG9915@port70.net>
 <20160208165143.GA9349@brightrain.aerifal.cx>
 <CAGWvnymnYg_tE0mrUKN7JMuLb29D_BfqJMOL12MXRui5-C0_xw@mail.gmail.com>
 <20160208201802.GB9349@brightrain.aerifal.cx>
 <CAGWvnynkUuf5u__MEkoZgMWp-Haxev8_c_vw4RA2-zqU2h-unQ@mail.gmail.com>
 <20160208225921.GD9349@brightrain.aerifal.cx>
 <CAGWvny=yDtcXo9+9s535rEFqvn3=W+L7b0WsWrM5TVHi+2pA2Q@mail.gmail.com>
 <20160208232945.GE9349@brightrain.aerifal.cx>
 <20160208234831.GI9915@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 1454979833 11098 80.91.229.3 (9 Feb 2016 01:03:53 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 9 Feb 2016 01:03:53 +0000 (UTC)
To: musl@lists.openwall.com, David Edelsohn <dje.gcc@gmail.com>
Original-X-From: musl-return-9304-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 09 02:03:52 2016
Return-path: <musl-return-9304-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-9304-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1aSwid-0003Er-4U
	for gllmg-musl@m.gmane.org; Tue, 09 Feb 2016 02:03:51 +0100
Original-Received: (qmail 19690 invoked by uid 550); 9 Feb 2016 01:03:49 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 19672 invoked from network); 9 Feb 2016 01:03:48 -0000
Mail-Followup-To: musl@lists.openwall.com,
	David Edelsohn <dje.gcc@gmail.com>
Content-Disposition: inline
In-Reply-To: <20160208234831.GI9915@port70.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Xref: news.gmane.org gmane.linux.lib.musl.general:9291
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/9291>

* Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
> * Rich Felker <dalias@libc.org> [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.