From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4073 invoked by alias); 22 Aug 2014 19:33:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 4063 invoked by uid 89); 22 Aug 2014 19:33:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 22 Aug 2014 19:33:20 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7MJXH2F026763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Aug 2014 19:33:18 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7MJXGYm010870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 19:33:17 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7MJXFli014967; Fri, 22 Aug 2014 19:33:15 GMT Received: from [192.168.1.4] (/79.12.211.101) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Aug 2014 12:33:15 -0700 Message-ID: <53F79AF8.3020004@oracle.com> Date: Fri, 22 Aug 2014 19:33:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [C++ RFC/Patch] PR 34938 References: <53F78398.2000908@oracle.com> <53F7894C.8010803@redhat.com> <53F797AD.5070309@oracle.com> <53F79990.5040004@redhat.com> In-Reply-To: <53F79990.5040004@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg02218.txt.bz2 Hi, On 08/22/2014 09:27 PM, Jason Merrill wrote: > On 08/22/2014 03:19 PM, Paolo Carlini wrote: >> Ok. Currently in cases like the present one, dump_type_suffix upon a >> pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given >> FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer >> context, just sees the latter. Do you think that the current simple >> setup, thus my patch which just extends it, can be incorrect in some >> cases? > > Yes, I think your patch changes it to be incorrect in different cases > than the ones where it's currently incorrect, namely the typedef and > template argument cases that I mentioned. Let me think about this. I'm not sure to understand what this boils down to, if we have to seriously restructure what we have got or not. Do you think that we have to track during the recursion in dump_type_suffix that the FUNCTION_TYPE / METHOD_TYPE comes from a pointer? > Incidentally, I don't understand > >> + pp_c_ws_string (pp, (func_type && !method_type > vs >> + pp_c_ws_string (pp, (func_type || method_type > > Surely the same logic is appropriate for both const and noreturn, and > they are represented the same way on both function_ and method_type. Ah, Ok, now I see, it's just that volatile member functions aren't *that* common ;) Paolo.