[PATCH v2 0/5] fix uninitialized variable warning

[PATCH v2 0/5] fix uninitialized variable warning

[Chen Qun]

Hi all,
  There are some variables initialized warnings reported by the GCC_9.3 compiler.
This serial has added some default values or changed the assignment places for the variablies to fix them.

v1->v2:
--patch1: Drop it base on Max Filippov comment.
--patch2->patch1: Add Marcel Apfelbaum and  Yuval Shaia review comment.
--patch3->patch2: Add Philippe Mathieu-Daudé review comment.
--patch6->patch5: Add Philippe Mathieu-Daudé review comment.


Chen Qun (5):
  hw/rdma/rdma_backend: fix uninitialized variable warning in
    rdma_poll_cq()
  util/qemu-timer: fix uninitialized variable warning in
    timer_mod_anticipate_ns()
  util/qemu-timer: fix uninitialized variable warning for expire_time
  plugins/loader: fix uninitialized variable warning in
    plugin_reset_uninstall()
  migration: fix uninitialized variable warning in
    migrate_send_rp_req_pages()

 hw/rdma/rdma_backend.c | 2 +-
 migration/migration.c  | 2 +-
 plugins/loader.c       | 2 +-
 util/qemu-timer.c      | 8 +++-----
 4 files changed, 6 insertions(+), 8 deletions(-)

-- 
2.27.0

[PATCH v2 1/5] hw/rdma/rdma_backend: fix uninitialized variable warning in rdma_poll_cq()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
hw/rdma/rdma_backend.c: In function ‘rdma_poll_cq’:
hw/rdma/rdma_utils.h:25:5: warning: ‘ne’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 25 |     error_report("%s: " fmt, "rdma", ## __VA_ARGS__)
    |     ^~~~~~~~~~~~
hw/rdma/rdma_backend.c:93:12: note: ‘ne’ was declared here
 93 |     int i, ne, total_ne = 0;
    |            ^~

Add a default value for 'ne' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
---
Cc: Yuval Shaia <yuval.shaia.ml@gmail.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
---
 hw/rdma/rdma_backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index 5de010b1fa..2fe4a3501c 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -90,7 +90,7 @@ static void clean_recv_mads(RdmaBackendDev *backend_dev)
 
 static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq *ibcq)
 {
-    int i, ne, total_ne = 0;
+    int i, ne = 0, total_ne = 0;
     BackendCtx *bctx;
     struct ibv_wc wc[2];
     RdmaProtectedGSList *cqe_ctx_list;
-- 
2.27.0

[PATCH v2 2/5] util/qemu-timer: fix uninitialized variable warning in timer_mod_anticipate_ns()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
util/qemu-timer.c: In function ‘timer_mod_anticipate_ns’:
util/qemu-timer.c:474:8: warning: ‘rearm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  474 |     if (rearm) {
      |        ^

Change the default value assignment place to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
 util/qemu-timer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 81c28af517..8b73882fbb 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -459,7 +459,7 @@ void timer_mod_ns(QEMUTimer *ts, int64_t expire_time)
 void timer_mod_anticipate_ns(QEMUTimer *ts, int64_t expire_time)
 {
     QEMUTimerList *timer_list = ts->timer_list;
-    bool rearm;
+    bool rearm = false;
 
     WITH_QEMU_LOCK_GUARD(&timer_list->active_timers_lock) {
         if (ts->expire_time == -1 || ts->expire_time > expire_time) {
@@ -467,8 +467,6 @@ void timer_mod_anticipate_ns(QEMUTimer *ts, int64_t expire_time)
                 timer_del_locked(timer_list, ts);
             }
             rearm = timer_mod_ns_locked(timer_list, ts, expire_time);
-        } else {
-            rearm = false;
         }
     }
     if (rearm) {
-- 
2.27.0

[PATCH v2 3/5] util/qemu-timer: fix uninitialized variable warning for expire_time

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
util/qemu-timer.c: In function ‘timerlist_expired’:
util/qemu-timer.c:199:24: warning: ‘expire_time’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 199 |     return expire_time <= qemu_clock_get_ns(timer_list->clock->type);
     |            ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/qemu-timer.c: In function ‘timerlist_deadline_ns’:
util/qemu-timer.c:237:11: warning: ‘expire_time’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 237 |     delta = expire_time - qemu_clock_get_ns(timer_list->clock->type);
     |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Add a default value for 'expire_time' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
 util/qemu-timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 8b73882fbb..3910003e86 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -183,7 +183,7 @@ bool qemu_clock_has_timers(QEMUClockType type)
 
 bool timerlist_expired(QEMUTimerList *timer_list)
 {
-    int64_t expire_time;
+    int64_t expire_time = -1;
 
     if (!qatomic_read(&timer_list->active_timers)) {
         return false;
@@ -213,7 +213,7 @@ bool qemu_clock_expired(QEMUClockType type)
 int64_t timerlist_deadline_ns(QEMUTimerList *timer_list)
 {
     int64_t delta;
-    int64_t expire_time;
+    int64_t expire_time = -1;
 
     if (!qatomic_read(&timer_list->active_timers)) {
         return -1;
-- 
2.27.0

[PATCH v2 4/5] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
plugins/loader.c: In function ‘plugin_reset_uninstall’:
plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 382 |     data->ctx = ctx;
     |     ~~~~~~~~~~^~~~~

Add a default value for 'expire_time' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: "Alex Bennée" <alex.bennee@linaro.org>
---
 plugins/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/loader.c b/plugins/loader.c
index 8ac5dbc20f..88593fe138 100644
--- a/plugins/loader.c
+++ b/plugins/loader.c
@@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
                             bool reset)
 {
     struct qemu_plugin_reset_data *data;
-    struct qemu_plugin_ctx *ctx;
+    struct qemu_plugin_ctx *ctx = NULL;
 
     WITH_QEMU_LOCK_GUARD(&plugin.lock) {
         ctx = plugin_id_to_ctx_locked(id);
-- 
2.27.0

Re: [PATCH v2 4/5] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Alex Bennée]

Chen Qun <kuhn.chenqun@huawei.com> writes:

> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some variables
>  assignment statements in the macro may be considered as unexecuted by the compiler.
>
> When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
> plugins/loader.c: In function ‘plugin_reset_uninstall’:
> plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>  382 |     data->ctx = ctx;
>      |     ~~~~~~~~~~^~~~~
>
> Add a default value for 'expire_time' to prevented the warning.
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: "Alex Bennée" <alex.bennee@linaro.org>
> ---
>  plugins/loader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/plugins/loader.c b/plugins/loader.c
> index 8ac5dbc20f..88593fe138 100644
> --- a/plugins/loader.c
> +++ b/plugins/loader.c
> @@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
>                              bool reset)
>  {
>      struct qemu_plugin_reset_data *data;
> -    struct qemu_plugin_ctx *ctx;
> +    struct qemu_plugin_ctx *ctx = NULL;

This doesn't really fix anything because you would end up faulting if
you attempted to de-ref a NULL ctx. However...

>  
>      WITH_QEMU_LOCK_GUARD(&plugin.lock) {
>          ctx = plugin_id_to_ctx_locked(id);

...this can't fail. If the lookup failed and returned a NULL plugin then
we would abort(). So why can't the Euler Robot see that?

-- 
Alex Bennée

RE: [PATCH v2 4/5] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Chenqun (kuhn)]

> -----Original Message-----
> From: Alex Bennée [mailto:alex.bennee@linaro.org]
> Sent: Thursday, November 12, 2020 1:23 AM
> To: Chenqun (kuhn) <kuhn.chenqun@huawei.com>
> Cc: qemu-devel@nongnu.org; qemu-trivial@nongnu.org;
> peter.maydell@linaro.org; Zhanghailiang <zhang.zhanghailiang@huawei.com>;
> ganqixin <ganqixin@huawei.com>; Euler Robot <euler.robot@huawei.com>
> Subject: Re: [PATCH v2 4/5] plugins/loader: fix uninitialized variable warning in
> plugin_reset_uninstall()
> 
> 
> Chen Qun <kuhn.chenqun@huawei.com> writes:
> 
> > After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot
> > identify  that the statements in the macro must be executed. As a
> > result, some variables  assignment statements in the macro may be
> considered as unexecuted by the compiler.
> >
> > When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler
> showed warning:
> > plugins/loader.c: In function ‘plugin_reset_uninstall’:
> > plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> >  382 |     data->ctx = ctx;
> >      |     ~~~~~~~~~~^~~~~
> >
> > Add a default value for 'expire_time' to prevented the warning.
> >
> > Reported-by: Euler Robot <euler.robot@huawei.com>
> > Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> > ---
> > Cc: "Alex Bennée" <alex.bennee@linaro.org>
> > ---
> >  plugins/loader.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/plugins/loader.c b/plugins/loader.c index
> > 8ac5dbc20f..88593fe138 100644
> > --- a/plugins/loader.c
> > +++ b/plugins/loader.c
> > @@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
> >                              bool reset)  {
> >      struct qemu_plugin_reset_data *data;
> > -    struct qemu_plugin_ctx *ctx;
> > +    struct qemu_plugin_ctx *ctx = NULL;
> 
> This doesn't really fix anything because you would end up faulting if you
> attempted to de-ref a NULL ctx. However...
> 
> >
> >      WITH_QEMU_LOCK_GUARD(&plugin.lock) {
> >          ctx = plugin_id_to_ctx_locked(id);
> 
> ...this can't fail. If the lookup failed and returned a NULL plugin then we would
> abort(). So why can't the Euler Robot see that?
>
Hi Alex ,
  As the commit message says, this warning is reported by GCC 9.3 compilation.
EulerRobot configures various compilation options and uses GCC or Clang to compilation tests.

This warning has occurred since WITH_QEMU_LOCK_GUARD was added, because the current compiler thinks that the statements in WITH_QEMU_LOCK_GUARD{ } may not be executed successfully.
In fact, it may be wrong, but the current compiler is not very smart. So, this patch only adds an initialization, if it does not have a bad effect, it can fix the warning which may exist for a long time.

Thanks,
Chen Qun

[PATCH v2 5/5] migration: fix uninitialized variable warning in migrate_send_rp_req_pages()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
migration/migration.c: In function ‘migrate_send_rp_req_pages’:
migration/migration.c:384:8: warning: ‘received’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 384 |     if (received) {
     |        ^

Add a default value for 'received' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
Cc: Juan Quintela <quintela@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
---
 migration/migration.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 9bb4fee5ac..de90486a61 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -361,7 +361,7 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis,
                               RAMBlock *rb, ram_addr_t start, uint64_t haddr)
 {
     void *aligned = (void *)(uintptr_t)(haddr & (-qemu_ram_pagesize(rb)));
-    bool received;
+    bool received = false;
 
     WITH_QEMU_LOCK_GUARD(&mis->page_request_mutex) {
         received = ramblock_recv_bitmap_test_byte_offset(rb, start);
-- 
2.27.0

Re: [PATCH v2 5/5] migration: fix uninitialized variable warning in migrate_send_rp_req_pages()

[Dr. David Alan Gilbert]

* Chen Qun (kuhn.chenqun@huawei.com) wrote:
> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some variables
>  assignment statements in the macro may be considered as unexecuted by the compiler.
> 
> When the -Wmaybe-uninitialized capability is enabled on GCC9,the compiler showed warning:
> migration/migration.c: In function ‘migrate_send_rp_req_pages’:
> migration/migration.c:384:8: warning: ‘received’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>  384 |     if (received) {
>      |        ^
> 
> Add a default value for 'received' to prevented the warning.
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

Queuing this one via migration

> ---
> Cc: Juan Quintela <quintela@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> ---
>  migration/migration.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 9bb4fee5ac..de90486a61 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -361,7 +361,7 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis,
>                                RAMBlock *rb, ram_addr_t start, uint64_t haddr)
>  {
>      void *aligned = (void *)(uintptr_t)(haddr & (-qemu_ram_pagesize(rb)));
> -    bool received;
> +    bool received = false;
>  
>      WITH_QEMU_LOCK_GUARD(&mis->page_request_mutex) {
>          received = ramblock_recv_bitmap_test_byte_offset(rb, start);
> -- 
> 2.27.0
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

RE: [PATCH v2 0/5] fix uninitialized variable warning

[Chenqun (kuhn)]

Kindly ping!

Hi folks,
 Patch 1 to Patch 4 are not in the queue.  Could someone help pick them up?

Patch1~Patch4:
  hw/rdma/rdma_backend: fix uninitialized variable warning in
    rdma_poll_cq()
  util/qemu-timer: fix uninitialized variable warning in
    timer_mod_anticipate_ns()
  util/qemu-timer: fix uninitialized variable warning for expire_time
  plugins/loader: fix uninitialized variable warning in
    plugin_reset_uninstall()

Thanks,
Chen Qun

> -----Original Message-----
> From: Chenqun (kuhn)
> Sent: Wednesday, November 11, 2020 10:22 PM
> To: qemu-devel@nongnu.org; qemu-trivial@nongnu.org
> Cc: peter.maydell@linaro.org; Zhanghailiang
> <zhang.zhanghailiang@huawei.com>; ganqixin <ganqixin@huawei.com>;
> Chenqun (kuhn) <kuhn.chenqun@huawei.com>
> Subject: [PATCH v2 0/5] fix uninitialized variable warning
> 
> Hi all,
>   There are some variables initialized warnings reported by the GCC_9.3
> compiler.
> This serial has added some default values or changed the assignment places for
> the variablies to fix them.
> 
> v1->v2:
> --patch1: Drop it base on Max Filippov comment.
> --patch2->patch1: Add Marcel Apfelbaum and  Yuval Shaia review comment.
> --patch3->patch2: Add Philippe Mathieu-Daudé review comment.
> --patch6->patch5: Add Philippe Mathieu-Daudé review comment.
> 
> 
> Chen Qun (5):
>   hw/rdma/rdma_backend: fix uninitialized variable warning in
>     rdma_poll_cq()
>   util/qemu-timer: fix uninitialized variable warning in
>     timer_mod_anticipate_ns()
>   util/qemu-timer: fix uninitialized variable warning for expire_time
>   plugins/loader: fix uninitialized variable warning in
>     plugin_reset_uninstall()
>   migration: fix uninitialized variable warning in
>     migrate_send_rp_req_pages()
> 
>  hw/rdma/rdma_backend.c | 2 +-
>  migration/migration.c  | 2 +-
>  plugins/loader.c       | 2 +-
>  util/qemu-timer.c      | 8 +++-----
>  4 files changed, 6 insertions(+), 8 deletions(-)
> 
> --
> 2.27.0