Re: bug - boost::math::ccmath::copysign not work

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2022-08-21 23:52:57

Am 21.08.22 um 23:25 schrieb Proton:
> 
> 
>> On Aug 21, 2022, at 1:26 PM, Gero Peterhoff via Boost <boost_at_[hidden]> wrote:
>>
>> Am 19.08.22 um 03:53 schrieb Proton via Boost:
>>> Using __builtin_bit_cast should be fine for conditional C++17 support since we already rely on __builtin_is_constant_evaluated. I’ll play with it this weekend and see where it get us. Worst case is we static_assert unsupported cases like John suggested.
>>
>> Hi Matt,
>> I see that you have started work on ccmath::signbit/copysign/etc. I also. Our basic problem is that std::bit_cast is only available with C++20. You are already trying to provide this for C++17 (BOOST_MATH_BIT_CAST). My questions:
>> - can you *guarantee* that BOOST_MATH_BIT_CAST works on/with all platforms/compilers ?
>> - if not: does it make sense to upgrade ccmath to C++20 so that std::bit_cast is available ?
>>
>> Otherwise I can only oracle and provide code to the best of my knowledge - without guarantee that it works on/with all platforms/compilers :-(
>>
>> regards
>> Gero
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

>> <OpenPGP_signature.sig>
> 
> 
> Gero,
> 
> I can make no such guarantees. I do not think it makes sense to upgrade to C++20 because BOOST_MATH_BIT_CAST macro enables C++17 support. If you look at the comments even with a move to C++20 Clang does not yet support constexpr std::bit_cast/__builtin_bit_cast with bit-fields. I have provided layouts for 64, 80, and 128 bit long doubles so most platforms should be covered if the toolchain supports it.
> 
> Matt

Hi Matt,
I haven't tried whether clang's bit_cast supports bit fields. There is a problem with your simple implementation:
Memory size for long double/float80 can be 10/12/16 bytes depending on platform or compiler option. You didn't take that into account, so bit_cast then fails.

That's why I'm working on extended structures for the bitrepresentation for float-types, so that unusual or machine-specific types can also be mapped. These then also include manipulating the individual components and/or checking for special values. For the concrete implementations it would be advantageous to have a stable bit_cast; otherwise I can only use explicit bitpatterns and hope they are (ieee) compatible.

This approach has other advantages. These extended structures always deliver correct results, even if the compiler option fast-math/finite-math or something similar is set. This can be used to implement various requirements, e.g. isnan/isinf:
- isnan/isinf -> default
- isnan_stable/isinf_stable -> correct results also with fast/finite-math etc

This can be very useful when implementing math functions.

Best, Gero