[PATCH v2] bunzip: work around gcc13 warning

Jan Beulich posted 1 patch 11 months, 2 weeks ago
Test gitlab-ci passed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/eecec806-1728-2efb-ad69-862fcca5ba75@suse.com
[PATCH v2] bunzip: work around gcc13 warning
Posted by Jan Beulich 11 months, 2 weeks ago
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))

Re: [PATCH v2] bunzip: work around gcc13 warning
Posted by Andrew Cooper 11 months, 2 weeks ago
On 13/03/2023 2:10 pm, Jan Beulich wrote:
> 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>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>