From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5551 invoked by alias); 23 Aug 2013 04:12:57 -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 5527 invoked by uid 89); 23 Aug 2013 04:12:57 -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:12:26 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1VCijW-0001ik-00; Fri, 23 Aug 2013 04:12:22 +0000 Date: Fri, 23 Aug 2013 04:12:00 -0000 From: Rich Felker To: pinskia@gmail.com Cc: "Maciej W. Rozycki" , "libc-ports@sourceware.org" , "libc-alpha@sourceware.org" , Doug Gilmore Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support Message-ID: <20130823041222.GR20515@brightrain.aerifal.cx> References: <20130823005820.GL20515@brightrain.aerifal.cx> <20130823015727.GM20515@brightrain.aerifal.cx> <20130823033802.GO20515@brightrain.aerifal.cx> <6DDE6A09-5E4D-4FCF-B126-7021735F431F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DDE6A09-5E4D-4FCF-B126-7021735F431F@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-08/txt/msg00039.txt.bz2 On Thu, Aug 22, 2013 at 09:07:34PM -0700, pinskia@gmail.com wrote: > 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: > >>>> > >>>> 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, > >>> > >>> 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 > >> recorded before spreading this kind of information. I really don't > >> like blank statements without facts to back up them. > > > > int foo() { double x = 0; x /= 0.0; return 1; } > > > > 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. They don't. Anyway, here's a less trivial example: double f(int y){ double x=0; x/=0; if(y) return 1; return x; } > At -O0, GCC won't remove it though. That's not helpful; -O0 is not usable for most purposes. The output is gigantic and slow. And if I'm not mistaken, there are some cases where even -O0 will mess it up... Rich