From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Subject: [PATCH v2] bunzip: work around gcc13 warning
Date: Mon, 13 Mar 2023 15:10:23 +0100 [thread overview]
Message-ID: <eecec806-1728-2efb-ad69-862fcca5ba75@suse.com> (raw)
While provable that length[0] is always initialized (because symCount
cannot be zero), upcoming gcc13 fails to recognize this and warns about
the unconditional use of the value immediately following the loop.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511.
Reported-by: Martin Liška <martin.liska@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Put new code on a separate line and add comment.
---
RFC: We've cloned this code from Linux and the code is unchanged there.
Therefore the same issue should exist there, and we may better get
whatever workaround is going to be applied there. But I'm unaware
of the issue, so far, having been observed in and reported against
Linux. This may be because they disable the maybe-uninitialized
warning by default, and they re-enable it only when building with
W=2.
--- a/xen/common/bunzip2.c
+++ b/xen/common/bunzip2.c
@@ -233,6 +233,11 @@ static int __init get_next_block(struct
becomes negative, so an unsigned inequality catches
it.) */
t = get_bits(bd, 5)-1;
+ /* GCC 13 has apparently improved use-before-set detection, but
+ it can't figure out that length[0] is always intialized by
+ virtue of symCount always being positive when making it here.
+ See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511. */
+ length[0] = 0;
for (i = 0; i < symCount; i++) {
for (;;) {
if (((unsigned)t) > (MAX_HUFCODE_BITS-1))
next reply other threads:[~2023-03-13 14:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 14:10 Jan Beulich [this message]
2023-03-13 14:13 ` [PATCH v2] bunzip: work around gcc13 warning Andrew Cooper
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=eecec806-1728-2efb-ad69-862fcca5ba75@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.