https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95555
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #2)
> alternative_order[0] is guaranteed to be set, because alternative_reject[i]
> <= alternative_reject[which_alternative] for i == which_alternative at
> least. We know that which_alternative < recog_data.n_alternatives,
> otherwise alternative_reject[which_alternative] would be undefined.
That's another way of saying that the code must be correct because otherwise it
would be undefined. (There is no obvious constraint that which_alternative is
less than recog_data.n_alternatives.)
But if clearing alternative_order[0] is safe and if avoids the warning it's
fine with me. Bill, can you please confirm that the patch below suppresses it
(I can't reproduce it on my end)?
diff --git a/gcc/postreload.c b/gcc/postreload.c
index f6258285022..9b4e2bd9efb 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -592,6 +592,10 @@ reload_cse_simplify_operands (rtx_insn *insn, rtx testreg)
}
}
+ /* The loop below sets alternative_order[0] but -Wmaybe-uninitialized
+ can't know that. Clear it here to avoid the warning. */
+ alternative_order[0] = 0;
+
/* Record all alternatives which are better or equal to the currently
matching one in the alternative_order array. */
for (i = j = 0; i < recog_data.n_alternatives; i++)
