| Message ID | fe2d6965-ca04-a863-db0b-2b040894cf6d@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | avoid -Wmaybe-uninitialized in reload_cse_simplify_operands (PR bootstrap/95555) | expand |
On Sat, 2020-06-06 at 14:30 -0600, Martin Sebor via Gcc-patches wrote: > A recent enhancement to the uninitialized access coverage to include > dynamically allocated objects, including alloca and VLAs, triggers > an expected instance of -Wmaybe-uninitialized on powerpc64-linux > in reload_cse_simplify_operands where an element of an XALLOCAVEC- > allocated array is read before it's provably assigned to. With > -Werror this causes the bootstrap there to fail. > > The attached patch avoids the warning by clearing the element first. > > Although not necessary to avoid the warning, the patch also adds > an assert to verify that the array isn't accessed outside its bounds. > recog.c sets which_alternative to -1 in a couple of places and > a number of tests for it being equal to it so I added the assert > "just to be sure." > > Tested on x86_64-linux (the warning was also confirmed gone on > powerpc64 by the reporter). > > Martin > PR bootstrap/95555 - 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. OK jeff
On Sat, 6 Jun 2020 at 22:30, Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > A recent enhancement to the uninitialized access coverage to include > dynamically allocated objects, including alloca and VLAs, triggers > an expected instance of -Wmaybe-uninitialized on powerpc64-linux > in reload_cse_simplify_operands where an element of an XALLOCAVEC- > allocated array is read before it's provably assigned to. With > -Werror this causes the bootstrap there to fail. > > The attached patch avoids the warning by clearing the element first. > > Although not necessary to avoid the warning, the patch also adds > an assert to verify that the array isn't accessed outside its bounds. > recog.c sets which_alternative to -1 in a couple of places and > a number of tests for it being equal to it so I added the assert > "just to be sure." > > Tested on x86_64-linux (the warning was also confirmed gone on > powerpc64 by the reporter). > Thanks for the fix, I've seen the same problem on arm and aarch64 (don't know why bootstrap still works on x86_64) Christophe > Martin
PR bootstrap/95555 - 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. diff --git a/gcc/postreload.c b/gcc/postreload.c index f6258285022..c9e637500f1 100644 --- a/gcc/postreload.c +++ b/gcc/postreload.c @@ -592,6 +592,13 @@ 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; + gcc_assert (!recog_data.n_alternatives + || (which_alternative >= 0 + && which_alternative < recog_data.n_alternatives)); + /* 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++)