https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
Zeb Figura <zfigura at codeweavers dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |13.2.0
Keywords| |wrong-code
Target| |i686-linux-gnu
Component|c |target
Summary|gcc generates wrong code |manually defined memcpy()
|with |and memmove() incorrectly
| |handle overlap with -O2
| |-m32 -march=bdver2
--- Comment #2 from Zeb Figura <zfigura at codeweavers dot com> ---
Really sorry about that, I managed to accidentally hit the Enter key halfway
through writing the title. Here is the actual bug description:
--
Wine provides freestanding libraries, including manual definitions of memcpy()
and memmove() [1].
Those are defined in C, and while our definitions are *technically*
non-compliant C (violating the requirement that the pointers must point to the
same object), they should be fine for our targets, and anyway, the case I'm
running into is failure to handle overlap where the pointers *do* in fact point
into the same object. I can't find fault with the definitions themselves,
although I may be missing something.
We also, contrary to standards, give memcpy() the semantics of memmove(),
because some Windows programs are buggy and make that assumption. We do this by
copy-pasting the definition (I'm not sure why we do this rather than just
calling one function from the other, but it is what it is).
I recently started compiling with -march=native, and found that gcc was failing
to correctly handle overlap in memmove. Further investigation revealed that,
somehow, memmove() was being incorrectly optimized to *not* check for overlap,
while memcpy() remained in its unoptimized form.
I ran into this originally with the i686-w64-mingw32 target, but I've adjusted
the target to i686-linux-gnu since it happens there too. It does *not* happen
on x86_64.
[1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/string.c#l98
