[Bug target/82386] [8 Regression] internal compiler error: Segmentation fault on 32-bit powerpc BE targets

[jakub at gcc dot gnu.org]

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].