https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #14)
> Reconfirmed with GCC 11 and the C test case below:
>
> void f (int);
>
> int main () {
> int i;
> int array[10];
> for (; i<10; ++i) { // no warning
> f (i); // no warning
> array [i] = i; // no warning, really hurts
> }
> }
So what's going "wrong" here is that we figure the BB with the i<10 check
post-dominates the entry block and thus is always executed. But when
doing warn_uninit on the SSA var we do not consider the value on the
always-executed path from entry (which is uninitialized i_3(D)).
That's for the early pass, the late pass doesn't run at -O0.
Note since we walk BBs in index order which 'i' we warn for is probably
random, I think we'll only warn once since we set TREE_NO_WARNING on the
underlying decl of the SSA name (that's probably misguided - different
SSA defs can have different uninit state).
It might be possible to populate possibly_undefined_names in the BB walk
by visiting PHIs and considering fallthru entries being taken to have this
work out without major restructuring of the pass (a lattice of "undefinedness"
would probably be more to the point).
