[cfe-dev] Clang builtins for C++20 STL features

[Erik Pilkington via cfe-dev]

On 2018-11-29 5:55 PM, Stephan T. Lavavej via cfe-dev wrote:
> Hi Clang devs,
>
> WG21 has voted in a bunch of C++20 STL features that need compiler support via builtins/intrinsics. As usual, MSVC's STL would like to use identically-named builtins for Clang, C1XX, and EDG, so I wanted to ask if you've chosen any names (and interfaces) yet. Also as usual, I have utterly no opinion about naming - any name that gets the compiler to do my work for me is amazing (as long as all compilers are consistent). :-)
>
> * P0595R2 std::is_constant_evaluated()
> Should this be __is_constant_evaluated() or __builtin_is_constant_evaluated() or something else?
>
> * P0482R6 char8_t
> Given std::is_constant_evaluated(), we might not need anything new here. Otherwise, should there be analogues of __builtin_memcmp(), __builtin_strlen(), and __builtin_char_memchr() for constexpr char_traits<char8_t>?
>
> * P0476R2 std::bit_cast()
> This came up a month ago, where Richard Smith suggested __builtin_bit_cast(To, value) or __bit_cast<To>(value), preferring the former (for C friendliness). Was a final name chosen?

Not formally, but I'm working on a patch that uses the 
__builtin_bit_cast(To, value) spelling, so lets just go with that.

>
> * P0528R3 Atomic Compare-And-Exchange With Padding Bits
> We need compiler magic here, in some form. Billy O'Neal wrote to the C1XX team: "To implement the new atomic_ref as well as the change to compare the value representation of atomics only, the library needs a way to zero out the padding in arbitrary T, which we can't discover with library tech alone. We would like an intrinsic that accepts a trivially-copyable T and produces a copy with the padding zeroed, or takes a T* and zeros the padding inside that T, or similar."
>
> * P0758R1 std::is_nothrow_convertible
> This can be implemented without an intrinsic (std::is_nothrow_invocable_r already demands it; std::is_convertible plus noexcept plus library cleverness works), but an intrinsic is higher throughput (and simpler for third-party libraries that want to imitate the STL without using the STL for whatever reason). MSVC's spelling for the plain trait is __is_convertible_to(From, To); should the new trait be __is_nothrow_convertible_to(From, To) or __is_nothrow_convertible(From, To)?
>
> * P1007R3 std::assume_aligned()
> MSVC supports a general __assume() although I'm unsure if it's applicable/desirable here. Should there be a dedicated builtin?
>
> * I think this list is complete but I might be missing some features.
>
> Thanks,
> STL
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev