public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "scovich at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/55288] New: Improve handling/suppression of maybe-uninitialized warnings Date: Mon, 12 Nov 2012 18:28:00 -0000 [thread overview] Message-ID: <bug-55288-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Bug #: 55288 Summary: Improve handling/suppression of maybe-uninitialized warnings Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: scovich@gmail.com Created attachment 28669 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28669 maybe-uninitialized false positive Enabling -Wmaybe-unused (part of -Wall) can result in false positives, which is fine (the warning is still quite useful). However, there is currently no way to disable such warnings on a per-variable basis. It is possible, but ineffective, to push a diagnostic pragma to ignore such warnings: Warnings are generated where the uninitialized value (!= variable) is eventually consumed, and that can easily happen outside the range covered by the pragma. Inlining makes the problem much worse [1]. The attached test case (reduced from actual code) illustrates the problem clearly, failing to compile with `-O2 -Wall -Werror' even though (a) the value *is* always written before being read and (b) even though the containing function has maybe-uninitialized warnings disabled. Adding -DWORKS allows it to compile by disabling the warning for the call site, even though the offending variable is not in scope at any part of the source code where the pragma is in effect. Since the compiler can clearly track which variable was the problem, I would instead propose a new variable attribute, ((maybe_uninitialized)), to suppress all maybe-uninitialized warnings the marked variable might trigger for its consumers. That way, known false positives can be whitelisted without disabling a useful warning for large swaths of unrelated code [2]. [1] First, it can vastly expand the number of problematice end points that lie outside the pragma (they may even reside in different files). Second, the resulting error message is extremely unhelpful, because it names the variable that was originally uninitialized, rather than the variable that ended up holding the "poisoned" value at the point of use (the former might not even be in the same file, let alone be in scope, and there's no easy way to figure out which of its uses causes the problem). It would be much better in this case if the diagnostic listed the call site(s) and/or assignments that led to the identified line of code depending on the potentially-uninitialized value, similar to how template substitution failures or errors in included headers are handled today. [2] Another potential solution would be to propagate the pragma to inlined call sites, but that seems like a horrifically hacky and error prone solution.
next reply other threads:[~2012-11-12 18:28 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-12 18:28 scovich at gmail dot com [this message] 2012-11-12 20:07 ` [Bug c++/55288] " manu at gcc dot gnu.org 2012-11-12 21:11 ` scovich at gmail dot com 2021-03-25 23:39 ` [Bug tree-optimization/55288] " msebor at gcc dot gnu.org 2021-04-09 17:42 ` cvs-commit at gcc dot gnu.org 2022-01-08 10:53 ` pinskia at gcc dot gnu.org 2022-02-01 22:24 ` egallager at gcc dot gnu.org 2022-09-14 13:20 ` rguenth 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-55288-4@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).