From patchwork Sat Apr 27 21:17:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 240201 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 902202C00AE for ; Sun, 28 Apr 2013 07:17:42 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=fwvu/Ex+x3+A6j+Im SVT6EHqrZIDazX0CAbQc/BqBAhedM5fcF13C6jLmncnrQ5Im63LiugytxFB3U9j5 TzEbYxDKl3Sw0fO7UyqLKljzSIIz/bQQr7iSpbirkyF/xExCQqFclWA26rvHFFYI nDk/aBkMFoPwHEEMvRBFQYpuh0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=NdkgaOXAxtHAQkwWPEwuqyV 4s1I=; b=xRxXXOSriQgs94L5mBYr4kjtI+TrM846pMai7Lp3PNuUezmpuqcvy6K +4QS4/yxOUInDf3BzrTyAzCEAq+QDFK2XZTPGVUB77PqfyG6fHCpOg9LRCuSdkF6 41dqLvJR+XBzUsQwiFZBrvq6cBlIozwvZUS2QdLjpvFQkCYf0gnw= Received: (qmail 31571 invoked by alias); 27 Apr 2013 21:17:36 -0000 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 Received: (qmail 31561 invoked by uid 89); 27 Apr 2013 21:17:35 -0000 X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RCVD_IN_DNSWL_MED, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD, SPF_PASS, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 27 Apr 2013 21:17:35 +0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3RLHVrL004890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Apr 2013 21:17:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3RLHUlK026029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 27 Apr 2013 21:17:31 GMT Received: from ubhmt112.oracle.com (ubhmt112.oracle.com [156.151.24.17]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3RLHUEQ018364; Sat, 27 Apr 2013 21:17:30 GMT Received: from poldo4.casa (/79.52.192.252) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Apr 2013 14:17:30 -0700 Message-ID: <517C4067.8070207@oracle.com> Date: Sat, 27 Apr 2013 23:17:27 +0200 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jason Merrill CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ Patch/RFC] PR 56450 References: <517AB267.7020900@oracle.com> <517B2237.4090401@redhat.com> In-Reply-To: <517B2237.4090401@redhat.com> X-Virus-Found: No Hi again, On 04/27/2013 02:56 AM, Jason Merrill wrote: > Why should id_expression_or_member_access_p be false? > "declval().dummy" is a class member access (5.2.5) regardless of > what kind of member dummy is. today I have been able to spend some more time on the issue, and I think the attached further reduced testcase summarizes rather well what I figured out. Assuming as obvious that we don't want to crash on it, the interesting issue is whether we want the static_asserts to both fail or succeed: in practice, a rather recent ICC I have at hand fails both; a rather recent clang++ passes both (consistently with the expectation of Bug submitter). In fact, as I'm reading now 7.1.6.2/4, since we are dealing with a class member access in any case, it may well be possible that *ICC* is right. And then a tiny patch like the attached works for me to obtain the same behavior for GCC (passes testing etc; it's the first "stupid" thing I tried days ago ;) FWIW, the attached testcase also explains pretty well why my earlier hack appeared to work, in the sense of recent clang++: we ended up calling cp_build_reference_type on the type. Overall, I think the situation is rather clear by now. What do you think? Thanks! Paolo. //////////////////////// Index: semantics.c =================================================================== --- semantics.c (revision 198359) +++ semantics.c (working copy) @@ -5398,6 +5398,7 @@ finish_decltype_type (tree expr, bool id_expressio break; case COMPONENT_REF: + case COMPOUND_EXPR: mark_type_use (expr); type = is_bitfield_expr_with_lowered_type (expr); if (!type)