This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix a tcb crash and a potential bug on mainline
On Wed, 2004-10-20 at 09:27, Steven Bosscher wrote:
> >
> > 1 - Why does cleanup_control_flow() ever look at a stmts inside an
> > unreachable block? Its seems rather, umm, unnecessary, for starters. Why
> > not just call delete_unreachable_blocks() as the *first* thing in
> > cfg_cleanup(). It doesn't look like its an expensive call...
>
> Well, it wouldn't help because the block is made unreachable by
> cleanup_control_flow().
>
> What happens is that cleanup_control_flow() uses FOR_EACH_BB which
> walks BBs from index 0 to last_basic_block, so it sees BB 2 before
> BB 4. In the test case, cleaning up control flow out of BB 2 makes
> BB 4 unreachable. So calling delete_unreachable_blocks() before
> cleanup_control_flow() would not help in this case.
> Hence my patch to make cleanup_control_flow() ignore unreachable BBs.
>
Why doesnt cleanup_control_flow actually follow the flow from entry to
exit instead of FOR_EACH_BB? Does it have to do something in blocks
that are unreachable? Or is it just an attempt to avoid using a visited
bitmap?
>
> > 2 - The issue may also exist outside cleanup_control_flow, so why does
> > remove_phi_arg_num have to remove the PHI node when is removes the last
> > argument.
>
> That is what I believe to be the problem. Jeff thinks this is "the
> right thing" to do.
I think he believes the right thing to do is to put the PHI_RESULT on
the free list when the PHI node is deleted. Thats different than the
issue of having remove_phi_arg_num remove the PHI node. But that just
my interpretation, I don't presume to actually say what he believes.
I just know I don't think remove_phi_arg_num() ought to delete the PHI
node when the last argument is removed...
Andrew