User account creation filtered due to spam.
I'd accept "may be used uninitialized", but I'm positively told
"is used uninitialized", which ain't true.
This is similar to bugs 32395 and 22197: apologies if it turns out to be
a mere duplicate. My code example is much simpler than the examples
given for those bugs: there are no aggregate types, the parameter
passing isn't interesting, and initialisation obviously DOES happen.
Also seen in 4.1.2 (I got around to building 4.2.0 so I could
verify the problem...)
The warning is attached to the line where 'diff' is assigned a
value. Note that this value is not then used again.
Required flags: -c -Wuninitialized -O1
(n.b.: -Wuninitialized is incompatible with -O0, but any other -O<n> will do)
No headers required.
double Find_Limit(double xcentre, unsigned ang)
ang &= 1U;
xlimit = xcentre;
xlimit = xcentre;
diff = xlimit;
return ang ? xlimit : 0.0;
} /* End of function Find_Limit() */
Removing the assignment to diff (which isn't used) demotes
"is uninitialized" to "may be uninitialized". Combining the two
case-clauses of the switch statement under the same header
(case 0U: case 1U: <stuff>) likewise demotes. Removing the use of
xlimit in the final (returned-value) expression removes the warning
entirely (so it DOES notice that diff isn't used - or is it more
confused than I think?)
If, in the assignments to xlimit, the right-hand expressions are replaced
with literal constants, the warning disappears entirely - even if the
two literal constants are unequal. So does the compiler recognise
that the two handled cases in the switch are exhaustive or doesn't it?
This looks deeply strange to me.
What is happening is that for the switch statement, we don't know that the value can't be just 0 or 1 at the point where we warn. We should be able to lower this switch statement into an if statement and get better results.
I have gone through this removing many repetitions of "see above for my
actual bug report". Please take it as read (and see above for my actual
I explicitly said that the mere confession of ignorance ("may be used
uninitialized") was not a problem. The claim that 'xlimit' IS used
uninitialized is false. I don't see that it is in any way justified
by claiming more rather than less ignorance. The mistake is sensitive
to internal rearrangement (without changed semantics) of the clauses
in the 'switch' statement, and also to the presence or absence of the
assignment to 'diff' following the 'switch' statement. It's hard to
see in what sense ignorance about the possible values of 'ang' is
affected by either feature of the code. Even if it is, the mistake is
still a mistake. The offered explanation is certainly not complete,
since it sheds no light on its selective appearance (well, none to my
possibly poor eyesight, anyway).
Oh but what happens is we do some duplication of code (for 4.2 at least) and then we see the variable is used unitialization. This has changed in the trunk to a may used uninitialized but the issue is still the same, we should not get an may or an is unitialized variable warning anyways as it can never be used unitialized.
Basically, when we reach "diff = xlimit;" we don't know that xlimit must be initialized. This may end up in different scenarios depending on the SSA tree finally generated. In any of those scenarios, not warning is sheer luck.
If you remove the assignment to diff, still when we reach "ang ? xlimit : 0.0;" we don't know that xlimit is always initialized. We get the "may be" because we don't know the value of "ang", so xlimit may not be used at all.
Finally, I guess that using constants make the warning disappear because the constant-propagation pass assumes that the uninitialized value of xlimit is either of the constants and thus xlimit is never used uninitialized.
My conclusion here is that we should not get a "is uninitialized". Maybe we can use the fact that the block is not entered 100% of times to avoid saying "is used"?
Nonetheless, avoiding the warning completely depends on being able to avoid a default case for the switch (which is a missed-optimization in VRP and not a diagnostics problem).
Fixed at -O2 since GCC 4.4.