From patchwork Thu Feb 10 18:31:18 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dodji Seketeli X-Patchwork-Id: 82646 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 922C8B70E3 for ; Fri, 11 Feb 2011 05:31:33 +1100 (EST) Received: (qmail 23967 invoked by alias); 10 Feb 2011 18:31:30 -0000 Received: (qmail 23870 invoked by uid 22791); 10 Feb 2011 18:31:29 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, 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, 10 Feb 2011 18:31:23 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1AIVLEU010065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 13:31:21 -0500 Received: from adjoa.redhat.com (ovpn-113-77.phx2.redhat.com [10.3.113.77]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p1AIVIEQ023208; Thu, 10 Feb 2011 13:31:20 -0500 From: Dodji Seketeli To: Jason Merrill Cc: Gabriel Dos Reis , GCC Patches Subject: Re: [PATCH] Fix PR c++/47172 References: <4D52DBB7.5000908@redhat.com> <4D5407D9.2060709@redhat.com> X-URL: http://www.redhat.com Date: Thu, 10 Feb 2011 19:31:18 +0100 In-Reply-To: <4D5407D9.2060709@redhat.com> (Jason Merrill's message of "Thu, 10 Feb 2011 10:44:25 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes 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 Jason Merrill writes: > Just add a reference to issues 515 and 1005. Done. >> + || (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn) >> + && current_class_ref >> + && type_dependent_expression_p (current_class_ref))) > > I'm uncomfortable with checking DECL_NONSTATIC_MEMBER_FUNCTION_P > before we've established that fn is a FUNCTION_DECL. Let's check its > TREE_CODE first. Right; done. >> /* Returns TRUE if the EXPRESSION is type-dependent, in the sense of >> - [temp.dep.expr]. */ >> + [temp.dep.expr]. Note that an expression with no type is >> + considered dependent. */ > > Let's also note that other parts of the compiler arrange for an > expression with type-dependent subexpressions to have no type, so we > don't need to recurse in type_dependent_expression_p. Done. I am currently running a full bootstrap & regression tests. OK to commit to trunk if the testing succeeds? diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index d59f32a..746e295 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -17912,7 +17912,7 @@ dependent_type_p_r (tree type) } /* Returns TRUE if TYPE is dependent, in the sense of - [temp.dep.type]. */ + [temp.dep.type]. Note that a NULL type is considered dependent. */ bool dependent_type_p (tree type) @@ -18184,7 +18184,10 @@ value_dependent_expression_p (tree expression) } /* Returns TRUE if the EXPRESSION is type-dependent, in the sense of - [temp.dep.expr]. */ + [temp.dep.expr]. Note that an expression with no type is + considered dependent. Other parts of the compiler arrange for an + expression with type-dependent subexpressions to have no type, so + this function doesn't have be fully recursive. */ bool type_dependent_expression_p (tree expression) diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c index 6d45fb9..4e9e71e 100644 --- a/gcc/cp/semantics.c +++ b/gcc/cp/semantics.c @@ -2028,8 +2028,21 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool disallow_virtual, if (processing_template_decl) { + /* If the call expression is dependent, build a CALL_EXPR node + with no type; type_dependent_expression_p recognizes + expressions with no type as being dependent. */ if (type_dependent_expression_p (fn) - || any_type_dependent_arguments_p (*args)) + || any_type_dependent_arguments_p (*args) + /* In a template scope, a call expression which + id-expression is non-dependent is considered dependent if + the implicit "this" is dependent. Note that the + id-expression is already bound (at template definition + time) so this respects the essence of the two-phases name + lookup. This is related to CWG issues 515 and 1005. */ + || (TREE_CODE (fn) == FUNCTION_DECL + && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn) + && current_class_ref + && type_dependent_expression_p (current_class_ref))) { result = build_nt_call_vec (fn, *args); KOENIG_LOOKUP_P (result) = koenig_p; diff --git a/gcc/testsuite/g++.dg/template/inherit6.C b/gcc/testsuite/g++.dg/template/inherit6.C new file mode 100644 index 0000000..241a68e --- /dev/null +++ b/gcc/testsuite/g++.dg/template/inherit6.C @@ -0,0 +1,23 @@ +// Origin PR c++/47172 +// { dg-options "-std=c++0x" } +// { dg-do compile } + +struct A +{ + int f() const; +}; + +template +struct B : A { }; + +template +struct C : B +{ + void g(); +}; + +template +void C::g() +{ + A::f(); +}