From patchwork Wed May 16 01:15:00 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 159484 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id AEADEB6FDA for ; Wed, 16 May 2012 11:15:20 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1337735721; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: Message-Id:To:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=i/R66t95nWooYUq11YGu/ZdCyCs=; b=j7gByGLVeOdmg9K kIywuxW7NKipEx3xuMXsVOv+6n3UBeLSG7zMwm8I0cEvJEFh5TtRSfAbQQ6CLD9X asgNHpDSMcVRVNW7Y3u0c0t8idpaHqb599yDqFPMDxLGL95MRHu+gyEaXwBsWW3c FycTEwF3kNQfair24x9bMLI1dF7Q= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:Message-Id:To:Subject:From:Mime-Version:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=JFY02k/47bTE4MvvXMVrTIjDqWzABjW/vh263UvykwcZlNNtoxFuxRd+/PI9KN lFLpr5jkeshBmc3BVql3rsleFEqcBGxWg3Y4QuZCNynXsgvorsG0O/3o3yEdVa8N PPP+LV8AAHnkqlQxfa46+lZdNNATHz0I61yaj/q/ZA6F0=; Received: (qmail 16784 invoked by alias); 16 May 2012 01:15:17 -0000 Received: (qmail 16772 invoked by uid 22791); 16 May 2012 01:15:16 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,TW_CF X-Spam-Check-By: sourceware.org Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net) (198.137.202.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 01:15:03 +0000 Received: from localhost (cpe-66-108-118-54.nyc.res.rr.com [66.108.118.54]) (authenticated bits=0) by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id q4G1F0Fe027308 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 15 May 2012 18:15:01 -0700 Date: Tue, 15 May 2012 21:15:00 -0400 (EDT) Message-Id: <20120515.211500.40143465924601627.davem@davemloft.net> To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix var tracking ICE due to reorg. From: David Miller Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org How bugs like this were not hit earlier, I'll never understand :-) If during reorg we delete a code label, and as a result we decide to delete all the code following that label, we hit this condition in jump.c:delete_related_insns(): if (was_code_label && prev && BARRIER_P (prev)) which passes and then we proceed to delete insns until we hit a non-deleted code label. During this traversal, we can end up deleting a CALL, but in doing so we will leave the var tracking note for the call arguments around. Later in dwarf2_var_location() we will ICE, because we can't find the CALL when we search backwards for it. The note searching scheme in the fix below is cribbed from code in try_split() which has to handle a similar problem. I fully understand that delete_related_insns() is a deprecated interface, and the "right" way to do this is to use delete_insn() and perform cfg cleanups afterwards. But fixing reorg to no longer use delete_related_insns() is a rather large task, and certainly outside the scope of fixing this bug in 4.7. Ok for mainline and 4.7 branch? * jump.c (delete_related_insns): If we remove a CALL, make sure we delete it's NOTE_INSN_CALL_ARG_LOCATION note too. diff --git a/gcc/jump.c b/gcc/jump.c index 52cbbca..d49b58e 100644 --- a/gcc/jump.c +++ b/gcc/jump.c @@ -1252,6 +1252,26 @@ delete_related_insns (rtx insn) if (next != 0 && BARRIER_P (next)) delete_insn (next); + /* If this is a call, then we have to remove the var tracking note + for the call arguments. */ + + if (CALL_P (insn) + || (NONJUMP_INSN_P (insn) + && GET_CODE (PATTERN (insn)) == SEQUENCE + && CALL_P (XVECEXP (PATTERN (insn), 0, 0)))) + { + rtx p = insn; + + for (p = NEXT_INSN (p); + p && NOTE_P (p); + p = NEXT_INSN (p)) + if (NOTE_KIND (p) == NOTE_INSN_CALL_ARG_LOCATION) + { + remove_insn (p); + break; + } + } + /* If deleting a jump, decrement the count of the label, and delete the label if it is now unused. */