From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14976 invoked by alias); 21 Feb 2014 21:50:44 -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 14966 invoked by uid 89); 21 Feb 2014 21:50:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.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 ESMTP; Fri, 21 Feb 2014 21:50:42 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1LLofip022178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Feb 2014 16:50:41 -0500 Received: from [10.10.116.20] ([10.10.116.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1LLoeMP000616 for ; Fri, 21 Feb 2014 16:50:40 -0500 Message-ID: <5307CA30.8030902@redhat.com> Date: Fri, 21 Feb 2014 21:50:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: gcc-patches List Subject: Re: C++ PATCH for c++/60252 (ICE with VLA in lambda parameter) References: <53075E44.2040501@redhat.com> In-Reply-To: <53075E44.2040501@redhat.com> Content-Type: multipart/mixed; boundary="------------090304000102050209000805" X-SW-Source: 2014-02/txt/msg01354.txt.bz2 This is a multi-part message in MIME format. --------------090304000102050209000805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 601 On 02/21/2014 09:10 AM, Jason Merrill wrote: > While parsing the template parameter list for a lambda, we've already > pushed into the closure class but haven't created the op() > FUNCTION_DECL, so trying to capture 'this' by way of the 'this' pointer > of op() breaks. Avoid the ICE by not trying to capture 'this' when > parsing a parameter list. On second thought, I'd rather not depend on the parsing state here, since we don't always update current_binding_level during template instantiation. So let's check for the actual problem instead. Tested x86_64-pc-linux-gnu, applying to trunk. --------------090304000102050209000805 Content-Type: text/x-patch; name="60252-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="60252-2.patch" Content-length: 1025 commit 5ca06118071f28b060b751415d18f8af4968a0a4 Author: Jason Merrill Date: Fri Feb 21 15:06:47 2014 -0500 PR c++/60252 * lambda.c (maybe_resolve_dummy): Check lambda_function rather than current_binding_level. diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c index 7fe235b..277dec6 100644 --- a/gcc/cp/lambda.c +++ b/gcc/cp/lambda.c @@ -749,10 +749,8 @@ maybe_resolve_dummy (tree object) if (type != current_class_type && current_class_type && LAMBDA_TYPE_P (current_class_type) - && DERIVED_FROM_P (type, current_nonlambda_class_type ()) - /* If we get here while parsing the parameter list of a lambda, it - will fail, so don't even try (c++/60252). */ - && current_binding_level->kind != sk_function_parms) + && lambda_function (current_class_type) + && DERIVED_FROM_P (type, current_nonlambda_class_type ())) { /* In a lambda, need to go through 'this' capture. */ tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type); --------------090304000102050209000805--