From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Pan Nengyuan <pannengyuan@huawei.com>
Cc: zhang.zhanghailiang@huawei.com, qemu-devel@nongnu.org,
euler.robot@huawei.com
Subject: Re: [PATCH] op_helper: fix some compile warnings
Date: Mon, 20 Apr 2020 18:49:14 +0900 [thread overview]
Message-ID: <87mu76v65h.wl-ysato@users.sourceforge.jp> (raw)
In-Reply-To: <b55a0120-55bb-eb9b-208c-13a01fb8af06@huawei.com>
On Mon, 20 Apr 2020 18:18:39 +0900,
Pan Nengyuan wrote:
>
>
>
> On 4/20/2020 4:50 PM, Yoshinori Sato wrote:
> > On Mon, 20 Apr 2020 14:49:59 +0900,
> > Pan Nengyuan wrote:
> >>
> >> We got the following compile-time warnings(gcc7.3):
> >> /mnt/sdb//qemu/target/rx/op_helper.c: In function ‘helper_scmpu’:
> >> /mnt/sdb/qemu/target/rx/op_helper.c:213:24: error: ‘tmp1’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> env->psw_c = (tmp0 >= tmp1);
> >> ~~~~~~^~~~~~~~
> >> /mnt/sdb/qemu/target/rx/op_helper.c:213:24: error: ‘tmp0’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> /mnt/sdb/qemu/target/rx/op_helper.c: In function ‘helper_suntil’:
> >> /mnt/sdb/qemu/target/rx/op_helper.c:299:23: error: ‘tmp’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> env->psw_c = (tmp <= env->regs[2]);
> >> ~~~~~^~~~~~~~~~~~~~~~
> >> /mnt/sdb/qemu/target/rx/op_helper.c: In function ‘helper_swhile’:
> >> /mnt/sdb/qemu/target/rx/op_helper.c:318:23: error: ‘tmp’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> env->psw_c = (tmp <= env->regs[2]);
> >>
> >> Actually, it looks like a false-positive because it will enter the body of while loop and init it for the first time.
> >> Let's change 'while' to 'do .. while' to avoid it.
> >
> > OK.
> >
> >> Reported-by: Euler Robot <euler.robot@huawei.com>
> >> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
> >> ---
> >> target/rx/op_helper.c | 12 ++++++------
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/target/rx/op_helper.c b/target/rx/op_helper.c
> >> index f89d294f2b..b612ab1da8 100644
> >> --- a/target/rx/op_helper.c
> >> +++ b/target/rx/op_helper.c
> >> @@ -201,14 +201,14 @@ void helper_scmpu(CPURXState *env)
> >> if (env->regs[3] == 0) {
> >> return;
> >> }
> >> - while (env->regs[3] != 0) {
> >> + do {
> >> tmp0 = cpu_ldub_data_ra(env, env->regs[1]++, GETPC());
> >> tmp1 = cpu_ldub_data_ra(env, env->regs[2]++, GETPC());
> >> env->regs[3]--;
> >> if (tmp0 != tmp1 || tmp0 == '\0') {
> >> break;
> >> }
> >> - }
> >> + } while (env->regs[3] != 0);
> >> env->psw_z = tmp0 - tmp1;
> >> env->psw_c = (tmp0 >= tmp1);
> >> }
> >> @@ -287,14 +287,14 @@ void helper_suntil(CPURXState *env, uint32_t sz)
> >> if (env->regs[3] == 0) {
> >> return ;
> >> }
> >> - while (env->regs[3] != 0) {
> >> + do {
> >> tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> >> env->regs[1] += 1 << sz;
> >> env->regs[3]--;
> >> if (tmp == env->regs[2]) {
> >> break;
> >> }
> >> - }
> >> + } while (env->regs[3] != 0);
> >> env->psw_z = tmp - env->regs[2];
> >> env->psw_c = (tmp <= env->regs[2]);
> >> }
> >> @@ -306,14 +306,14 @@ void helper_swhile(CPURXState *env, uint32_t sz)
> >> if (env->regs[3] == 0) {
> >> return ;
> >> }
> >> - while (env->regs[3] != 0) {
> >> + do {
> >> tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> >> env->regs[1] += 1 << sz;
> >> env->regs[3]--;
> >> if (tmp != env->regs[2]) {
> >> break;
> >> }
> >> - }
> >> + } while (env->regs[3] != 0);
> >> env->psw_z = env->regs[3];
> >> env->psw_c = (tmp <= env->regs[2]);
> >> }
> >> --
> >> 2.18.2
> >>
> >>
> >
> > It looks different result in env->regs[3] is zero.
>
> If env->regs[3] is zero, it will return at the begin of these functions:
>
> if (env->regs[3] == 0) {
> return;
> }
>
> Thus, the while loop will not be reached.
> In this case, I think 'while' and 'do .. while' will get the same result and it will disappear the warnings.
Oh. Sorry. I misunderstood.
Since the pseudo code described in the manual uses while,
I think it's easier for everyone to understand by following
the description.
> > In such a case, nothing changes.
> >
> > I think that the warning of the uninitialized variable
> > will disappear by fixing as follows.
> >
>
> Yes, it also can fix these warnings.
OK. Thanks.
> Thanks.
>
> >>From 5de0c54a970e01e96b41870252d0ea54ec61c540 Mon Sep 17 00:00:00 2001
> > From: Yoshinori Sato <ysato@users.sourceforge.jp>
> > Date: Mon, 20 Apr 2020 17:41:04 +0900
> > Subject: [PATCH] target/rx/op_helper: Fix uninitialized warning.
> >
> > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> > ---
> > target/rx/op_helper.c | 101 ++++++++++++++++++++----------------------
> > 1 file changed, 49 insertions(+), 52 deletions(-)
> >
> > diff --git a/target/rx/op_helper.c b/target/rx/op_helper.c
> > index f89d294f2b..f84f6c706c 100644
> > --- a/target/rx/op_helper.c
> > +++ b/target/rx/op_helper.c
> > @@ -284,38 +284,36 @@ void helper_suntil(CPURXState *env, uint32_t sz)
> > {
> > uint32_t tmp;
> > tcg_debug_assert(sz < 3);
> > - if (env->regs[3] == 0) {
> > - return ;
> > - }
> > - while (env->regs[3] != 0) {
> > - tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> > - env->regs[1] += 1 << sz;
> > - env->regs[3]--;
> > - if (tmp == env->regs[2]) {
> > - break;
> > + if (env->regs[3] > 0) {
> > + while (env->regs[3] != 0) {
> > + tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> > + env->regs[1] += 1 << sz;
> > + env->regs[3]--;
> > + if (tmp == env->regs[2]) {
> > + break;
> > + }
> > }
> > + env->psw_z = tmp - env->regs[2];
> > + env->psw_c = (tmp <= env->regs[2]);
> > }
> > - env->psw_z = tmp - env->regs[2];
> > - env->psw_c = (tmp <= env->regs[2]);
> > }
> >
> > void helper_swhile(CPURXState *env, uint32_t sz)
> > {
> > uint32_t tmp;
> > tcg_debug_assert(sz < 3);
> > - if (env->regs[3] == 0) {
> > - return ;
> > - }
> > - while (env->regs[3] != 0) {
> > - tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> > - env->regs[1] += 1 << sz;
> > - env->regs[3]--;
> > - if (tmp != env->regs[2]) {
> > - break;
> > + if (env->regs[3] > 0) {
> > + while (env->regs[3] != 0) {
> > + tmp = cpu_ldufn[sz](env, env->regs[1], GETPC());
> > + env->regs[1] += 1 << sz;
> > + env->regs[3]--;
> > + if (tmp != env->regs[2]) {
> > + break;
> > + }
> > }
> > + env->psw_z = env->regs[3];
> > + env->psw_c = (tmp <= env->regs[2]);
> > }
> > - env->psw_z = env->regs[3];
> > - env->psw_c = (tmp <= env->regs[2]);
> > }
> >
> > /* accumlator operations */
> > @@ -325,40 +323,39 @@ void helper_rmpa(CPURXState *env, uint32_t sz)
> > int32_t result_h;
> > int64_t tmp0, tmp1;
> >
> > - if (env->regs[3] == 0) {
> > - return;
> > - }
> > - result_l = env->regs[5];
> > - result_l <<= 32;
> > - result_l |= env->regs[4];
> > - result_h = env->regs[6];
> > - env->psw_o = 0;
> > + if (env->regs[3] > 0) {
> > + result_l = env->regs[5];
> > + result_l <<= 32;
> > + result_l |= env->regs[4];
> > + result_h = env->regs[6];
> > + env->psw_o = 0;
> >
> > - while (env->regs[3] != 0) {
> > - tmp0 = cpu_ldfn[sz](env, env->regs[1], GETPC());
> > - tmp1 = cpu_ldfn[sz](env, env->regs[2], GETPC());
> > - tmp0 *= tmp1;
> > - prev = result_l;
> > - result_l += tmp0;
> > - /* carry / bollow */
> > - if (tmp0 < 0) {
> > - if (prev > result_l) {
> > - result_h--;
> > - }
> > - } else {
> > - if (prev < result_l) {
> > - result_h++;
> > + while (env->regs[3] != 0) {
> > + tmp0 = cpu_ldfn[sz](env, env->regs[1], GETPC());
> > + tmp1 = cpu_ldfn[sz](env, env->regs[2], GETPC());
> > + tmp0 *= tmp1;
> > + prev = result_l;
> > + result_l += tmp0;
> > + /* carry / bollow */
> > + if (tmp0 < 0) {
> > + if (prev > result_l) {
> > + result_h--;
> > + }
> > + } else {
> > + if (prev < result_l) {
> > + result_h++;
> > + }
> > }
> > - }
> >
> > - env->regs[1] += 1 << sz;
> > - env->regs[2] += 1 << sz;
> > + env->regs[1] += 1 << sz;
> > + env->regs[2] += 1 << sz;
> > + }
> > + env->psw_s = result_h;
> > + env->psw_o = (result_h != 0 && result_h != -1) << 31;
> > + env->regs[6] = result_h;
> > + env->regs[5] = result_l >> 32;
> > + env->regs[4] = result_l & 0xffffffff;
> > }
> > - env->psw_s = result_h;
> > - env->psw_o = (result_h != 0 && result_h != -1) << 31;
> > - env->regs[6] = result_h;
> > - env->regs[5] = result_l >> 32;
> > - env->regs[4] = result_l & 0xffffffff;
> > }
> >
> > void helper_racw(CPURXState *env, uint32_t imm)
> >
--
Yosinori Sato
next prev parent reply other threads:[~2020-04-20 9:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 5:49 [PATCH] op_helper: fix some compile warnings Pan Nengyuan
2020-04-20 3:13 ` no-reply
2020-04-20 8:50 ` Yoshinori Sato
2020-04-20 9:18 ` Pan Nengyuan
2020-04-20 9:49 ` Yoshinori Sato [this message]
2020-04-20 11:04 ` Pan Nengyuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mu76v65h.wl-ysato@users.sourceforge.jp \
--to=ysato@users.sourceforge.jp \
--cc=euler.robot@huawei.com \
--cc=pannengyuan@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).