From patchwork Sun Mar 6 14:30:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 592546 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 94B9E140273 for ; Mon, 7 Mar 2016 01:30:38 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=GKVbHXvK; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=M7qhlpsAGdisBn+ Yrqth1QemehO4o8XlvGNEvR6E3G5qYXf0nHpZtn0Fe6HDc83Mn/5rnjHgYafTfOV pnT0upWX/CA4ANK6+hmB0rvpA8IDvPNdxS9M6/uaJIJzvqI21DqRdjlz27pd9CRs pLgFn08ZDo9oCFWTeg9ARNRV+VEE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=taya4BXaX9afIqHYIGdwS gLRLFI=; b=GKVbHXvKfh/0vHJOtleLNcexOlwaf0sIJWPVp2XSw2AImtUJftZeb SBiOpBDFWBk5niK/Gv/33DirLsc87olf5p8zqae6YH18I7zLlIAm+v7c07l/LS/4 3kpXbAIpZxWZxRmGG7JeHRjPB6aRwgLVZYpK222094Nw3LdKbXh7NQ= Received: (qmail 94760 invoked by alias); 6 Mar 2016 14:30:31 -0000 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 Received: (qmail 94742 invoked by uid 89); 6 Mar 2016 14:30:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:2386, nonnull, non-null, const_tree X-HELO: mail-oi0-f53.google.com Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com) (209.85.218.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 06 Mar 2016 14:30:29 +0000 Received: by mail-oi0-f53.google.com with SMTP id r187so65132057oih.3 for ; Sun, 06 Mar 2016 06:30:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5FVCHJPA5a8hIdYlnVfvJcOwRf8UvnFhjy8PPgr3fGs=; b=IuY9zYTS+Tag8JWbL4AnrPjzXcrtUpi1sUy2sC9Kh9JFz7AAfdUW9bfYXHIUUQJEUo 4qJeTeVa/+EG3/q3kn8yppG76uw1Zdxtk98DsnMGoSV/EmqOiWsexKswCuzJLwPKSEtX BXmRaVoMzZe9uF/p5+7+t6XNbXP+BIi5WKcubhLRDMfyONruH1E52LaXXRPPS8z8mxDy RxhpYt4sJ2s5COnIBJVCj8AjQYelWNn+Sdk0x2+5Cu+eaQgL9Adjd81iUiE5UFMgitA5 3RkYJwxEOp+YXmPftdRE8ejBMduWZ8EBwQo5r04Xv0nISmk97QnSi3dUIURoT93nkarY 8wGA== X-Gm-Message-State: AD7BkJLJx8LJ7Z98HbnSCSnB1gcGLnhztQSDPuwFV7sm0D6StEDIJ4eeJuYfi0GaxjtH0Eqfn3hAthsuYzWqZA== X-Received: by 10.202.217.136 with SMTP id q130mr11128378oig.127.1457274627629; Sun, 06 Mar 2016 06:30:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.29.226 with HTTP; Sun, 6 Mar 2016 06:30:08 -0800 (PST) In-Reply-To: <56DBD161.3010507@redhat.com> References: <1454908753-15468-1-git-send-email-patrick@parcs.ath.cx> <56DBD161.3010507@redhat.com> From: Patrick Palka Date: Sun, 6 Mar 2016 09:30:08 -0500 Message-ID: Subject: Re: [PATCH] Fix PR c++/66786 (ICE with nested lambdas in variable template) To: Jason Merrill Cc: GCC Patches On Sun, Mar 6, 2016 at 1:42 AM, Jason Merrill wrote: > On 02/08/2016 12:19 AM, Patrick Palka wrote: >> >> Here, we are calling template_class_depth on a FIELD_DECL corresponding >> to a lambda that is used inside variable template. template_class_depth >> however does not see that this FIELD_DECL is used inside a variable >> template binding because its chain of DECL_CONTEXTs does not include the >> corresponding VAR_DECL. So template_class_depth returns the wrong >> template nesting level which causes its callers to malfunction. In >> particular we strip a template argument level in >> tsubst_copy [FIELD_DECL] when we shouldn't have. >> >> This patch makes template_class_depth look at a lambda type's >> LAMBDA_TYPE_EXTRA_SCOPE field instead of its TYPE_CONTEXT, so that it >> can iterate into an enclosing variable template, if applicable. >> >> Tested on x86_64-pc-linux gnu, no new regressions. Also tested against >> Boost. Is this OK to commit? > > > This is breaking several lambda testcases with -fconcepts on; > LAMBDA_TYPE_EXTRA_SCOPE can also be a FIELD_DECL or PARM_DECL. Let's just > check DECL_P. Sorry about that. In the case of LAMBDA_TYPE_EXTRA_SCOPE being a PARM_DECL, could there be a chance that this PARM_DECL has a non-null DECL_LANG_SPECIFIC? If so it looks like we could still later ICE in get_template_info (called from template_class_depth) when we try to get at its DECL_TEMPLATE_INFO, an accessor that cannot be used on PARM_DECLs. So I wonder if maybe get_template_info() should also be adjusted to handle the case of being given a PARM_DECL which may have a non-null DECL_LANG_SPECIFIC: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 823e2f0..f68b1f6 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -330,7 +330,8 @@ get_template_info (const_tree t) if (!t || t == error_mark_node) return NULL; - if (TREE_CODE (t) == NAMESPACE_DECL) + if (TREE_CODE (t) == NAMESPACE_DECL + || TREE_CODE (t) == PARM_DECL) return NULL; if (DECL_P (t) && DECL_LANG_SPECIFIC (t)) @@ -378,7 +379,7 @@ template_class_depth (tree type) && uses_template_parms (INNERMOST_TEMPLATE_ARGS (TI_ARGS (tinfo)))) ++depth; - if (VAR_OR_FUNCTION_DECL_P (type)) + if (DECL_P (type)) type = CP_DECL_CONTEXT (type); else if (LAMBDA_TYPE_P (type)) type = LAMBDA_TYPE_EXTRA_SCOPE (type);