On 25/02/2022 21:51, Gero Peterhoff via Boost wrote:
Apologies for the delay, I meant to reply to your previous message: here's the basic issue, yes you can create a __float128 which has the bit pattern a signalling NaN would have if supported, but based on my local tests on Mingw it's not actually supported by GCC or clang - which is to say they don't *raise a signal when used*.
Unless you have a use case, and/or can show that __float128 is capable of raising a floating point exception when loaded into memory (and remember that we're talking about a type that is really a software emulation under the hood), then I just don't see signally NaN's as being supported for this type?
Thanks, John. Hi John, it is already clear to me that float128/libquadmath is only a sw-emulation, where not all features are supported at the moment. But with http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1467r5.html that will change (and then we won't have to bother with these problems any longer). Nevertheless, it makes sense to prepare the boost-libs now; be it just numeric_limits<float128>::signaling_NaN() to make isnan/fpclassify work. Unfortunately, I've only now found out that the gcc-builtins are not consistent and libquadmath::nanq doesn't work correctly. Reported the bugs and am waiting for an answer.
To quote from the paper: "It is currently implementation-defined whether or not the floating-point types support infinity and NaN. That is not changing. That feature will still be implementation-defined, even for extended floating-point types." There is still no requirement to support NaN at all, much less signally NaN's which are traditionally dependent upon the underlying hardware. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus