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

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2022-02-25 21:51:58

> 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.

regards
Gero