From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2749 invoked by alias); 11 Nov 2009 14:32:42 -0000 Received: (qmail 2739 invoked by uid 22791); 11 Nov 2009 14:32:40 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Nov 2009 14:32:37 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1N8EFM-0007xq-OL for gcc@gcc.gnu.org; Wed, 11 Nov 2009 15:32:32 +0100 Received: from r74-192-0-229.bcstcmta01.clsttx.tl.dh.suddenlink.net ([74.192.0.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Nov 2009 15:32:32 +0100 Received: from cppljevans by r74-192-0-229.bcstcmta01.clsttx.tl.dh.suddenlink.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Nov 2009 15:32:32 +0100 To: gcc@gcc.gnu.org From: Larry Evans Subject: Re: [c++]pt.c:most_specialized_class appears to substitute outer args for inner params Date: Wed, 11 Nov 2009 14:32:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.23 (X11/20090817) In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00300.txt.bz2 On 11/02/09 22:39, Larry Evans wrote: > The following code around trunk/gcc/cp/pt.c:15514: > > 15513 partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args); > 15514 partial_spec_args = tsubst_template_args > 15515 (partial_spec_args, outer_args, tf_none, NULL_TREE); > > as shown here: > > http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?view=markup&pathrev=153822 > > appears to substitute outer_args in the place where inner parameters > are located. Am I reading the code wrong? I ask because gdb seems to > show this happening with the following code: > > --{-- test code -- > struct > outer_arg0 > ; > struct > inner_arg0 > ; > struct > inner_arg1 > ; > > //#define CLASS_SCOPE_SPECIALIZATION > template > < class OuterArg0 > > > struct > outer_tmpl > { > template > < typename InnerArg0 > , typename InnerArg1 > > > struct > inner_tmpl > #ifndef CLASS_SCOPE_SPECIALIZATION > ; > #else > {}; > template > < typename InnerArg0 > > > struct > inner_tmpl > < InnerArg0 > , inner_arg1 > > > { > typedef > InnerArg0 > inner_typdef > ; > }; > #endif > }; > > #ifndef CLASS_SCOPE_SPECIALIZATION > template > < //class OuterArg0 > > > template > < typename InnerArg0 > > > struct > outer_tmpl > < outer_arg0 > >:: > inner_tmpl > < InnerArg0 > , inner_arg1 > > > { > typedef > InnerArg0 > inner_typdef > ; > }; > #endif > > typedef > outer_tmpl > ::inner_tmpl > < inner_arg0 > , inner_arg1 > > > ::inner_typdef //error here. > outer_inner_type > ; > --}-- test code -- [snip] Just adding an outer_tmpl specialization solves the problem: template struct outer_tmpl < outer_arg0 > { template < typename InnerArg0 , typename InnerArg1 > struct inner_tmpl ; };