From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27700 invoked by alias); 23 Aug 2013 03:11:24 -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 27681 invoked by uid 89); 23 Aug 2013 03:11:23 -0000 X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=BAYES_20,FREEMAIL_FROM,KHOP_THREADED,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 03:10:54 +0000 Received: by mail-pd0-f179.google.com with SMTP id v10so115514pde.10 for ; Thu, 22 Aug 2013 20:10:52 -0700 (PDT) X-Received: by 10.66.243.196 with SMTP id xa4mr619348pac.174.1377227452600; Thu, 22 Aug 2013 20:10:52 -0700 (PDT) Received: from [10.0.0.141] ([75.94.136.65]) by mx.google.com with ESMTPSA id wp8sm2511990pbc.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 20:10:51 -0700 (PDT) References: <20130823005820.GL20515@brightrain.aerifal.cx> <20130823015727.GM20515@brightrain.aerifal.cx> Mime-Version: 1.0 (1.0) In-Reply-To: <20130823015727.GM20515@brightrain.aerifal.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: "Maciej W. Rozycki" , "libc-ports@sourceware.org" , "libc-alpha@sourceware.org" , Doug Gilmore From: pinskia@gmail.com Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support Date: Fri, 23 Aug 2013 03:11:00 -0000 To: Rich Felker X-SW-Source: 2013-08/txt/msg00034.txt.bz2 On Aug 22, 2013, at 6:57 PM, Rich Felker wrote: > On Fri, Aug 23, 2013 at 02:41:21AM +0100, Maciej W. Rozycki wrote: >> On Fri, 23 Aug 2013, Rich Felker wrote: >>=20 >>>> As many of you have been aware it has been a long practice for softwar= e=20 >>>> using IEEE 754 floating-point arithmetic run on MIPS processors to use= an=20 >>>> encoding of Not-a-Number (NaN) data different to one used by software = run=20 >>>> on other processors. And as of IEEE 754-2008 revision [1] this encodi= ng=20 >>>> does not follow one recommended in the standard, as specified in secti= on=20 >>>> 6.2.1, where it is stated that quiet NaNs should have the first bit (d= 1)=20 >>>> of their significand set to 1 while signalling NaNs should have that b= it=20 >>>> set to 0, but MIPS software interprets the two bits in the opposite=20 >>>> manner. >>>>=20 >>>> As from revision 3.50 [2][3] the MIPS Architecture provides for=20 >>>> processors that support the IEEE 754-2008 preferred NaN encoding forma= t.=20=20 >>>> As the two formats (further referred to as "legacy NaN" and "2008 NaN"= )=20 >>>> are incompatible to each other, tools will have to provide support for= the=20 >>>> two formats to help people avoid using incompatible binary modules. H= ere=20 >>>> is the glibc part. >>>=20 >>> 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. >>=20 >> To give you a small example this: >>=20 >> double foo =3D __builtin_nan (""); >>=20 >> will compile to a different data pattern with opposite (qNaN vs sNaN)=20 >> semantics depending on the NaN encoding mode selected in the compiler.= =20=20 >> Modules built with different NaN encodings are therefore not compatible, >=20 > They are compatible except in the area of subtle exception-raising > semantics that GCC *DOES NOT GET CORRECT ANYWAY*. GCC is full of > incorrect optimizations that cause the exception flags to be wrong. > Until that's fixed, I don't see why this issue is so important to > merit flagging object files build with different modes as having an > incompatible ABI. The semantics are slightly different, but the type > sizes and the way they're passed are all the same, and programs that > don't use the GCC extension __builtin_nan() or the NAN macro from > math.h, or writing raw float values to/from disk, are completely > unaffected. Can you give an example and maybe a link to a GCC bug where this is recorde= d before spreading this kind of information. I really don't like blank sta= tements without facts to back up them. Thanks, Andrew Pinski >=20 >> either at the link or at the load time, as applicable. LD (from binutil= s)=20 >> and ld.so take care of the link-time and the load-time integrity check,= =20 >> respectively. >>=20 >> Additionally hardware has to be configured to match the encoding selecte= d=20 >> and executables that require a NaN encoding that is not supported by a=20 >> given piece of hardware have to be rejected -- execve(2) is supposed to= =20 >> return in that case, which may only be handled by the kernel. Please no= te=20 >> that neither the legacy-NaN nor the 2008-NaN encoding is mandatory in th= e=20 >> MIPS architecture; MIPS FPU hardware at the implementer's discretion may= =20 >> support either or both. >>=20 >> I hope this answers your question. Any further concerns? >=20 > I'm just opposed to introducing massive complexity and spurious linker > errors for the sake of something that shouldn't affect most programs, > and where the only affected programs already had wrong behavior due to > GCC's lack of proper support for floating point exception and > rounding-mode semantics. Signaling NANs are an obscure, optional > feature almost nobody uses, and if you're not intentionally using > them, you don't care if computations with NANs raise spurious > exceptions or not (especially since the exception was already raised > when you first generated the NAN, unless you loaded a NAN explicitly > via the NAN macro or strtod("NAN", 0)... >=20 > Rich