https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423
--- Comment #21 from pipcet at protonmail dot com --- Created attachment 61848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61848&action=edit patch documenting the problem This is obviously not something we should consider applying, but this patch contains a workaround which compares accesses bit-by-bit, determining whether each bit is in a hole or not. It appears to fix both testcases, but I'm not sure it's actually correct. The idea is that if two accesses differ in their hole patterns, we never merge them into the same access group, so the bug can't happen. Of course the actual comparison of the hole bit patterns could be made to be much faster, but is this the right approach? Or would it slow down code too much because copying a struct with a hole, for example, would no longer be scalarized?
