https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> Created attachment 47612 [details]
> 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.
Another solution is to make the vectorizer not use &header_139->flags
but instead &MEM[header_139 + offsetof(flags)].
