Am 21.08.22 um 23:25 schrieb Proton:
On Aug 21, 2022, at 1:26 PM, Gero Peterhoff via Boost
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
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