From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9299 invoked by alias); 10 Nov 2013 06:10:55 -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 9282 invoked by uid 89); 10 Nov 2013 06:10:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 10 Nov 2013 06:10:53 +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 rAA6Ajaf008837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Nov 2013 01:10:46 -0500 Received: from [10.10.116.17] ([10.10.116.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAA6AiK9028701; Sun, 10 Nov 2013 01:10:45 -0500 Message-ID: <527F2364.3060404@redhat.com> Date: Sun, 10 Nov 2013 10:34:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Adam Butcher CC: gcc-patches@gcc.gnu.org, Volker Reichelt Subject: Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637. References: <1383212824-5493-1-git-send-email-adam@jessamine.co.uk> <1383212824-5493-2-git-send-email-adam@jessamine.co.uk> <527D328D.9010800@redhat.com> <48a0350ad377d7ec6de413e61724fe4e@imap.force9.net> In-Reply-To: <48a0350ad377d7ec6de413e61724fe4e@imap.force9.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg01038.txt.bz2 On 11/09/2013 08:21 AM, Adam Butcher wrote: >>> + TYPE_STUB_DECL (t) = TYPE_NAME (t) = TEMPLATE_TYPE_DECL (t); >> >> Is this changing anything? I'm not sure if we need to copy the decl >> or if we can just reuse it, but either way we need to set the type of >> TEMPLATE_TYPE_DECL (t) to t. >> > I think it (or at least one of the assignments) is necessary. It is > derived from some similar code in tsubst. The code in tsubst is updating the type because the TEMPLATE_TYPE_PARM_INDEX has changed; in this case, it hasn't, so neither has the TEMPLATE_TYPE_DECL. But see below... > I'll have another look into > it and add TREE_TYPE (TEMPLATE_TYPE_DECL (t)) = t also. What problem > will be caused by not setting the latter; is it a consistency issue? I > have not seen any probs in testing so far. Just that without this assignment anything wanting to get from the TYPE_DECL to its type will get the non-pack, but we want it to get the pack. Hmm, actually I think messing with the non-pack's decl is dangerous, and we should come up with a new decl for the pack instead. I think you can use reduce_template_parm_level with a "levels" argument of 0 to build a new decl and parm index. And if we're doing that, setting TYPE_STUB_DECL and TYPE_NAME is indeed necessary. > Only for the sake of not exposing this (currently static) function from > pt.c (or moving the pack convert function into pt.c). My original impl > did extern canonical_type_parameter and use that and I think it worked > as expected. Would that be preferred? Yes. Please declare it in cp-tree.h rather than within the function. Jason