RE: Gcc builtin review: isinf, insnan ...

[Joseph Myers <joseph at codesourcery dot com>]

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