Am 10.02.22 um 14:07 schrieb John Maddock via Boost:
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?
Hi John, I can't think of anything besides the sledgehammer method (cast) either, assuming the value of gcc __builtin_nansq is universal.
namespace boost { namespace math { namespace cstdfloat { namespace detail {
using float128_snan_array = std::integral_constant
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.