Re: Built-in testing for signaling nan?
On Nov 7 2013, FX wrote: Given how murky signaling NaNs are in practice, I think it's worth asking: why do you want to know? Because I am writing an implementation of the IEEE support modules in GNU Fortran, which are part of the Fortran 2003 standard. And the standard provides for a procedure (IEEE_CLASS) to distinguish between IEEE_SIGNALING_NAN and IEEE_QUIET_NAN. It doesn't explicitly state that supporting sNaN is required, so I can also just not return it. Yes. There is also the issue that the Fortran community (which gfortran follows) takes portability very seriously indeed, both over a very wide range of systems and over long periods of time. Simply saying if your system doesn't fit into one of these two categories, you can't have any of this facility is not regarded as reasonable. Those weren't/aren't the only ways NaNs could be provided. Unfortunately, that is probably the best that can be done for a reasonable amount of effort. I.e. to pass the buck back to base gcc, and put up with its restrictive view of the universe of 'IEEE 754 support'. Because this area is such a complete mess, most people interested in extreme portability will continue to ignore all of the IEEE 754 facilities, even in Fortran (which gets them at least part-right). I can't say that I am entirely happy with your effort, because the problem is that having the procedures available will encourage people to trust the IEEE features, and the real problems are in the optimisation and code generation. In particular, there will be pressure to remove optimisations and not add new ones because of perceived semantic conflicts - we have seen this very badly in the C world. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
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
Re: Built-in testing for signaling nan?
On Nov 6 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? Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. I don't know how reliable __builtin_nans() is, but a test is potentially even less reliable. Simply testing that bit MIGHT work, or it might be nothing more than a gotcha. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
On Wed, 6 Nov 2013, N.M. Maclaren wrote: Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. In GCC, the qnan_msb_set bit of struct real_format is what specifies the convention in use for a particular floating-point mode. -- Joseph S. Myers jos...@codesourcery.com
Re: Built-in testing for signaling nan?
Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. In GCC, the qnan_msb_set bit of struct real_format is what specifies the convention in use for a particular floating-point mode. A single bit necessarily conveys at most one bit of information. That can indicate whether the MSB being zero is the criterion; it cannot indicate what the criterion is if that is not the case. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
On Wed, 6 Nov 2013, N.M. Maclaren wrote: Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. In GCC, the qnan_msb_set bit of struct real_format is what specifies the convention in use for a particular floating-point mode. A single bit necessarily conveys at most one bit of information. That can indicate whether the MSB being zero is the criterion; it cannot indicate what the criterion is if that is not the case. There are only two conventions relevant to systems supported by GCC: the one where MSB of 1 indicates quiet NaN and 0 indicates signaling NaN (most systems) and the reverse one, where MSB of 0 indicates quiet NaN and 1 indicates signaling NaN (MIPS -mnan=legacy, HPPA). (Plus a few formats with no NaNs at all, but there __builtin_issignaling can just evaluate its argument for its side effects and return 0, like __builtin_isnan does.) -- Joseph S. Myers jos...@codesourcery.com
Re: Built-in testing for signaling nan?
On Wed, Nov 6, 2013 at 5:44 AM, FX fxcoud...@gmail.com 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? Given how murky signaling NaNs are in practice, I think it's worth asking: why do you want to know? Ian
Re: Built-in testing for signaling nan?
Given how murky signaling NaNs are in practice, I think it's worth asking: why do you want to know? Because I am writing an implementation of the IEEE support modules in GNU Fortran, which are part of the Fortran 2003 standard. And the standard provides for a procedure (IEEE_CLASS) to distinguish between IEEE_SIGNALING_NAN and IEEE_QUIET_NAN. It doesn’t explicitly state that supporting sNaN is required, so I can also just not return it. FX
