[Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2

["zfigura at codeweavers dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722

--- Comment #5 from Zeb Figura <zfigura at codeweavers dot com> ---
(In reply to Andrew Pinski from comment #4)
> There is no bug here.
> ICF finds that your definition of memcpy is the same as memmove and merges
> the 2 and then calls memcpy from your memmove and then inlines the normal
> memcpy because well it says it is the same.

I suppose I understand this explanation, but it does not feel like a very
intuitive behaviour.

The ICF part makes sense. The choice to optimize a builtin memcpy/memmove call
into a different instruction sequence (which doesn't match the original) also
makes sense. I would not really expect these two to be combined in this manner,
though. memmove() is not calling builtin memcpy(), it is calling our
implementation of memcpy(), which doesn't have the same semantics as builtin
memcpy().

[It also seems odd to me that func2() would be replaced with a builtin memcpy()
rather than a builtin memmove()?]

> You can just use -fno-builtin to fix the issue by saying memcpy and memmove
> are not builtins and treat them like normal functions.
> 
> That fixes the issue by not inlining the target defined memcpy.

Fair enough, I guess. I suppose that's the right thing to do anyway...