From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6621 invoked by alias); 25 Nov 2008 20:05:55 -0000 Received: (qmail 25666 invoked by alias); 25 Nov 2008 20:04:29 -0000 Date: Tue, 25 Nov 2008 20:05:00 -0000 Message-ID: <20081125200429.25665.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/38264] tree_forwarder_block_p says no to first basic block In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "law at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg02203.txt.bz2 ------- Comment #2 from law at redhat dot com 2008-11-25 20:04 ------- Subject: Re: New: tree_forwarder_block_p says no to first basic block rguenth at gcc dot gnu dot org wrote: > tree_forwarder_block_p has > > if (find_edge (ENTRY_BLOCK_PTR, bb)) > return false; > > without explanation. This test was added by you, Jeff - do you remember why? > > Removing this check triggers some ICEs in the testsuite because remove_bb > (called from remove_forwarder_block) unconditionally moves labels from the > removed block to prev_bb (yuck!) - which is of course invalid if that happens > to be the entry bb. Luckily remove_forwarder_block already contains code > to do the label-move job itself - it is just conditional on seen abnormal > incoming edges. Enabling this code to run by default causes a bootstrap > comparison failure though. > > > I'm not sure -- that code was introduced in 2003 and looks like it was a mix of some of Zdenek's work as well as mine. It could well have been the label issue, or some horrid problem dealing with our control structures (which were still in the IL at that time), or simply my mis-translation of some of Zdenek's code. Clearly remove_bb has to do something with the labels. I think it was decided that the labels could go anywhere and the previous block reasonably convenient -- the theory was the block was unreachable, so the location of a named label in the block was unimportant. In the case of a forwarder block the label was reachable and needs to be moved into a sane location -- removal of forwarder blocks probably wasn't something we considered when discussing the named label issues. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264