In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
All of these problems related to getting confused in the optimizers in
various ways; sometimes we think things are uninitialized when they
obviously aren't; other times we don't warn when we obviously should,
etc. The set of places we warn is moving around from 3.4 to 4.0 to 4.1,
which annoys people using -Werror, especially if we have new false
positives.
I'm not going to try to advance my own personal views on the best
solution; I've lost that argument enough times already. So, let's start
with the premise that we're doing this in the optimizers.
I still think we should take the goals of consistency across releases,
across architectures, and across optimization levels seriously. For
-Wuninitialized, we should err on the side of warning too often. If
possible, we should try to sketch the rules we're using so that users
understand them.
I think users who set this flag generally want warnings about variables
that look unitialized, but happen not be used, or happen to be
initialized only in tricky ways; they're often using these warnings to
make their code robust not just today, but in the face of future
modification. I'd expect that most users want a warning about:
int x;
if (f())
x = 3;
return x;
even if f() happens to always return true on this system. (I don't know
that we don't warn in this case; it's just meant as an example of a case
where doing too much optimization might cause us to miss a warning
people want.) Certainly, this code from PR 22456:
int i;
while (i) ++i;
should trigger a warning. The fact that i is then never used, and thus
the loop is removed, is a fine optimization, but that shouldn't affect
whether or not a warning is issued. Bugs like:
void f(int j) {
int i; // Should be initialized.
while (j) i += j--;
return j; // Should be i, not j.
}
are not that rare; the fact that this function can be optimized to
"return 0" should not preclude the warning!
Maybe it would help to move the checks closer to the front of the
optimizer chain. We'd have less accuracy, but, probably, more consistency.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
