From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23468 invoked by alias); 23 Aug 2013 01:41:33 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 23444 invoked by uid 89); 23 Aug 2013 01:41:33 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 01:41:31 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VCgNW-0004h8-8O from Maciej_Rozycki@mentor.com ; Thu, 22 Aug 2013 18:41:30 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Aug 2013 18:41:30 -0700 Received: from [172.30.64.243] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Fri, 23 Aug 2013 02:41:28 +0100 Date: Fri, 23 Aug 2013 01:41:00 -0000 From: "Maciej W. Rozycki" To: Rich Felker CC: , , Doug Gilmore Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support In-Reply-To: <20130823005820.GL20515@brightrain.aerifal.cx> Message-ID: References: <20130823005820.GL20515@brightrain.aerifal.cx> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00032.txt.bz2 On Fri, 23 Aug 2013, Rich Felker wrote: > > As many of you have been aware it has been a long practice for software > > using IEEE 754 floating-point arithmetic run on MIPS processors to use an > > encoding of Not-a-Number (NaN) data different to one used by software run > > on other processors. And as of IEEE 754-2008 revision [1] this encoding > > does not follow one recommended in the standard, as specified in section > > 6.2.1, where it is stated that quiet NaNs should have the first bit (d1) > > of their significand set to 1 while signalling NaNs should have that bit > > set to 0, but MIPS software interprets the two bits in the opposite > > manner. > > > > As from revision 3.50 [2][3] the MIPS Architecture provides for > > processors that support the IEEE 754-2008 preferred NaN encoding format. > > As the two formats (further referred to as "legacy NaN" and "2008 NaN") > > are incompatible to each other, tools will have to provide support for the > > two formats to help people avoid using incompatible binary modules. Here > > is the glibc part. > > Can you elaborate on why you think this is an ABI issue? IMO it's just > s runtime issue unless you're considering raw floating point data > written to disk. In any case this seems like such a small issue that > it should just be silently fixed, rather than adding huge amounts of > ABI ugliness. To give you a small example this: double foo = __builtin_nan (""); will compile to a different data pattern with opposite (qNaN vs sNaN) semantics depending on the NaN encoding mode selected in the compiler. Modules built with different NaN encodings are therefore not compatible, either at the link or at the load time, as applicable. LD (from binutils) and ld.so take care of the link-time and the load-time integrity check, respectively. Additionally hardware has to be configured to match the encoding selected and executables that require a NaN encoding that is not supported by a given piece of hardware have to be rejected -- execve(2) is supposed to return in that case, which may only be handled by the kernel. Please note that neither the legacy-NaN nor the 2008-NaN encoding is mandatory in the MIPS architecture; MIPS FPU hardware at the implementer's discretion may support either or both. I hope this answers your question. Any further concerns? Maciej