https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2018-11-02
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, the bug is that in the code introduced in the PR86844 fix, if we skip any
stores because their order was > last_order, we should have marked the
merged_store with some flag that prevents merging that with any further stores.
Plus, there is obviously a missed optimization (and regression on that),
because in this testcase there is no reason why any of the INTEGER_CST stores
should be skipped.
We have stores (bitposition, bitsize):
0 32
0 1
1 1
...
21 1
32 32
64 32
66 1
where 0 32 has order 0, 0 1 has order 9, 1 1 has order 15, 32 32 has order 1,
64 32 has order 2 and 66 1 has the highest order.
All the stores at offsets 0 to 21 are overlapping. We go and merge as
overlapping store 0 32, 0 1 and all stores with order in between those (but
that means skipping 1 1 and various others). If we have to do that, e.g.
because the
1 1 store would be not INTEGER_CST store, then we need to arrange not to merge
with it anymore stores with order above that problematic store.
If all the to be skipped stores are INTEGER_CSTs, then we should obviously try
to merge them in all (as was the case before the PR86844 fix on this testcase).
