https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82386
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-10-02
CC| |jakub at gcc dot gnu.org,
| |segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that try_combine has two spots where it calls split_block:
remove_edge (split_block (bb, i3));
and
remove_edge (split_block (bb, undobuf.other_insn));
When LOG_LINKS are created, they point only within the same basic block, so
without those two calls, combine_instruction calls to try_combine should have
all insns belonging to the same basic block - this_basic_block.
But when the bb is split, we reach end of that bb earlier, then start
processing perhaps the new basic block created from there and through LOG_LINKS
reach back the old basic block, so this_basic_block doesn't necessarily mean
the bb of all the instructions that are being combined anymore.
this_basic_block is used in multiple spots, in some (e.g. calls to
propagate_for_debug) we use its BB_END, in other cases (e.g. in
distribute_notes) we use its BB_HEAD.
Makes me wonder if it wouldn't be better to defer the splitting until later,
then we'd restore the invariant that this_basic_block is the bb of i[3210].
