https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #46 from Richard Biener <rguenth at gcc dot gnu.org> --- I'll note that restrict on the parameters can help optimizing the copying loop because you can then unroll and hoist loads before stores. I'll also note that almost all (important) targets implement memcpy with special assembler in libc. But yes, a compiler might, seeing void foo (char * __restrict d, char * s) { *d = *s; if (d != s) abort (); } optimize the compare to always true because of the wording of the C standard with regard to restrict. GCC doesn't (yet) do this. A compiler might also transform foo (p, p); to trap (as part of eliminating paths with undefined behavior) if it can analyze foo inter-procedurally seeing that foo will always invoke undefined behavior if d == s. For memcpy the same would hold true but the compiler would need to know that the size of the copy is not zero. So yes, the most clean solution would be to have __forgiving_memcpy possibly also allowing NULL pointers when n == 0 besides allowing the exact overlap. Its prototype wouldn't have restrict then or nonnull. This all doesn't change the fact that GCC up to now always assumed memcpy with exact overlap is fine to do, so it's practically impossible to change implementations without recompiling the world with a "fixed" compiler.