From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8587 invoked by alias); 23 Aug 2013 00:58:26 -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 8568 invoked by uid 89); 23 Aug 2013 00:58:26 -0000 X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC2,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 00:58:25 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1VCfhk-00017F-00; Fri, 23 Aug 2013 00:58:20 +0000 Date: Fri, 23 Aug 2013 00:58:00 -0000 To: "Maciej W. Rozycki" Cc: libc-ports@sourceware.org, libc-alpha@sourceware.org, Doug Gilmore Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support Message-ID: <20130823005820.GL20515@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) From: Rich Felker X-SW-Source: 2013-08/txt/msg00031.txt.bz2 On Fri, Aug 23, 2013 at 12:52:43AM +0100, Maciej W. Rozycki 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. Rich