From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-34285-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28358 invoked by alias); 6 May 2003 13:06:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 28340 invoked by uid 71); 6 May 2003 13:06:01 -0000
Date: Tue, 06 May 2003 13:06:00 -0000
Message-ID: <20030506130601.28339.qmail@sources.redhat.com>
To: gdr@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Subject: Re: c++/99: [2003-03-26] Bug in type in error message.
Reply-To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
X-SW-Source: 2003-05/txt/msg00373.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR c++/99; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, carlo@alinoe.com,
  gdr@gcc.gnu.org, gcc-prs@gcc.gnu.org, martin@loewis.home.cs.tu-berlin.de
Cc:  
Subject: Re: c++/99: [2003-03-26] Bug in type in error message.
Date: Tue, 6 May 2003 15:04:23 +0200

 Here's a further reduced testcase, along with some more analysis:
 
  template<typename S> class X {};
  template<typename Q> int f(X<int>, X<Q>);
  template<typename B> int f(X<B>, X<int>);
 
  int main(void) {
     return f(X<int>(), X<int>());
  }
 
 If compiled this will output the following error message (note Q instead
 of B in the last line):
 
 99-3.cc: In function `int main()':
 99-3.cc:6: call of overloaded `f(X<int>, X<int>)' is ambiguous
 99-3.cc:2: candidates are: int f(X<int>, X<Q>) [with Q = int]
 99-3.cc:3:                 int f(X<Q>, X<int>) [with B = int]
 
 Analysis: When instantiating X<Q> a typedef like construct is
 created an added the list of instantiations of X. Should we
 ever ancounter X<Q> again, this type will be reused an no new instantiation
 is created. We also note along with the type that the template parameter
 S is bound to the outer template parameter Q. The relevant code for this
 is in pt.c:lookup_template_class.
 Problem: When we need to find a type for X<B> in a completly different
 outer template we walk the list of instantiations again (line 4322)
 and come accross the instance of X<Q>. At this point gcc (wrongly)
 decides that the Q in X<Q> and B are the same template parameters and
 reuses X<Q> instead of creating a new type. This can happen because
 there is no check if we're still in the same outer template. There are
 only checks if TEMPLATE_TYPE_IDX and TEMPLATE_TYPE_LEVEL match.
 
 However, the context of TEMPLATE_TYPE_DECLs should be compared somehow
 as well.
 
     regards  Christian
 
 -- 
 THAT'S ALL FOLKS!