From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22264 invoked by alias); 8 Apr 2011 17:50:40 -0000 Received: (qmail 22254 invoked by uid 22791); 8 Apr 2011 17:50:38 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_JS,T_RP_MATCHES_RCVD 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; Fri, 08 Apr 2011 17:50:32 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p38HoPdB022687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 13:50:25 -0400 Received: from [127.0.0.1] ([10.3.113.14]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p38HoOlU001270; Fri, 8 Apr 2011 13:50:25 -0400 Message-ID: <4D9F4AE0.6050200@redhat.com> Date: Fri, 08 Apr 2011 17:50:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nathan Froyd CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH PING] c++-specific bits of tree-slimming patches References: <20110324131518.GO23480@codesourcery.com> In-Reply-To: <20110324131518.GO23480@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2011-04/txt/msg00651.txt.bz2 On 03/24/2011 09:15 AM, Nathan Froyd wrote: > The C++-specific bits of these patches: > > [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html OK. > [PATCH 07/18] generalize build_case_label to the rest of the compiler > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html > + tree t = make_node (CASE_LABEL_EXPR); > + > + TREE_TYPE (t) = void_type_node; > + SET_EXPR_LOCATION (t, input_location); As jsm and richi said, using input_location like this is a regression. Can we use DECL_SOURCE_LOCATION (label_decl) instead? > [PATCH 08/18] convert cp *FOR_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00553.html > [PATCH 09/18] convert cp IF_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00562.html > [PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00552.html OK. > [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html It looks like you need to add EXPR_PACK_EXPANSION cases to value_dependent_expression_p and cp_tree_equal. Maybe split out the code from write_expression that overrides TREE_OPERAND_LENGTH in some cases and use that new function instead of TREE_OPERAND_LENGTH in these places. > [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00566.html OK. > Alternatively, could we have a GWP or similar rule on Tom's suggestion: > > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00620.html > > that patches propagating middle-end changes to front-ends are > obvious/preapproved, perhaps after a 24-48 hour waiting period for > comments? That would cover 02 and 07 above (possibly 17 as well); 02 is > blocking some of the already-approved middle-end changes later in the > series. That makes sense to me, but I'd give it a week. Jason