public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/102386] [12 regression] bogus -Wrestrict for unreachable memcpy()
Date: Sat, 18 Sep 2021 22:48:02 +0000	[thread overview]
Message-ID: <bug-102386-4-35Xj2N5N8j@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102386-4@http.gcc.gnu.org/bugzilla/>

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |msebor at gcc dot gnu.org
           Keywords|                            |diagnostic
             Blocks|                            |84774

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is correct (at -O0 GCC issues a -Wuninitialized for dereferencing
the uninitialized pBlb), but I suspect you're expecting it to be suppressed
because the memcpy call is eliminated.  I've simplified the test case and
changed the names in it to make it easier to see what I assume you're really
pointing out:

$ cat pr102386.c && gcc -O2 -S  -Wall pr102386.c
struct S { int n, a[8]; };

static int n = 0;                   // not const but not modified

void f (struct S *p)
{
  if (n)                            // folded to false by ccp2
    {
      void *q = p->a, *r = p->a;
      int n = 8;
      __builtin_memcpy (q, r, n);   // -Wrestrict
    }
}
pr102386.c: In function ‘f’:
pr102386.c:11:7: warning: ‘__builtin_memcpy’ accessing 8 bytes at offsets 4 and
4 overlaps 8 bytes at offset 4 [-Wrestrict]
   11 |       __builtin_memcpy (q, r, n);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~

Although the memcpy call does ultimately end up removed (by ccp2) as
unreachable because the static global variable N is never set in the file, the
warning is issued before that happens, during folding.  This might change
if/when warnings are deferred until the end of compilation but I don't see this
use case as compelling enough to consider this particular instance a bug.  Feel
free to reopen it if you have a more compelling use case.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict

      reply	other threads:[~2021-09-18 22:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 10:43 [Bug middle-end/102386] New: " dimhen at gmail dot com
2021-09-18 22:48 ` msebor at gcc dot gnu.org [this message]

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-102386-4-35Xj2N5N8j@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).