Re: [tree-ssa] Insert on edge fix

[law at redhat dot com]

In message <Pine.LNX.4.44.0306192155110.7104-100000@ops2.one-point.com>, Jeff S
turm writes:
 >On 19 Jun 2003, Diego Novillo wrote:
 >> That looks odd.  Could you set a breakpoint in create_bb() for
 >> n_basic_blocks == 92?  Is it being created by tree_split_edge?
 >
 >Yes.
 >
 >#0  create_bb () at ../../gcc/tree-cfg.c:795
 >#1  0x0839b57f in tree_split_edge (edge_in=0x85eb4c4) at
 >../../gcc/tree-cfg.c:4567
 >#2  0x08399e38 in bsi_insert_on_edge_immediate (e=0x85eb4c4,
 >stmt=0x402b4160, old_bsi=0x0, created_block=0x0) at
 >../../gcc/tree-cfg.c:4034
 >#3  0x0839a42c in bsi_commit_edge_inserts (update_annotations=0,
 >new_blocks=0x0) at ../../gcc/tree-cfg.c:4143
 >
 >> That block ought to have something in head_tree_p and end_tree_p.
 >
 >We wind up here in find_insert_location, where the first argument to
 >hande_switch_split is the new, empty block.
 >
 >    default:
 >      if (is_ctrl_altering_stmt (stmt))
 >        {
 >          /* The block ends in a CALL or something else which likely has
 >             abnormal edges.  In that case, we simple create a new block
 >             right after this one, and then fall through to the
 >             destination  block.  */
 >          ret = handle_switch_split (new_block, dest);
 >          *location = EDGE_INSERT_LOCATION_AFTER;
 >          break;
 >        }
 >
 >It eventually recurses back into find_insert_location and
 >handle_switch_split, never further initializing the problem block.
I haven't looked into your problem, but it might be worth picking up
my fix to tree-cfg.c from earlier tonight and see if it fixes your
problem.  It was clearly doing the wrong thing in its handling of switch
statements.  

jeff