Message ID | 20200106015700.52992-1-pannengyuan@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | arm/translate-a64: fix uninitialized variable warning | expand |
On 1/6/20 11:57 AM, pannengyuan@huawei.com wrote: > From: Pan Nengyuan <pannengyuan@huawei.com> > > Fixes: > target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512': > target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in this function [-Werror=maybe-uninitialized] > genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used uninitialized in this function [-Werror=maybe-uninitialized] > if (!feature) { > > Reported-by: Euler Robot <euler.robot@huawei.com> > Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> > Cc: Peter Maydell <peter.maydell@linaro.org> Are you compiling with reduced optimization? The compiler should be able to prove that these variables are initialized. It certainly does with -O2, on all known gcc versions. Perhaps a better fix is to add a default: g_assert_not_reached(); entry to the o == 0 switch. Though of course opcode must be in [0-3], based on the extraction mask, so a default label isn't actually reachable. But that's the only path I can see for which incomplete optimization would fail to prove initialization. r~
On 1/6/2020 10:15 AM, Richard Henderson wrote: > On 1/6/20 11:57 AM, pannengyuan@huawei.com wrote: >> From: Pan Nengyuan <pannengyuan@huawei.com> >> >> Fixes: >> target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512': >> target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> if (!feature) { >> >> Reported-by: Euler Robot <euler.robot@huawei.com> >> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> >> Cc: Peter Maydell <peter.maydell@linaro.org> > > Are you compiling with reduced optimization? The compiler should be able to > prove that these variables are initialized. It certainly does with -O2, on all > known gcc versions. Yes, I compile it with optimization flags (-O2) and get this warnings. The gcc version is 8.2.1. > > Perhaps a better fix is to add a > > default: > g_assert_not_reached(); > > entry to the o == 0 switch. Though of course opcode must be in [0-3], based on > the extraction mask, so a default label isn't actually reachable. But that's > the only path I can see for which incomplete optimization would fail to prove > initializatio Yes, a default label is a better way. > > r~ >
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c index d4bebbe629..211e3d813f 100644 --- a/target/arm/translate-a64.c +++ b/target/arm/translate-a64.c @@ -13564,8 +13564,8 @@ static void disas_crypto_three_reg_sha512(DisasContext *s, uint32_t insn) int rm = extract32(insn, 16, 5); int rn = extract32(insn, 5, 5); int rd = extract32(insn, 0, 5); - bool feature; - CryptoThreeOpFn *genfn; + bool feature = false; + CryptoThreeOpFn *genfn = NULL; if (o == 0) { switch (opcode) {