[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.