This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
cfg_layout_split_edge doesn't handle the general case correctly
- From: Mostafa Hagog <MUSTAFA at il dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 17 Aug 2004 22:37:22 +0300
- Subject: cfg_layout_split_edge doesn't handle the general case correctly
- Reply-to:
- Sensitivity:
Hello there,
While trying to use loop information in later stages of
the RTL level I have encountered a problem with cfg_layout_split_edge.
It turns out that this function is not correct in some cases.
according to the below lines, cfg_layout_split_edge adds the newly
created basic block after e->src, this is not correct when there
is at least one additional edge that is fallthru that is going out
of e->src.
cfg_layout_split_edge (edge e)
{
edge new_e;
basic_block new_bb =
create_basic_block (e->src != ENTRY_BLOCK_PTR
? NEXT_INSN (BB_END (e->src)) : get_insns (),
NULL_RTX, e->src);
Int he tree level (tree_split_edge) we try to put the new block before
e->src
first and check a similar put if our check fails we put the block after
e->src
without additional checking; see the following lines taken from
tree_split_edge:
/* Place the new block in the block list. Try to keep the new block
near its "logical" location. This is of most help to humans looking
at debugging dumps. */
for (e = dest->pred; e; e = e->pred_next)
if (e->src->next_bb == dest)
break;
if (!e)
after_bb = dest->prev_bb;
else
after_bb = src;
The above makes the CFG inconsistent, and calling commit_edge_insertions in
that
situation causes an ICE (this was the case when I tried to use
loop_optimizer_init
inside SMS, in which I use commit_edge_insertions).
Is there something wrong in my understanding of the above?
Do we need a fix for this?
Thanks,
Mostafa.