https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I think the problem is that check_no_overlap only looks at later m_store_info stores that would overlap and cause problems. But in this case, the problem is that we'd need to check earlier m_store_info store too. We have in the stmt order bitpos bitsize kind order 64 96 INTEGER_CST 0 0 16 INTEGER_CST 1 16 64 MEM_REF 2 128 8 INTEGER_CST 3 160 32 INTEGER_CST 4 After sort_by_bitpos this is: 0 16 INTEGER_CST 1 16 64 MEM_REF 2 64 96 INTEGER_CST 0 128 8 INTEGER_CST 3 160 32 INTEGER_CST 4 The first store in this order doesn't overlap anything and is followed by adjacent store of incompatible kind, so is kept as is. Then the MEM_REF store is kept as is too, because again it overlaps with the next one, but is of a different kind. The bug is when deciding if the 3rd store could be mergeable with the 4th store. They are overlapping and of the same kind that can be handled for overlapping stores, but they shouldn't be merged, because there was a non-mergeable overlapping store in between them in the sort_by_order order (the MEM_REF one).
