https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #4 from Deniz Bahadir <D.Bahadir at GMX dot de> --- (In reply to Jonathan Wakely from comment #3) > (In reply to Deniz Bahadir from comment #1) > > Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if > > `__builtin_memcpy` should be usable from a `constexpr` context. > > Why? std::memcpy isn't usable in constant expressions. Revision 0 of P0202 (https://wg21.link/p0202r0) originally had the following text in section III.B: "B. std::memmove and std::memcpy must have constexpr additions std::memmove and std::memcpy accept void* and const void* parameters. This makes them impossible to implement in pure C++ as constexpr, because constant expressions can not evaluate a conversion from type cv void * to a pointer-to-object type according to [expr.const]. However those functions are not only popular, but also are widely used across Standard Library to gain better performance. Not making them constexpr will force standard Library developer to have compiler intrinsics for them anyway. This is a hard step that must be done." That was rejected at the committee meeting in Jacksonville in early 2018 and the section was replaced by the following: "During the Jacksonville meeting it was decided not to modify the <cstring> headers, leading to a decision to use compiler specific intrinsics instead of functions from <cstring> header." To me that sounds as if compiler-intrinsics like `__builtin_memcpy` should instead be usable in `constexpr` contexts. > It might be useful if it could be used, but the fact it can't currently > isn't a bug. OK, then consider this issue a feature-request and a question. As the link to Compiler Explorer shows the compiler is already able to calculate the result of the entire function call at compile-time when called from a non-`constexpr` context. Shouldn't it then be able to still do so in a `constexpr` context, too? (As I mentioned, e.g. for `__builtin_bswap32` that is possible.)
