Why does constexpr context make the compiler fail, while w/o it optimizes perfectly?

Question

I played around with constexpr and realized some interesting behavior:

• In some situations adding constexpr in front of a function enables GCC to try optimizing harder which results in fully optimizing the function away and just providing the calculated value.
• However, calling such a fully optimized function from a constexpr context results in errors because it internally uses (compiler-built-in) functions/intrinsics which are not marked constexpr (in particularly memcpy).
• (Clang fails directly when applying constexpr to such a function, even without a constexpr context.)

Why is that so?

• Shouldn't the compiler (GCC) be able to still optimize, even in constexpr context?
• C++ proposal P0202 (which made it into C++20) wanted to make functions like memcpy constexpr (see section III.B in original revision), but that was rejected and changed because compiler-built-in versions of such functions would achieve the same (see section III.A in latest revision).
• So, are GCC and Clang wrong in not allowing memcpy in constexpr functions/context? (Note: memcpy and __builtin_memcpy are equivalent.)

---

As examples are easier to understand, here is such an example.
(You can even see it more comfortably with its results in Compiler Explorer here.)

Note: I was unable to come up with a simple example where simply adding constexpr to the function helped the GCC optimizer to fully optimize, which it otherwise would not. But believe me, that I have such examples, which are more complicated (and sadly closed-source).

#include <array>
#include <cstdint>
#include <cstring>

constexpr std::uint32_t extract(const std::uint8_t* data) noexcept
{
    std::uint32_t num;
    memcpy(&num, data, sizeof(std::uint32_t));
    return num;
}

int main()
{
    constexpr std::array<std::uint8_t, 4> a1 {{ 0xff, 0xff, 0xff, 0xff }};
    /*constexpr*/ auto val = extract(a1.data());  // <--- Using constexpr here makes compiler fail.
    return val;
}

GCC is able to optimize this to just:

main:     # @main
    mov   eax, -1
    ret

Clang can optimize it too, if removing the constexpr in front of the function definition.

However, if commenting in the constexpr in front of the function call (and thereby calling the function from constexpr context) the compiler fails with something like this:

GCC:

<source>: In function 'int main()':
<source>:15:33:   in 'constexpr' expansion of 'extract(a1.std::array<unsigned char, 4>::data())'
<source>:8:11: error: 'memcpy(((void*)(& num)), ((const void*)(& a1.std::array<unsigned char, 4>::_M_elems)), 4)' is not a constant expression
    8 |     memcpy(&num, data, sizeof(std::uint32_t));
      |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiler returned: 1

Clang:

<source>:5:25: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
constexpr std::uint32_t extract(const std::uint8_t* data) noexcept
                        ^
<source>:8:5: note: non-constexpr function 'memcpy' cannot be used in a constant expression
    memcpy(&num, data, sizeof(std::uint32_t));
    ^
<source>:15:20: error: constexpr variable 'val' must be initialized by a constant expression
    constexpr auto val = extract(a1.data());  // <--- Error!
                   ^     ~~~~~~~~~~~~~~~~~~
<source>:8:5: note: non-constexpr function 'memcpy' cannot be used in a constant expression
    memcpy(&num, data, sizeof(std::uint32_t));
    ^
<source>:15:26: note: in call to 'extract(&a1._M_elems[0])'
    constexpr auto val = extract(a1.data());  // <--- Error!

                         ^
2 errors generated.
Compiler returned: 1

Answer 1

According to dcl.constexpr

For a constexpr function or constexpr constructor that is neither defaulted nor a template, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression, or, for a constructor, an evaluated subexpression of the initialization full-expression of some constant-initialized object ([basic.start.static]), the program is ill-formed, no diagnostic required.

As memcpy is not constexpr, your program is ill formed NDR.

Using the function in contsexpr context would allow to have diagnostic.

In some situations adding constexpr in front of a function enables GCC to try optimizing harder which results in fully optimizing the function away and just providing the calculated value.

It is a good hint (as inline before).

constexpr function can be "misused":

constexpr std::size_t factorial(std::size_t n) {/*..*/}

int main()
{
    std::cout << factorial(5); // computed at runtime (but probably optimized)
}

Correct way would be

int main()
{
    constexpr auto fact5 = factorial(5); // computed at compile time
    std::cout << fact5; 
}