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: unassig...@gcc.gnu.org
ReportedBy: scov...@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.
