[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Fixed by r11-1067.
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c1057cc0a8ad972e0a2218ab74038a56e5514c39 commit r11-1067-gc1057cc0a8ad972e0a2218ab74038a56e5514c39 Author: Martin Sebor Date: Mon Jun 8 09:06:48 2020 -0600 PR bootstrap/9 - powepc64 bootstrap failure due to -Wmaybe-uninitialized in reload_cse_simplify_operands gcc/ChangeLog: * postreload.c (reload_cse_simplify_operands): Clear first array element before using it. Assert a precondition.
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Host||powerpc64*-linux Target||powerpc64*-linux Last reconfirmed||2020-06-06 Build||powerpc64*-linux Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||patch Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547436.html
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Andreas Schwab changed: What|Removed |Added Host|powerpc64*-linux-gnu| Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu| --- Comment #5 from Andreas Schwab --- Can we please get bootstrap back?
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #4 from Bill Seurer --- bootstrap works with that patch
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Martin Sebor --- (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++)
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #2 from Andreas Schwab --- 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.
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #1 from Martin Sebor --- The reload_cse_simplify_operands() function allocates three arrays but resets only two: alternative_reject = XALLOCAVEC (int, recog_data.n_alternatives); alternative_nregs = XALLOCAVEC (int, recog_data.n_alternatives); alternative_order = XALLOCAVEC (int, recog_data.n_alternatives); memset (alternative_reject, 0, recog_data.n_alternatives * sizeof (int)); memset (alternative_nregs, 0, recog_data.n_alternatives * sizeof (int)); It then assigns to the alternative_order array in the loop below, but only conditionally: /* 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++) if (alternative_reject[i] <= alternative_reject[which_alternative]) alternative_order[j++] = i; recog_data.n_alternatives = j; Finally, it unconditionally reads the first element: /* Substitute the operands as determined by op_alt_regno for the best alternative. */ j = alternative_order[0]; I don't know this part of the compiler to tell if the first element is guaranteed to be stored into by the loop, and it seems that GCC can't figure it out either, so it issues the warning. That's expected. If the element is guaranteed to be set by the loop then storing a zero into it before the loop should be safe and avoid the warning. If it isn't, someone familiar with the code should look into what the right initial value should be. The affected code hasn't changed since 2003 but Jakub and Richard Sandiford have made changes to the function since then so they might be able to help. In the meantime, I would suggest zeroing out the first element to see if that helps. Bill, can you give it a try?
