From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3094 invoked by alias); 23 Aug 2013 04:10:32 -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 3067 invoked by uid 89); 23 Aug 2013 04:10:31 -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 04:10:31 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1VCihg-0001iR-00; Fri, 23 Aug 2013 04:10:28 +0000 Date: Fri, 23 Aug 2013 04:10:00 -0000 From: Rich Felker 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: <20130823041028.GQ20515@brightrain.aerifal.cx> References: <20130823005820.GL20515@brightrain.aerifal.cx> 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) X-SW-Source: 2013-08/txt/msg00038.txt.bz2 On Fri, Aug 23, 2013 at 02:41:21AM +0100, Maciej W. Rozycki wrote: > > > 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. If you really care about supporting this, I have an alternate idea that doesn't lead to incompatible ABIs. Have GCC put static objects containing NANs in the writable data section, and add a new R_MIPS_NAN relocation type that flips the high bit of the NAN to match the runtime environment. The only difficulty would be making it work with static linking; you could choose to just have the static linker resolve all static objects containing NANs to a single, fixed NAN format at link time, or have some startup code to process them. For __builtin_nan() that's not used as a constant expression for initializing static objects, GCC can just generate a call to libgcc, or direct access to a global object, to flip the high bit appropriately. Rich