Possible infinite loop in target/arm/sme_helper.c: helper_sme_fmopa_h
I'm implementing a new GCC warning, -Wanalyzer-infinite-loop (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147).
My new warning is firing on a loop in qemu-7.2.0's target/arm/sme_helper.c, in 'helper_sme_fmopa_h'.
Looking at "master" here: https://gitlab.com/qemu-project/qemu/-/blame/master/target/arm/tcg/sme_helper.c?ref_type=heads?ref_type=heads&page=2#L1052 the relevant code seems unchanged from 7.2.0
Consider the "for" loop at line 1064:
1064 for (col = 0; col < oprsz; ) {
1065 uint16_t pcol = pm[H2(col >> 4)];
1066 do {
1067 if (prow & pcol & 0b0101) {
1068 uint32_t *a = vza_row + H1_4(col);
1069 uint32_t m = *(uint32_t *)(vzm + H1_4(col));
1070
1071 m = f16mop_adj_pair(m, pcol, 0);
1072 *a = f16_dotadd(*a, n, m, &fpst_std, &fpst_odd);
1073
1074 col += 4;
1075 pcol >>= 4;
1076 }
1077 } while (col & 15);
1078 }
If I'm reading it right, "col" is only ever modified within the loop at line 1074:
1074 col += 4;
but that's guarded by:
1067 if (prow & pcol & 0b0101) {`
My warning is reasoning that if the condition at line 1067 doesn't hold, "col" won't change and so "pcol" will be read from the same location and thus be the same on subsequent iterations, and so the condition continue to fail to hold. Hence if the condition at line 1067 ever fails to hold, the "for" loop at line 1064 will become infinite.
I'm inclined to agree with it, hence this report.
Does this look like a bug in qemu to you, or am I missing something?
Hope this is helpful
Dave