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 jos...@codesourcery.com
