From patchwork Fri Apr 6 13:18:18 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 151184 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 D80B2B7035 for ; Fri, 6 Apr 2012 23:18:44 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1334323125; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=QpjxLbn iisvRqYtv9Z7HTaRMTu8=; b=CSEc+xzW7HGZvghKe9FSS17q9tiqcFi4+uiCffg UqWQvoziKgr1Zl5fX+77/uanbywoNgZBxDBnIVO6+qnPG9Vr+8hfWlJSClau/QJV 0f40ZjWNhi+iiOpFRutt/I1beF0KmR2kizafqS/LEzw67YdYaqfbr+PvTqOs8YhQ 06do= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Vqifvd30qLfOdepflm54F5s4BLLxSJj9XQaJPfdFq0pWCXmuNlBHJR5b3Kv3ri eNzsJcTly0NY0EQ0H7aM5YbO8bUS40c/iqDzXfsygEgerzGiX4ojTQq45vvMvlip o3emyH5o+ZJGE78GG97wHWh2t3yeoupzkXEtmfsOpoNj4=; Received: (qmail 1422 invoked by alias); 6 Apr 2012 13:18:38 -0000 Received: (qmail 1413 invoked by uid 22791); 6 Apr 2012 13:18:37 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, 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; Fri, 06 Apr 2012 13:18:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q36DIJv0000638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Apr 2012 09:18:19 -0400 Received: from [10.3.113.125] (ovpn-113-125.phx2.redhat.com [10.3.113.125]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q36DIIWR017379 for ; Fri, 6 Apr 2012 09:18:19 -0400 Message-ID: <4F7EED1A.4040807@redhat.com> Date: Fri, 06 Apr 2012 09:18:18 -0400 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: gcc-patches List Subject: C++ PATCH for c++/52596 (C++11 ICE with qualified-id in template) 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 Since in C++11 the things you can do with an lvalue are no longer a superset of the things you can do with an rvalue (specifically, you can't bind one to an rvalue reference) we can't just conservatively assume that an expression is an lvalue in a template and then get a better answer later. So we've started looking into NON_DEPENDENT_EXPR in lvalue_kind. But that breaks on this testcase; when we encounter a qualified-id in a template we build up a SCOPE_REF for it even though we know what it refers to so that we can do access control at instantiation time, and lvalue_kind didn't know how to deal with that. For 4.8 I'm fixing this by changing the second operand of the SCOPE_REF to be the decl found by lookup, as the instantiation code already knows what to do with that. For 4.7 I'm just conservatively assuming it's a regular lvalue; it has to be an lvalue because it's something with a name, and if it's a field it's a member of *this, which is an lvalue. It might be a bit-field, but bit-field semantics are a strict subset of normal lvalue semantics, so this is OK. Tested x86_64-pc-linux-gnu, applying to trunk and 4.7. commit 078e78553f6e1a3727dedf10ab2825c96552e86d Author: Jason Merrill Date: Thu Apr 5 14:41:25 2012 -0400 PR c++/52596 * tree.c (lvalue_kind): Treat a deferred access control SCOPE_REF as an lvalue. diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c index 2bb2801..9129a7e 100644 --- a/gcc/cp/tree.c +++ b/gcc/cp/tree.c @@ -150,8 +150,14 @@ lvalue_kind (const_tree ref) /* A scope ref in a template, left as SCOPE_REF to support later access checking. */ case SCOPE_REF: - gcc_assert (!type_dependent_expression_p (CONST_CAST_TREE(ref))); - return lvalue_kind (TREE_OPERAND (ref, 1)); + { + tree op = TREE_OPERAND (ref, 1); + /* The member must be an lvalue; assume it isn't a bit-field. */ + if (TREE_CODE (op) == IDENTIFIER_NODE) + return clk_ordinary; + gcc_assert (!type_dependent_expression_p (CONST_CAST_TREE (ref))); + return lvalue_kind (op); + } case MAX_EXPR: case MIN_EXPR: diff --git a/gcc/testsuite/g++.dg/template/qualified-id5.C b/gcc/testsuite/g++.dg/template/qualified-id5.C new file mode 100644 index 0000000..3126d33 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/qualified-id5.C @@ -0,0 +1,17 @@ +// PR c++/52596 + +struct msgpack_zone_finalizer_array { + int* tail; +}; +struct msgpack_zone { + msgpack_zone_finalizer_array finalizer_array; +}; +struct zone : public msgpack_zone { + template T* allocate(); + +}; +template +T* zone::allocate() +{ + --msgpack_zone::finalizer_array.tail; +}