From patchwork Thu Jul 5 21:24:09 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 169274 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]) by ozlabs.org (Postfix) with SMTP id 44B3E2C01BC for ; Fri, 6 Jul 2012 07:24:45 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1342128286; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=UcltWS3G0a11xlj+bHwm10KtkIo=; b=AXFKX6QESvPkhpB cX7AVBw3KZeB8xIFn66JpiihavgDivVe9V1BPs7PxTPy0r0ZblIqPwiRAM71fuIg L7xIhQ5fCeW8mnBl/ENuQqOAAh3KOqkJjBDhZvAANYLwQxRnt1R4XAYw6YHKN64J vqWkaiHI6fT7/rljXVPk0Gi+UqKQ= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ag59bDO2qFdoseqGuTG3fQcNaf6azCpZA2Olwhpem8Ly+H9t+xlpHgdzDj+JTq pxoXYmIU5JK/27a9rYWcwQMr6aBEMcv42Et/AhOWCx5VPbQYx8iWYQgv+jGH6+hj yJjYTFuN8LHzw2pJB+RKpO4105kHonn3Hn9i5PK8jqo0g=; Received: (qmail 4738 invoked by alias); 5 Jul 2012 21:24:37 -0000 Received: (qmail 4709 invoked by uid 22791); 5 Jul 2012 21:24:32 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, 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; Thu, 05 Jul 2012 21:24:11 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q65LOAhL011241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Jul 2012 17:24:10 -0400 Received: from [10.3.113.62] (ovpn-113-62.phx2.redhat.com [10.3.113.62]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q65LO9l2016503; Thu, 5 Jul 2012 17:24:10 -0400 Message-ID: <4FF605F9.1040102@redhat.com> Date: Thu, 05 Jul 2012 17:24:09 -0400 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: gcc-patches List , Dodji Seketeli Subject: Re: C++ PATCH for c++/50852, 53039 (problems with typedefs in templates) References: <4FF5ED16.909@redhat.com> In-Reply-To: <4FF5ED16.909@redhat.com> 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 On 07/05/2012 03:37 PM, Jason Merrill wrote: > have not done that for non-type arguments so far. This patch implements > typedef stripping for non-type template arguments, and thereby avoids > the need for any fixup of sibling information. > > The patch also fixes 53039, which is another case of treating things as > interchangeable that turn out not to be: in this case they are template > parameter packs that are compared for identity in arg_from_parm_pack_p, > which was running into problems during template parameter fixup. I > didn't expect this patch to fix the bug, but apparently removing the > fixup solves the problem for this testcase. And since we no longer have to try to deal with comparing fixed-up and non-fixed-up template parms, we can revert the earlier patch for PR 46394 which led to the issue in 53039. Tested x86_64-pc-linux-gnu, applying to trunk. commit 1213de7ecf31a323c64fa75fba30e523431602db Author: Jason Merrill Date: Thu Jul 5 15:49:23 2012 -0400 PR c++/53039 * pt.c (arg_from_parm_pack_p): Go back to using same_type_p or cp_tree_equal. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index e07a362..df5d1f6 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -3760,34 +3760,13 @@ arg_from_parm_pack_p (tree arg_pack, tree parm_pack) { tree expansion = TREE_VEC_ELT (ARGUMENT_PACK_ARGS (arg_pack), 0); tree pattern = PACK_EXPANSION_PATTERN (expansion); - /* So we have an argument_pack. We want to test if P - is actually PARM_PACK. We will not use cp_tree_equal to - test P and PARM_PACK because during type fixup (by - fixup_template_parm) P can be a pre-fixup version of a - type and PARM_PACK be its post-fixup version. - cp_tree_equal would consider them as different even - though we would want to consider them compatible for our - precise purpose here. - - Thus we are going to consider that P and PARM_PACK are - compatible if they have the same DECL. */ - if ((/* If ARG_PACK is a type parameter pack named by the - same DECL as parm_pack ... */ - (TYPE_P (pattern) - && TYPE_P (parm_pack) - && TYPE_NAME (pattern) == TYPE_NAME (parm_pack)) - /* ... or if PARM_PACK is a non-type parameter named by the - same DECL as ARG_PACK. Note that PARM_PACK being a - non-type parameter means it's either a PARM_DECL or a - TEMPLATE_PARM_INDEX. */ - || (TREE_CODE (pattern) == TEMPLATE_PARM_INDEX - && ((TREE_CODE (parm_pack) == PARM_DECL - && (TEMPLATE_PARM_DECL (pattern) - == TEMPLATE_PARM_DECL (DECL_INITIAL (parm_pack)))) - || (TREE_CODE (parm_pack) == TEMPLATE_PARM_INDEX - && (TEMPLATE_PARM_DECL (pattern) - == TEMPLATE_PARM_DECL (parm_pack)))))) - && template_parameter_pack_p (pattern)) + if ((TYPE_P (pattern) && same_type_p (pattern, parm_pack)) + || (!TYPE_P (pattern) && cp_tree_equal (parm_pack, pattern))) + /* The argument pack that the parameter maps to is just an + expansion of the parameter itself, such as one would + find in the implicit typedef of a class inside the + class itself. Consider this parameter "unsubstituted", + so that we will maintain the outer pack expansion. */ return true; } return false;