On Saturday, July 26, 2003, at 5:08 PM, Daniel Berlin wrote:
Note that 345 was an empty block (but still had the same
head_tree_p)
at the time 444 was created by bsi_insert_on_edge_immediate.
The edge we insert on is also from 54->346 (346 is the successor
block
of 345), so it looks like collateral damage that we chose the same
head_tree_p as block 345.
Soooo. What block is the switch stmt in?
Whats block 345? I clearly need
more context :-)
Yeah, i'm working on minimizing a testcase for you.
it occurs in combine.c from 176.gcc, in simplify_shift_const.
It's not a nice looking function, so i set my automatic test case
minimizer on it an hour ago to see if we could come up with something
smaller that still fails. It's slow, but it's working on it, and
getting somewhere.
I've already halved the number of bb's in the failing functions.
:)
Okay, i've gotten it down to 60 lines of code, 31 bb's (it was 4000
lines before, 543 bb's).
I've attached the code.
Breakpoint on bsi_insert_on_edge_immediate, hit run, and it's the
second bsi_insert_on_edge_immediate call (which is the first one that
creates a new bb).
Look at the head_tree_p of basic_block 20, then, look at the
head_tree_p of the bb 30 it creates when the insertion is done.
For simplicity, here's the relevant blocks, and where we are inserting.
What happens is this:
1. We have a switch statement, like so:
# BLOCK 9 (bug.c:37). PRED: 8 7 6. SUCC: 10 21.
# code_2 = PHI <code_29(6), code_1(7), code_1(8)>;
# .GLOBAL_VAR_5 = PHI <.GLOBAL_VAR_19(6), .GLOBAL_VAR_19(7),
.GLOBAL_VAR_4(8)>;
# VUSE <.GLOBAL_VAR_5>;
T.12_30 = varop_17->code;
T.13_31 = (int)T.12_30;
switch (T.13_31)
{
{
....
# BLOCK 20 (bug.c:51). PRED: 19 18. SUCC: 21.
<THIS BLOCK IS INSIDE THE BIND_EXPR_BODY OF THE SWITCH STATEMENT>
goto <UL1070>;
}
};
# BLOCK 21. PRED: 20 14 9. SUCC: 23.
<THIS BLOCK IS OUTSIDE OF IT, AFAICT>
<UL1070>:;;
goto <ULcf50>;
};
We go to insert on the edge between block 9 and block 21
It creates a new basic block to do this, bb 30.
So it then goes to find the insert location for the statement.
It then notices it's inserting into a switch statement, sees it's
inserting into the fallthru, and calls handle_switch_fallthru.
Handle switch fallthru starts to do it's thing, eventually calls:
3820 tsi = tsi_last (&BIND_EXPR_BODY (SWITCH_BODY (sw_stmt)));
The tsi it returns is a pointer to the head of basic block 20 (which
is the correct last thing in the bind_expr_body, AFAICT).
At this point, we link the new case label after that statement (which
is a statement really in bb 20, still :P), so that bb 20 now looks
like:
51 goto <UL1070>;
-1 default :
We then try to append the container (which is the pointer to the head
of bb 20) to the new bb, which causes the two bb's to now share a
head.