Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk