From patchwork Thu Oct 18 13:30:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 192319 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 CCEB32C007C for ; Fri, 19 Oct 2012 00:31:34 +1100 (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=1351171895; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:Date:Message-ID: User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=ElpXUCGOKUEsJ0sE2/ywmGnc348=; b=pdxCoMppfusOR29 gj6ssAqMhhuTLSWJtrHyUTu5kKD373wV1z8xIlBDfh2SklAX4Lj2k74Yqmu3xDM1 +z3UcMWQk7C8S2JMmwBBmV8KE6WlSYpWRb7iMRP2JffbdTDrUgqhQV68ULgyqaY4 ALXXA+r9CC3U3Efsnh5Iq0RKc/J0= 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:Received:Received:From:To:Mail-Followup-To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=PlLs98rk3331ZSEHaai562VclVW8fqh6ntwAmI96MEXWtwRx6CfLc3daj/NIlT PUgLrFJ1p6Sn8YwjsNo+tShllzifQ1QhRHXN9oitwlReQ1tpMJmtJtvvWIXNsNzk XXAzl+d5nAbIesXPEIU7Uqb7ZwYtg0y5NWVlKSwWv1BVA=; Received: (qmail 10477 invoked by alias); 18 Oct 2012 13:31:12 -0000 Received: (qmail 10461 invoked by uid 22791); 18 Oct 2012 13:31:09 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Oct 2012 13:30:51 +0000 Received: by mail-ee0-f47.google.com with SMTP id t10so4758928eei.20 for ; Thu, 18 Oct 2012 06:30:48 -0700 (PDT) Received: by 10.14.194.2 with SMTP id l2mr31703294een.12.1350567048465; Thu, 18 Oct 2012 06:30:48 -0700 (PDT) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com. [195.212.29.75]) by mx.google.com with ESMTPS id i1sm39878028eeo.8.2012.10.18.06.30.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 06:30:47 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, vmakaraov@redhat.com, rdsandiford@googlemail.com Cc: vmakaraov@redhat.com Subject: [lra] Fix rtl checking failure Date: Thu, 18 Oct 2012 14:30:41 +0100 Message-ID: <876267di0u.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 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 This is the first of two patches needed to get a clean bootstrap on x86_64-linux-gnu with RTL checking enabled. It simply stops us from pushing notes, barriers, etc. onto the stack, which then trigger a checking failure when we try to access their patterns later. Tested on x86_64-linux-gnu. OK for lra branch? There are still some extra testsuite failures compared to the default checking mode: FAIL: g++.dg/torture/pr49938.C -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: g++.dg/torture/pr49938.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: g++.dg/torture/pr49938.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: g++.dg/torture/pr49938.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) These failures are due to subregs of hard registers appearing in the insn stream. Although that in itself is easy to fix, I think there might be some problems with the way we handle multi-register hard registers during splitting, e.g. for situations like: write (reg:DI 2) ...split 2/3 here... read (reg:SI 3) ... read (reg:SI 2) That probably needs looking at first. Richard gcc/ * lra.c (push_insns): Check INSN_P. Index: gcc/lra.c =================================================================== --- gcc/lra.c 2012-10-17 16:36:34.000000000 +0100 +++ gcc/lra.c 2012-10-18 11:48:40.423088311 +0100 @@ -1810,7 +1810,8 @@ push_insns (rtx from, rtx to) if (from == NULL_RTX) return; for (insn = from; insn != to; insn = PREV_INSN (insn)) - lra_push_insn (insn); + if (INSN_P (insn)) + lra_push_insn (insn); } /* Emit insns BEFORE before INSN and insns AFTER after INSN. Put the