From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28271 invoked by alias); 20 Oct 2004 13:41:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28223 invoked from network); 20 Oct 2004 13:41:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Oct 2004 13:41:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9KDfJIX024952; Wed, 20 Oct 2004 09:41:19 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9KDfIr28830; Wed, 20 Oct 2004 09:41:18 -0400 Received: from pain (vpn50-35.rdu.redhat.com [172.16.50.35]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id i9KDfEvn030240; Wed, 20 Oct 2004 09:41:16 -0400 Subject: Re: Fix a tcb crash and a potential bug on mainline From: Andrew MacLeod To: Steven Bosscher Cc: Jeff Law , gcc-patches , Diego Novillo In-Reply-To: <200410201527.38061.stevenb@suse.de> References: <200410182303.52997.stevenb@suse.de> <1098227633.2915.166.camel@localhost.localdomain> <1098278085.5695.3886.camel@pain> <200410201527.38061.stevenb@suse.de> Content-Type: text/plain Message-Id: <1098279673.5695.3937.camel@pain> Mime-Version: 1.0 Date: Wed, 20 Oct 2004 13:47:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg01724.txt.bz2 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