[Bug c++/94082] __builtin_memcpy in constexpr context should compile

["D.Bahadir at GMX dot de" <gcc-bugzilla@gcc.gnu.org>]

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