From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32626 invoked by alias); 23 Aug 2013 04:08:07 -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 32601 invoked by uid 89); 23 Aug 2013 04:08:07 -0000 X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,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-f176.google.com (HELO mail-pd0-f176.google.com) (209.85.192.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 04:07:38 +0000 Received: by mail-pd0-f176.google.com with SMTP id q10so161194pdj.35 for ; Thu, 22 Aug 2013 21:07:36 -0700 (PDT) X-Received: by 10.66.220.103 with SMTP id pv7mr18886493pac.29.1377230856680; Thu, 22 Aug 2013 21:07:36 -0700 (PDT) Received: from [192.168.1.16] (76-253-2-104.lightspeed.sntcca.sbcglobal.net. [76.253.2.104]) by mx.google.com with ESMTPSA id mr3sm18510527pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 21:07:35 -0700 (PDT) References: <20130823005820.GL20515@brightrain.aerifal.cx> <20130823015727.GM20515@brightrain.aerifal.cx> <20130823033802.GO20515@brightrain.aerifal.cx> Mime-Version: 1.0 (1.0) In-Reply-To: <20130823033802.GO20515@brightrain.aerifal.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6DDE6A09-5E4D-4FCF-B126-7021735F431F@gmail.com> 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 04:08:00 -0000 To: Rich Felker X-SW-Source: 2013-08/txt/msg00037.txt.bz2 On Aug 22, 2013, at 8:38 PM, Rich Felker wrote: > On Thu, Aug 22, 2013 at 08:10:49PM -0700, pinskia@gmail.com wrote: >>>> 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 compatibl= e, >>>=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. >>=20 >> Can you give an example and maybe a link to a GCC bug where this is >> recorded before spreading this kind of information. I really don't >> like blank statements without facts to back up them. >=20 > int foo() { double x =3D 0; x /=3D 0.0; return 1; } >=20 > While this is a stupid, trivial example, the issue has come up A LOT > for us in musl's implementation of the math library (based on fdlibm) > with nontrivial code. Wait you mean dead code? I think the standard/IEEE allows to remove it. At = -O0, GCC won't remove it though. >=20 > Rich