From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11817 invoked by alias); 23 Aug 2013 03:38:08 -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 11794 invoked by uid 89); 23 Aug 2013 03:38:08 -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 03:38:07 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1VCiCI-0001d2-00; Fri, 23 Aug 2013 03:38:03 +0000 Date: Fri, 23 Aug 2013 03:38: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: <20130823033802.GO20515@brightrain.aerifal.cx> References: <20130823005820.GL20515@brightrain.aerifal.cx> <20130823015727.GM20515@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/msg00035.txt.bz2 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. Rich