[Bug string/31055] Request: guarantee that memcpy(x, x, n) is well-defined

["post+sourceware.org at ralfj dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31055

--- Comment #4 from Ralf Jung <post+sourceware.org at ralfj dot de> ---
> I think with this extra constraint we can't really mark the memcpy as having 'restrict' arguments, which would also have extra performance implications.

Does anything change in the generated assembly for memcpy when the arguments
are vs are not `restrict`? If yes, that would be a sign that compilers should
probably stop using `memcpy(x, x, n)`... but it seems unlikely, given how
heavily hand-tuned that code already is.

> And I think valgrind will need to at least keep this warning for non-glibc targets, which I am not it would simplify things.

It would at least give solid motivation for the to support the option of a libc
that allows this, e.g. via a flag.

> Maybe the best way would to follow the __memcmpeq route, where it was added solely for compile usage.

That's also a possibility, of course. Though I assume adding a new symbol would
take forever to propagate through the ecosystem. Also, would that symbol be for
GCC only or also for other compilers? It would not be great to have a GCC-only
solution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.