From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4293 invoked by alias); 28 May 2015 17:49:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 4282 invoked by uid 89); 28 May 2015 17:49:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Thu, 28 May 2015 19:33:00 -0000 From: Joseph Myers To: Wilco Dijkstra CC: =?ISO-8859-2?Q?'Ond=F8ej_B=EDlka'?= , , Subject: RE: Gcc builtin review: isinf, insnan ... In-Reply-To: <000e01d0988d$686514d0$392f3e70$@com> Message-ID: References: <000e01d0988d$686514d0$392f3e70$@com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-05/txt/msg00802.txt.bz2 On Wed, 27 May 2015, Wilco Dijkstra wrote: > Note the GCC built-ins are actually incorrect and should not be used until > they are fixed to use integer arithmetic. The GLIBC versions are never GCC bug report number? Is the problem something other than general issues with -fsignaling-nans not making everything correct for the presence of signaling NaNs (as documented)? If there are signaling NaN issues but not other issues, the built-in functions could be used conditional on __SUPPORT_SNAN__ to fix bugs 15367 and 17441, provided (a) comments referred to applicable GCC bug reports for any signaling NaN issues, with those bug reports referring back to getting the glibc comments updated when fixed in GCC, and (b) if uses in glibc rely on proper signaling NaN handling, glibc were made to build with -fsignaling-nans (not the default in GCC). It's certainly the case that substantial GCC work is needed to make floating-point properly follow even C99/C11 Annex F regarding exceptions / rounding modes, let alone make signaling NaNs follow TS 18661-1, though the signaling NaNs fixes would probably be more straightforward (reviewing lots of code and making local changes, rather than any tricky design issues involved for other floating-point areas). While I think such support would be desirable, it also seems there's limited demand for it. It's not obvious that integer arithmetic is optimal in all cases (if the implementation is otherwise correct given the compiler options passed). For example, if the argument is in a floating-point register and an integer implementation would involve the (architecture-specific) costs of moving it to an integer register - obviously something that can only be decided quite late in code generation. -- Joseph S. Myers joseph@codesourcery.com