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

  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: link
Be 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).