https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120138
--- Comment #7 from Thor Preimesberger <tcpreimesberger at gmail dot com> --- (In reply to Andrew Pinski from comment #6) > (In reply to Andrew Pinski from comment #5) > > The code does look like in the case of M being between 0 and 7 will cause > > use of the uninitilized r[1]. > > Actually I did my math wrong, it is between 1 and 8. The control flow of the original source is pretty nasty and only really makes sense in the context of the rest of the original project, fbgemm. There's some bit swizzling to make sure that M has a value that is a multiple of 16. There are also analogous functions in the original source with the same control flow, but they don't trigger -Wmaybe-uninit. (e.g. transpose_32x4_block, etc...). Also, looking at tree-ssa-uninit.cc, I'm not certain that the specific value of these variables actually even affect the analysis behind -Wmaybe-uninit, as we're just walking vdefs. I might be wrong though. But all this would make me guess that something funny is happening in gcc itself. Here's the upstream file FWIW: https://github.com/pytorch/FBGEMM/blob/main/src/UtilsAvx512.cc The current version initializes r[0] and r[1] to zero as a work around in transpose_16x2_block, but not in any others.
