ICE in fixup_reorder_chain, at bb-reorder.c:633

[John David Anglin]

> Certainly it should, if one is needed.  That was the whole point of
> my comment.  That said, I wish you'd provided a compilable test case,
> since we should have kept the two blocks together, but didn't.
> 
> Put a breakpoint at 
> 
>   /* In the absence of a prediction, disturb things as little as possible
>      by selecting the old "next" block from the list of successors.  If
>      there had been a fallthru edge, that will be the one.  */
>   if (! next)
>     {
>       for (e = bb->succ; e ; e = e->succ_next)
> 
> conditional on bb->index == 206, and see why the fallthru edge is
> not chosen.

The problem seems to be that old "next" block is not chosen because
it has already been visited.  In the test case, the casesi is in block
1.  Block 2 is selected by the above loop but next is set to NULL here:

  /* Make sure we didn't select a silly next block.  */
  if (! next || next == EXIT_BLOCK_PTR || RBI (next)->visited)
    next = NULL;

Here is the debug values just before:

(gdb) p ((reorder_block_def) (next)->aux)->visited
$24 = 1
(gdb) p next->index
$25 = 2

Here is the rtl dump from the reorder pass:

;; Function main

Reordering block 2 (1) after 0 (0)
Reordering block 1 (2) after 2 (1)
Reordering block 8 (3) after 1 (2)
Reordering block 3 (4) after 8 (3)
Reordering block 9 (6) after 4 (5)
Reordering block 5 (8) after 10 (7)
Reordering block 7 (9) after 5 (8)
Reordering block 6 (10) after 7 (9)
Emitting label for block 1 (2)

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)