Why does memcpy cause compilers to seemingly forget about strict aliasing?

Question

Consider the following C++ code:

std::uint32_t func(std::uint32_t* p1, std::uint64_t* p2) {
    *p2 = *p1;
    return *p1;
}

Compiling with -O3 yields the following disassembly on Clang (GCC is similar):

func(unsigned int*, unsigned long*):
        mov     eax, dword ptr [rdi]
        mov     qword ptr [rsi], rax
        ret

(Live demo: https://godbolt.org/z/vKPvT7o51)

Due to the strict aliasing rule, the compiler assumes p1 and p2 don't point to the same memory location, and thus there is no need to reload *p1 from memory for the return statement. So far so good, optimisations are working as I expect.

---

Now consider a similar piece of code, where the copy is done via memcpy():

std::uint32_t func(std::uint32_t* p1, std::uint64_t* p2) {
    std::memcpy(p2, p1, sizeof(std::uint32_t));
    return *p1;
}

Disassembly (identical on Clang and GCC):

func(unsigned int*, unsigned long*):
        mov     eax, dword ptr [rdi]
        mov     dword ptr [rsi], eax
        mov     eax, dword ptr [rdi]
        ret

(Live demo: https://godbolt.org/z/rszEEc1Gr)

This time, *p1 is reloaded from memory, as if writing via p2 could have modified the memory at p1 - i.e. p1 and p2 could be aliased.
I find this to be strange, because:

1. The compiler already knows that p1 and p2 do not alias due to the strict aliasing rule, as demonstrated in the first example.
2. (Even if the above point is untrue) memcpy() has the requirement that its arguments cannot alias, otherwise it's UB. I presume that compilers are aware of this restriction and take advantage of it for optimisation purposes (otherwise you'd end up with a slower memcpy()).

Therefore it seems as though the use of memcpy() is causing the compiler to forget about these aliasing restrictions.

What is going on here?

• Is it simply a missed optimisation (or bug?) by the compiler?
• Is it behaviour somehow required by the Standard?
• Is it UB and thus we can't reason about the generated code?

---

On the point of UB, one line of possible reasoning is that the code is UB because the types of the source and destination are mismatched, which is likely not allowed (possibly violates the strict aliasing rule?). However, I do not believe this is true, because memcpy() copies at the byte level and it doesn't care what the types of its argument pointers are. p1 and p2 could just as well point to objects of the same type, but have been reinterpret_cast'd into different pointer types (which I believe is OK, as long as those pointers are not dereferenced, which they are not in this example).

One could then argue that if p1 and p2 could have been reinterpret_cast'd from any memory location, then they could alias, and thus the compiler must reload *p1 from memory. However, the restriction that memcpy()'s source and destination cannot overlap is still present, so the compiler should still know that p1 and p2 cannot alias.