| Message ID | 5b52263e-b0d2-03cf-2ae5-c0b2fcc50ff7@suse.cz |
|---|---|
| State | New |
| Headers | show |
| Series | Initialize a variable due to -Wmaybe-uninitialized. | expand |
On 11/18/19 6:17 AM, Martin Liška wrote: > Hi. > > The patch is about yet another bootstrap -Wmaybe-uninitialized warning. > I've just tested that on risv64 cross compiler with latest trunk. > > Ready to be installed? > Thanks, > Martin > > gcc/ChangeLog: > > 2019-11-18 Martin Liska <mliska@suse.cz> > > PR bootstrap/92540 > * config/riscv/riscv.c (riscv_address_insns): Initialize > addr in order to remove boostrap -Wmaybe-uninitialized > error. OK. I had this internally, but haven't had time to analyze if the warnings was a false positive or not. jeff
On Nov 18 2019, Jeff Law wrote: > On 11/18/19 6:17 AM, Martin Liška wrote: >> Hi. >> >> The patch is about yet another bootstrap -Wmaybe-uninitialized warning. >> I've just tested that on risv64 cross compiler with latest trunk. >> >> Ready to be installed? >> Thanks, >> Martin >> >> gcc/ChangeLog: >> >> 2019-11-18 Martin Liska <mliska@suse.cz> >> >> PR bootstrap/92540 >> * config/riscv/riscv.c (riscv_address_insns): Initialize >> addr in order to remove boostrap -Wmaybe-uninitialized >> error. > OK. I had this internally, but haven't had time to analyze if the > warnings was a false positive or not. IMHO it is a false positive. Andreas.
On Mon, 18 Nov 2019 09:58:19 PST (-0800), law@redhat.com wrote: > On 11/18/19 6:17 AM, Martin Liška wrote: >> Hi. >> >> The patch is about yet another bootstrap -Wmaybe-uninitialized warning. >> I've just tested that on risv64 cross compiler with latest trunk. >> >> Ready to be installed? >> Thanks, >> Martin >> >> gcc/ChangeLog: >> >> 2019-11-18 Martin Liska <mliska@suse.cz> >> >> PR bootstrap/92540 >> * config/riscv/riscv.c (riscv_address_insns): Initialize >> addr in order to remove boostrap -Wmaybe-uninitialized >> error. > OK. I had this internally, but haven't had time to analyze if the > warnings was a false positive or not. It's always initialized: the only path by which riscv_classify_address() doesn't initialize it is on an error, but riscv_classify_insns() handles that correctly -- well, at least without accessing an uninitialized variable, that implicit 3 is a bit ugly... Thanks for fixing this!
On Nov 21 2019, Palmer Dabbelt wrote: > It's always initialized: the only path by which riscv_classify_address() > doesn't initialize it is on an error, That is not true. Only if GET_CODE (x) == LO_SUM, but then it is only accessed if addr.type is ADDRESS_LO_SUM, which is equivalent. Andreas.
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c index 11a43c1b64d..9aa4d266e6b 100644 --- a/gcc/config/riscv/riscv.c +++ b/gcc/config/riscv/riscv.c @@ -857,7 +857,7 @@ riscv_legitimate_address_p (machine_mode mode, rtx x, bool strict_p) int riscv_address_insns (rtx x, machine_mode mode, bool might_split_p) { - struct riscv_address_info addr; + struct riscv_address_info addr = {}; int n = 1; if (!riscv_classify_address (&addr, x, mode, false))