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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-02-10 13:07:21

On 07/02/2022 19:18, Gero Peterhoff via Boost wrote:
> Hello,
> please see https://godbolt.org/z/Ksshxvhaj
>
> 1) std::numeric_limits<__float128>::signaling_NaN always returns 0 but gcc-__builtin_nansq doesn't. I think __builtin_nansq is correct as it is also distinct from std::numeric_limits<__float128>::quiet_NaN (__builtin_nanq).
Can you submit a PR please?  We would probably need to check for the 
presence of the intrinsic with __has_intrinsic as I don't *think* it's 
always been available?
>
> 2) The types __float128, __extension__ __float128 (gcc) and _Quad (intel) are identical, but there are different definitions in boost/config/detail/suffix.hpp and boost/math/cstdfloat/cstdfloat_types.hpp.
> I think it would make sense to have just one definition or is there a reason why it was done that way? If yes, which one is it?
> You could always use __float128 directly and/or adjust boost/config/detail/suffix.hpp so that it also works with clang/intel.
> Which way would be better?

There are two points here: __float128 and _Quad have similar 
functionality, but are different types with a different set of support 
functions and headers.  You also need to remember that Boost.Math is now 
usable standalone (ie without the rest of Boost, including 
Boost.Config), so there will be some duplication of effort, but as it's 
a one line configuration, I really don't see that as a big issue?

John.

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus