From patchwork Tue Feb 5 11:30:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 218240 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 7F3C72C0291 for ; Tue, 5 Feb 2013 22:31:10 +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=1360668671; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=bwtHTZN8qtv57jqu1zqEB8T2nzo=; b=hEGB5tfTPVmzXzp TZ+mySwOUmrVkhUL+H50tg5QDCmWVShF3FukMdzPiAhSSfyuZQZ9NpZzjpVFzoXf qhF9fUE7Jl2vIpCqtqOD/FNpoaBeAifG01FbFqJtk+kPtttyrCcGwO6Dg43P+RFH Hviqe6HypKhoRPFp040YuyALRqeM= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=wbYhjkub1BXoLIz8vK+NXZQx07BS6q/iVTk5bSYedZ6Bqyfxl00lWmAPpKmTjI m8YSf+CkGA6o5f4b22eajXs3z1rFdciYHBB4h96Sz0jkXj8BMecr3BMiEY5v+qTn IRSGCBFEXD78k0Kfrm2jLGahfunSSV1yrZMqKzzz7xOsE=; Received: (qmail 1224 invoked by alias); 5 Feb 2013 11:30:53 -0000 Received: (qmail 1199 invoked by uid 22791); 5 Feb 2013 11:30:52 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, TW_CF X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Feb 2013 11:30:44 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1U2gja-0007L9-84 from Tom_deVries@mentor.com ; Tue, 05 Feb 2013 03:30:42 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Feb 2013 03:30:41 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 5 Feb 2013 11:30:39 +0000 Message-ID: <5110ED59.9050500@mentor.com> Date: Tue, 5 Feb 2013 12:30:33 +0100 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jakub Jelinek CC: Eric Botcazou , , Mikael Pettersson Subject: Re: [PATCH] Fix PR56131 - gcc.dg/pr56035.c ICEs gcc on sparc-linux References: <510FF01D.5040309@mentor.com> <1551618.pBYOJKzDYv@polaris> <5110D3DF.2050904@mentor.com> <20130205094959.GH4385@tucnak.redhat.com> <5110D872.2010606@mentor.com> <20130205101235.GI4385@tucnak.redhat.com> In-Reply-To: <20130205101235.GI4385@tucnak.redhat.com> 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 On 05/02/13 11:12, Jakub Jelinek wrote: > On Tue, Feb 05, 2013 at 11:01:22AM +0100, Tom de Vries wrote: >> I'm not sure I understand your comment. >> >> The BLOCK_FOR_INSN of the note was NULL. The NOTE_BASIC_BLOCK of the note was >> correct. Are you saying that the BLOCK_FOR_INSN should not have been NULL? > > Yeah, I mean the following invariant should hold IMHO: > !NOTE_INSN_BASIC_BLOCK_P (insn) || NOTE_BASIC_BLOCK (insn) == BLOCK_FOR_INSN (insn) > NOTE_INSN_BASIC_BLOCK for some bb outside of that bb? That looks fishy. > Haven't bootstrapped/regtested with such a check anywhere, just compiled one > largish C++ testcase with it. > Jakub, I've used patch below to print rtl with a BLOCK_FOR_INSN annotation, and looked at behaviour for x86_64 and sparc. For sparc, BLOCK_FOR_INSN is always NULL starting at pass_mach dump files, due to pass_free_cfg that calls free_bb_for_insn, whose only purpose is to set the BLOCK_FOR_INSN field to NULL. So all NOTE_INSN_BASIC_BLOCKs in the .mach dump and after violate the invariant formulated above: ... [bfi NULL](note 13 8 201 [bb 2] NOTE_INSN_BASIC_BLOCK) ... For x86_64, we recompute BLOCK_FOR_INSN in pass_mach here: ... static void ix86_reorg (void) { /* We are freeing block_for_insn in the toplev to keep compatibility with old MDEP_REORGS that are not CFG based. Recompute it now. */ compute_bb_for_insn (); ... so we have BLOCK_FOR_INSN all the way till pass_final. The PR56131 ICE occurred for sparc in pass_delay_slots, after pass_mach, so it's expected that BLOCK_FOR_INSN is NULL. Thanks, - Tom Index: gcc/print-rtl.c =================================================================== --- gcc/print-rtl.c (revision 195747) +++ gcc/print-rtl.c (working copy) @@ -800,6 +800,20 @@ print_rtl_single_with_indent (FILE *outf sawclose = 0; fputs (s_indent, outfile); fputs (print_rtx_head, outfile); +#ifndef GENERATOR_FILE + { + basic_block bb; + if (GET_RTX_LENGTH (GET_CODE (x)) >= 4 + && GET_RTX_FORMAT (GET_CODE (x))[3] == 'B') + { + bb = BLOCK_FOR_INSN (x); + if (bb != 0) + fprintf (outfile, " [bfi %d]", bb->index); + else + fprintf (outfile, " [bfi NULL]"); + } + } +#endif