From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18889 invoked by alias); 14 Jul 2009 00:13:47 -0000 Received: (qmail 18880 invoked by uid 22791); 14 Jul 2009 00:13:47 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mo10.iij4u.or.jp (HELO mo10.iij4u.or.jp) (210.138.174.78) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Jul 2009 00:13:40 +0000 Received: by mo.iij4u.or.jp (mo10) id n6E0A30J004897; Tue, 14 Jul 2009 09:10:03 +0900 Received: from localhost (238.152.138.210.bn.2iij.net [210.138.152.238]) by mbox.iij4u.or.jp (mbox11) id n6E0A2Yf014512; Tue, 14 Jul 2009 09:10:02 +0900 Date: Tue, 14 Jul 2009 00:13:00 -0000 Message-Id: <20090714.091001.52900237.kkojima@rr.iij4u.or.jp> To: stevenb.gcc@gmail.com Cc: gcc@gcc.gnu.org, zadeck@naturalbridge.com, ebotcazou@adacore.com Subject: Re: A question about df_get_live_in From: Kaz Kojima In-Reply-To: <571f6b510907131637j1949c9f5q27d2fa58931de792@mail.gmail.com> References: <571f6b510907131507y6824fe4n6932b3ea26e85527@mail.gmail.com> <20090714.081700.128123313.kkojima@rr.iij4u.or.jp> <571f6b510907131637j1949c9f5q27d2fa58931de792@mail.gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00232.txt.bz2 Steven Bosscher wrote: > OK, so isn't the bug obvious then? You said: "mark_target_live_regs > uses df_get_live_in to get live regs for the basic block including the > opposite_thread insn which is insn 32.". And you had insn 32 in basic > block 3. So find_basic_block returns the wrong basic block. > > reorg.c:find_basic_block uses BLOCK_FOR_INSN, which is not valid after > freeing the CFG. The bug you see occurs now because your backport of > the other DF/reorg fixes (your patch for PR40105) also introduces a > call to free_bb_for_insn which clears BLOCK_FOR_INSN. And since > find_basic_block skips over NOTE_INSN_BASIC_BLOCK notes (it uses > {prev,next}_nonnote_insn) and basic block 3 doesn't start with a > label, find_basic_block never sees the start of basic block 3. Ugh. > I am not even sure why it finds basic block 2. Is there a label in > basic block 2 that you were not showing in the original post? There are no labels in basic block2. gdb says it hits the start of the function and returns with 150 else if (insn == 0) 151 return ENTRY_BLOCK_PTR->next_bb->index; > Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes? The same question arises to me. Regards, kaz