From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10798 invoked by alias); 20 Aug 2014 00:05:21 -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 10788 invoked by uid 89); 20 Aug 2014 00:05:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Wed, 20 Aug 2014 00:05:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7K05I0F032556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Aug 2014 20:05:19 -0400 Received: from pike.twiddle.home (vpn-56-106.rdu2.redhat.com [10.10.56.106]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7K05H8t028943; Tue, 19 Aug 2014 20:05:17 -0400 Message-ID: <53F3E63C.9060904@redhat.com> Date: Wed, 20 Aug 2014 00:05:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: David Malcolm CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 225/236] Work towards NEXT_INSN/PREV_INSN requiring insns as their params References: <1407345815-14551-1-git-send-email-dmalcolm@redhat.com> <1407345815-14551-226-git-send-email-dmalcolm@redhat.com> <53F3BA30.4050301@redhat.com> <1408484146.2473.128.camel@surprise> In-Reply-To: <1408484146.2473.128.camel@surprise> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg01968.txt.bz2 On 08/19/2014 02:35 PM, David Malcolm wrote: > This one is quite ugly: the pre-existing code has two locals named > "note", both of type rtx, with one shadowing the other. This patch > introduces a third, within the scope where the name "note" is used for > insns. In the other scopes the two other "note" variables are used for > find_reg_note. In each case, the name "note" is written to before use. > > So in my defense, the existing code already had shadowing of locals... > but I guess that's not much of a defense, and it would be better to > introduce a different name, and rename the uses in the appropriate > scope. Or, if possible, narrow the scope of the other names such that there is no shadowing. r~