From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9292 Path: news.gmane.org!not-for-mail From: David Edelsohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl libc for PPC64 Date: Mon, 8 Feb 2016 20:16:25 -0500 Message-ID: References: <20160208161758.GG9915@port70.net> <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=UTF-8 X-Trace: ger.gmane.org 1454980600 21972 80.91.229.3 (9 Feb 2016 01:16:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 01:16:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9305-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 09 02:16:39 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 1aSwv1-0000zg-1g for gllmg-musl@m.gmane.org; Tue, 09 Feb 2016 02:16:39 +0100 Original-Received: (qmail 25899 invoked by uid 550); 9 Feb 2016 01:16:37 -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 25878 invoked from network); 9 Feb 2016 01:16:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N4XKp+sDmo/LmxVw0uSQ3IOQk0C3+sgHjF4gIat2Dl4=; b=Us/wj/JG/6li4w331uvmcLJq54i27pqwKdlGO18amEje1KMUffq0/Oq+JaqDA+eS5G 3SdlXIRAwtLOUHoRY0/ghtXmwqHeNtPr+sHvsTOrb5NOmOw5rMjd8wpLuxEVBn3T1YH9 UzbrU8DdSC2f2dFMxBAtWS7g3ySPQSNpGndxVzxkc/xGUZvg34HaUuKv3ilmEo/wUsSQ YsAEqsye0FLFiZSfzB1YfsjQ6pS5WDFQBZ/bYvKI606aj3HfPOUY6KK3asu4aX+qSxan vUz3UzNNnNfCRoFYU7rmh0mZ98Vo3Z7k0ePqqKEGI7UjW5kYDJS73fSAsZKfkMaxRGEH DDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=N4XKp+sDmo/LmxVw0uSQ3IOQk0C3+sgHjF4gIat2Dl4=; b=SYF6sU7lMcDl1Gx1mIKVDZLgxxq4HrATutxXlXAX744LfJk+c/Dh9Bk7erJAGKSGVs 2NHd1EBVFqiZoG3Tar0AnijU145TvZlIHmEQRSLvIfvTi5VRxi68/P9ekenve5BuQKpE dZCFXhTmzsx8T1A/KXXYzJWNy0kfSVYTxvwLwSnFrpayk6ZszB6/9vi5H0IRQoid5zB3 c8D8lot0G5SncqRyvI7SAeriCGS8K+OZ84DwSk7YF/axZNkuaM7IDvKCzIZoTg6/20ky 2VekKJfNRY1oqD1A+d88F4L40XMByaMIzf/LK+K44uOD3dmx/vjiYzwxi1KqMIwpaEFz enXg== X-Gm-Message-State: AG10YORtL3fYQsScQHOu9aCtWu6zOA9c4l/DcqNt596fnCzhsDSSPR9A7i2Q0pysxyP1ChY2z5cHbUgsVuOdoQ== X-Received: by 10.25.83.209 with SMTP id h200mr12882802lfb.129.1454980585330; Mon, 08 Feb 2016 17:16:25 -0800 (PST) In-Reply-To: <20160209010336.GJ9915@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:9292 Archived-At: 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. - David