From patchwork Tue Jan 3 19:14:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 134059 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 C09B9B6FA8 for ; Wed, 4 Jan 2012 06:15:20 +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=1326222921; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=F0Sta1k+KEcIyMw7el8C 4zZBoQY=; b=uF6WYjScrtHOaKUEzzgIcpY0xYeoDKcJbIe0z5PUacSCPU53BISn 8j4UrofcYZAIgjfxZJaGTRxtC6ELcRDt/V+ymShmQ0++oHfp+QcG+OEnd8lvOjWm m3MpGRrSvSGjkTG7aFNZ8HnupkvWylvJiPpCqiy0b6qRoZR9DKdlAKM= 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:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=UV/Y4rnCWdryahmPnfCtvm7KJG3fKsR7hdSx6rUd7km5bZPgAAlko+dIwoNnXO uHq30Jp9gjBWw2BpnNb4Uyt9dPLguPbYoZpwb2CYrKDt3ZYsxnnTXCUMbRlUg0G8 +NKCex9NrLmm6SwijGd6ymKSoRwUADw6Rthjfd1vdz/lw=; Received: (qmail 7115 invoked by alias); 3 Jan 2012 19:15:15 -0000 Received: (qmail 7092 invoked by uid 22791); 3 Jan 2012 19:15:13 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Jan 2012 19:15:00 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q03JExbj020802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 14:15:00 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q03JExRL023819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 14:14:59 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id q03JEwFc020973; Tue, 3 Jan 2012 20:14:58 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id q03JEwg6020971; Tue, 3 Jan 2012 20:14:58 +0100 Date: Tue, 3 Jan 2012 20:14:57 +0100 From: Jakub Jelinek To: Richard Henderson , Richard Guenther , Alexandre Oliva Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Another canonical cselib_val bootstrap fix (PR bootstrap/51725) Message-ID: <20120103191457.GZ18937@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi! My previous patch apparently wasn't enough. If at add_mem_* time mem_elt is still its own canonical cselib_val, but only afterwards new_elt_loc_list adds a new canonical cselib_val to it (and moves over its locs), then we can still crash in cselib_invalidate_mem. This patch ensures that new_elt_loc_list when moving over the locs also adds the canonical cselib_val to first_containing_mem list if it wasn't already there and the old val was (it would be better to remove it, but the chain is only single linked list and it would be expensive to remove it there - the next cselib_invalidate_mem will handle it automatically, as non-canonical values don't have any mem locs and thus are removed from the chain). In cselib_invalidate_mem it needs to call canonical_cselib_val on the addr_list chain elts (those aren't canonicalized by anything). There is no need to call canonical_cselib_val on v, the new_elt_loc_list change ensures that the canonical value is in the list always too and non-canonical values don't have MEM locs. Bootstrapped/regtested on x86_64-linux and i686-linux, tested with cross jc1 to ia64-linux on gnu-CORBA.list compilation. Ok for trunk? 2012-01-03 Jakub Jelinek PR bootstrap/51725 * cselib.c (new_elt_loc_list): When moving locs from one cselib_val to its new canonical_cselib_val and the cselib_val was in first_containing_mem chain, but the canonical_cselib_val was not, add the latter into the chain. (cselib_invalidate_mem): Compare canonical_cselib_val of addr_list chain elt with v. Jakub --- gcc/cselib.c.jj 2012-01-03 16:22:48.000000000 +0100 +++ gcc/cselib.c 2012-01-03 17:29:10.096229315 +0100 @@ -277,6 +277,12 @@ new_elt_loc_list (cselib_val *val, rtx l } el->next = val->locs; next = val->locs = CSELIB_VAL_PTR (loc)->locs; + if (CSELIB_VAL_PTR (loc)->next_containing_mem != NULL + && val->next_containing_mem == NULL) + { + val->next_containing_mem = first_containing_mem; + first_containing_mem = val; + } } /* Chain LOC back to VAL. */ @@ -2211,7 +2217,7 @@ cselib_invalidate_mem (rtx mem_rtx) mem_chain = &addr->addr_list; for (;;) { - if ((*mem_chain)->elt == v) + if (canonical_cselib_val ((*mem_chain)->elt) == v) { unchain_one_elt_list (mem_chain); break;