From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20723 invoked by alias); 13 Mar 2003 20:26:22 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 20692 invoked by uid 48); 13 Mar 2003 20:26:22 -0000 Date: Thu, 13 Mar 2003 20:26:00 -0000 Message-ID: <20030313202622.20691.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, jgibbs@bluearc.com, mdorey@bluearc.com From: jason@gcc.gnu.org Reply-To: jason@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, jgibbs@bluearc.com, mdorey@bluearc.com, gcc-gnats@gcc.gnu.org Subject: Re: c++/9420: [3.2/3.3/3.4 regression] incomplete type incorrectly reported X-SW-Source: 2003-03/txt/msg00780.txt.bz2 List-Id: Synopsis: [3.2/3.3/3.4 regression] incomplete type incorrectly reported State-Changed-From-To: open->analyzed State-Changed-By: jason State-Changed-When: Thu Mar 13 20:26:21 2003 State-Changed-Why: Core issues 63 and 212 are relevant here. [temp.inst] says A class template specialization is implicitly instantiated if the class type is used in a context that requires a completely-defined object type or if the completeness of the class type might affect the semantics of the program. [Note: in particular, if the semantics of an expression depend on the member or base class lists of a class template specialization, the class template specialization is implicitly generated. For instance, deleting a pointer to class type depends on whether or not the class declares a destructor, and conversion between pointer to class types depends on the inheritance relationship between the two classes involved. ] ... If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place. In this case, we need to do overload resolution for E<0, because E is an enum. We consider op<(C,C) as a candidate. To test whether or not it is a valid candidate, we need to determine whether or not there is a conversion from E (and int) to C. Hmm... No, I'm making this harder than it actually is. The bug is that we're instantiating B when we don't need to, because we can't use a user-defined conversion from E (or int) to B, because we're already considering a UDC to C. This should be simple to fix. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9420