[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen stable-4.16] bunzip: work around gcc13 warning
commit 49116b2101094c3d6658928f03db88d035ba97be Author: Jan Beulich <jbeulich@xxxxxxxx> AuthorDate: Tue Mar 21 13:52:58 2023 +0100 Commit: Jan Beulich <jbeulich@xxxxxxxx> CommitDate: Tue Mar 21 13:52:58 2023 +0100 bunzip: work around gcc13 warning 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@xxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 402195e56de0aacf97e05c80ed367d464ca6938b master date: 2023-03-14 10:45:28 +0100 --- xen/common/bunzip2.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/common/bunzip2.c b/xen/common/bunzip2.c index 2087cfbbed..5108e570ed 100644 --- a/xen/common/bunzip2.c +++ b/xen/common/bunzip2.c @@ -233,6 +233,11 @@ static int __init get_next_block(struct bunzip_data *bd) 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)) -- generated by git-patchbot for /home/xen/git/xen.git#stable-4.16
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |