Re: std::numeric_limits<__float128>::signaling_NaN + __float128-Type

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-02-26 09:45:45

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