public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "zfigura at codeweavers dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2 Date: Sun, 08 Oct 2023 00:19:54 +0000 [thread overview] Message-ID: <bug-111722-4-eJbVgK2OUl@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111722-4@http.gcc.gnu.org/bugzilla/> 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
next prev parent reply other threads:[~2023-10-08 0:19 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-07 23:51 [Bug c/111722] New: gcc generates wrong code with zfigura at codeweavers dot com 2023-10-08 0:09 ` [Bug c/111722] " pinskia at gcc dot gnu.org 2023-10-08 0:19 ` zfigura at codeweavers dot com [this message] 2023-10-08 0:21 ` [Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2 zfigura at codeweavers dot com 2023-10-08 0:28 ` pinskia at gcc dot gnu.org 2023-10-08 0:50 ` zfigura at codeweavers dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-111722-4-eJbVgK2OUl@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).