[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] arm/translate-a64: fix uninitialized variable warning
From: |
Pan Nengyuan |
Subject: |
Re: [PATCH] arm/translate-a64: fix uninitialized variable warning |
Date: |
Mon, 6 Jan 2020 10:45:30 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
On 1/6/2020 10:15 AM, Richard Henderson wrote:
> On 1/6/20 11:57 AM, address@hidden wrote:
>> From: Pan Nengyuan <address@hidden>
>>
>> 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 <address@hidden>
>> Signed-off-by: Pan Nengyuan <address@hidden>
>> Cc: Peter Maydell <address@hidden>
>
> 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~
>