From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36226 invoked by alias); 6 Nov 2015 18:45:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 36150 invoked by uid 89); 6 Nov 2015 18:45:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Nov 2015 18:44:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A61AE8EFD9; Fri, 6 Nov 2015 18:44:58 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-107.phx2.redhat.com [10.3.113.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA6IiwYV022712; Fri, 6 Nov 2015 13:44:58 -0500 Subject: Re: regrename: don't overflow insn_rr_info To: Bernd Schmidt , GCC Patches References: <563C8A38.10209@t-online.de> From: Jeff Law Message-ID: <563CF52A.3020403@redhat.com> Date: Fri, 06 Nov 2015 18:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563C8A38.10209@t-online.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00702.txt.bz2 On 11/06/2015 04:08 AM, Bernd Schmidt wrote: > This one is a fix for something that could currently only affect c6x, > but I have code that exposes it on i386. > > When optionally gathering operand info in regrename, we can overflow the > array in certain situations. This can occur when we have a situation > where a value is constructed in multiple small registers and then > accessed as a larger one (CDImode in the testcase I have). In that case > we enter the "superset" path, which fails the involved chains, but the > smaller pieces still all get seen by record_operand_use, and there may > be more of them than MAX_REGS_PER_ADDRESS. > > The following fixes it. Bootstrapped and tested with -frename-registers > enabled at -O1 on x86_64-linux. Ok? > > > Bernd > > rr-fail-op.diff > > > * regrename.c (record_operand_use): Keep track of failed operands > and stop appending if we see any. > * regrename.h (struct operand_rr_info): Add a failed field and shrink > n_chains to short. OK. jeff