Built-in testing for signaling nan?

[Joseph S. Myers]

On Wed, 6 Nov 2013, FX wrote:

> GCC has a number of floating-point-related type-generic built-ins, which 
> are great and which we largely rely on in the gfortran runtime library 
> (rather than depending on the possibly poor-quality target math 
> library).
> 
> However, I have not been able to find a way to test for a signaling NaN 
> using the existing built-ins? __builtin_fpclassify() and 
> __builtin_isnan() both return the same thing for quite and signaling 
> NaNs. We have a __builtin_nans() function to generate a signaling NaN, 
> but nothing to find one.
> 
> Am I missing something? Would it be hard to implement such a built-in?

All the usual caveats about floating-point exception and rounding mode 
support in GCC (that optimizations may not reliably respect exceptions and 
rounding modes even when the selected command-line options indicate that 
they should, that operations may not raise the right exceptions, etc.) 
apply here, but to a greater extent - even with -fsignaling-nans, 
signaling NaNs may well not work reliably (whether "reliably" means in 
accordance with the old WG14 proposal from which the __SUPPORT_SNAN__ 
macro was taken, the more recent C bindings in draft TS 18661-1, or 
something else).  I don't know if the existing type-generic built-ins 
properly handle signaling NaNs (this means, for example, that 
__builtin_isnan and other classification built-ins should not raise 
INVALID even for signaling NaN operands, at least if -fsignaling-nans is 
used).

You could certainly implement __builtin_issignaling - but you'd probably 
run into similar issue to those found when adding the issignaling macro 
from draft TS 18661-1 to glibc, that signaling NaNs can get turned into 
quiet NaNs (with INVALID raised) on loads (on 32-bit x86 at least).  See 
bugs 56831 and 58416, at least (the latter shows there's a wrong-code bug 
even for code that never uses NaNs directly at all and so shouldn't even 
need -fsignaling-nans).

-- 
Joseph S. Myers
joseph@codesourcery.com