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

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2022-02-10 22:18:59

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<std::array<uint64_t, 2>, std::array<uint64_t, 2>{0ULL, 9223160930622242816ULL}>;

#if defined(__cpp_inline_variables) && defined(__cpp_lib_bit_cast)
        inline constexpr float_internal128_t float128_snan_v = std::bit_cast<float_internal128_t>(float128_snan_array::value);
#else
        static const float_internal128_t float128_snan_v = reinterpret_cast<const float_internal128_t&>(float128_snan_array::value);
#endif
}}}}

#if __has_builtin(__builtin_nansq) /* gcc/clang */
        #define BOOST_CSTDFLOAT_FLOAT128_SNAN (__builtin_nansq(""))
#elif __has_builtin(__nansq) /* intel */
        #define BOOST_CSTDFLOAT_FLOAT128_SNAN (__nansq(""))
#else
        #define BOOST_CSTDFLOAT_FLOAT128_SNAN (boost::math::cstdfloat::detail::float128_snan_v)
#endif 

Hints
- intels __nanq returns a negative value, this can also happen with __nansq if available
- on big-endian machines, the values of the array may need to be swapped.

Gero.

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