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/98871] Cannot silence -Wmaybe-uninitialized at declaration site
Date: Fri, 29 Jan 2021 00:49:01 +0000	[thread overview]
Message-ID: <bug-98871-4-FBbMNSoaMl@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-98871-4@http.gcc.gnu.org/bugzilla/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
   Last reconfirmed|                            |2021-01-29
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=98465,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=98512
     Ever confirmed|0                           |1
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
             Blocks|                            |24639

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed.  The root cause of the problem is that the #pragma diagnostic
suppression machinery consider only one location but that location may be
different depending on the warning and depending on inlining.  For some
warnings it's the location of the call site into which the problem statement
has been inlined.  For others it might be the original location of the
statement itself.  -Wuninitialized and -Wmaybe-uninitialized happen to fall
into the first category.

The solution I posted for pr98465 and pr98512 lets it consider both (or all
locations along the inlining stack) and, with an minor extension, makes the
suppression work in this case as well.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

  parent reply	other threads:[~2021-01-29  0:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 21:44 [Bug c/98871] New: " 1zeeky at gmail dot com
2021-01-28 21:46 ` [Bug c/98871] " 1zeeky at gmail dot com
2021-01-29  0:49 ` msebor at gcc dot gnu.org [this message]
2021-01-29  0:59 ` [Bug middle-end/98871] " msebor at gcc dot gnu.org
2021-01-29 21:56 ` msebor at gcc dot gnu.org
2021-01-29 21:56 ` msebor at gcc dot gnu.org
2021-06-10 23:31 ` msebor at gcc dot gnu.org
2021-07-02 22:20 ` cvs-commit at gcc dot gnu.org
2021-07-06 19:43 ` cvs-commit at gcc dot gnu.org
2021-11-12 19:44 ` msebor at gcc dot gnu.org

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-98871-4-FBbMNSoaMl@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).