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