https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- Created attachment 47612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47612&action=edit Translation unit to reproduce the warning. Attached is a cjdns-v20.4 translation unit that reproduces the warning with -O3 -Wall. For the record, here's what I replied to Jeff's report of the cjdns-v20.4 warning. The code that triggers the warning is these two assignments to two consecutive members of type unsigned char: header->unused = 0; header->flags = 1; GCC turns them into this single vector assignment to the first of them, overwriting both: vectp.336_252 = &header_139->flags; MEM <vector(2) unsigned char> [(unsigned char *)vectp.336_252] = { 1, 0 }; The warning is working correctly, it's just not prepared for GCC to do the sorts of transformations that are indistinguishable from invalid C code it is designed to warn for. I think this is also behind the Fortran PR 92956 (see the test case in comment 10). A possible workaround, if this is causing lots of false positives, is to detect this vectorization pattern and suppress the warning for it. It seems unlikely that it would the result of an accidental bug in the source code. Then again, bugs are often in tricky code that tries to do something "clever" and gets it wrong. Longer term, I think the robust solution is to distinguish these GCC transformations from user code. It could be done by simply setting some otherwise unused bit on the MEM_REF tree node used to represent them (this is my comment #13 on PR 92956). But that's probably GCC 11 material.
