From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78771 invoked by alias); 14 Dec 2018 18:44:32 -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 78742 invoked by uid 89); 14 Dec 2018 18:44:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:templat, H*Ad:D*oracle.com, HContent-Transfer-Encoding:8bit X-HELO: aserp2130.oracle.com Received: from aserp2130.oracle.com (HELO aserp2130.oracle.com) (141.146.126.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Dec 2018 18:44:27 +0000 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBEIfF2v133662; Fri, 14 Dec 2018 18:44:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=M4buSsHMpiDtWLyMT2MFY1v6NRS7sm6xR7ae3TWGi1o=; b=U5pQ4zf4Ie7tyNnG8IIuq1rN3cdVLtkQu3mZTGrQK+Qo7925MWOESAviwCAb5xYH7TWg r57tWhS3V+y88BXEr+bRbNcOsH08E8CRnBzKHr27d5MOA6Gtdq+pVWSQXjqckRNsxQIc 1TXWN1RCjXwnrMFsjt+B890yG2LEJdCT1yZrehLqtCC/bbc1IAOOUCcQfmPMWcEuvCvd CX3V1hfqVGcg70P9p+rRPASkO0HeFJSoa0zNgxvZ5f0dcFeppj4MoKPkJ7Izr7UCsIwg yL7ZPYwt2I/52GpqkyKm5fo5Vv3pQ68YbwEBF3L2XtnwAOiBpoF6oD+C1b3/WKQuGQIq Yw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2pawwpeqh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Dec 2018 18:44:24 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wBEIiN4p032729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Dec 2018 18:44:23 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wBEIiNRM003595; Fri, 14 Dec 2018 18:44:23 GMT Received: from [192.168.1.4] (/80.181.224.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Dec 2018 10:44:23 -0800 Subject: Re: [C++ Patch] PR 84644 ("internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718") To: Jason Merrill Cc: gcc-patches List , Nathan Sidwell References: <4c6fe735-5435-1ede-a85a-787262a7e63c@oracle.com> <37c9ffea-5929-a209-7818-67e05d44edcc@oracle.com> <1db43e23-22da-0f4a-d711-fe6c54244564@oracle.com> <6d56abf3-93a0-d1ad-0072-2e0d9922b492@redhat.com> From: Paolo Carlini Message-ID: <6d889ffa-607f-853e-4b87-68bcf5c1028c@oracle.com> Date: Fri, 14 Dec 2018 18:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <6d56abf3-93a0-d1ad-0072-2e0d9922b492@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01083.txt.bz2 Hi, On 13/12/18 22:03, Jason Merrill wrote: > On 10/30/18 9:22 PM, Paolo Carlini wrote: >> Hi, >> >> On 30/10/18 21:37, Jason Merrill wrote: >>> On 10/26/18 2:02 PM, Paolo Carlini wrote: >>>> On 26/10/18 17:18, Jason Merrill wrote: >>>>> On Fri, Oct 26, 2018 at 4:52 AM Paolo Carlini >>>>> wrote: >>>>>> On 24/10/18 22:41, Jason Merrill wrote: >>>>>>> On 10/15/18 12:45 PM, Paolo Carlini wrote: >>>>>>>>          && ((TREE_CODE (declspecs->type) != TYPENAME_TYPE >>>>>>>> +       && TREE_CODE (declspecs->type) != DECLTYPE_TYPE >>>>>>>>           && MAYBE_CLASS_TYPE_P (declspecs->type)) >>>>>>> I would think that the MAYBE_CLASS_TYPE_P here should be >>>>>>> CLASS_TYPE_P, >>>>>>> and then we can remove the TYPENAME_TYPE check.  Or do we want to >>>>>>> allow template type parameters for some reason? >>>>>> Indeed, it would be nice to just use OVERLOAD_TYPE_P. However it >>>>>> seems >>>>>> we at least want to let through TEMPLATE_TYPE_PARMs representing >>>>>> 'auto' >>>>>> - otherwise Dodji's check a few lines below which fixed c++/51473 >>>>>> doesn't work anymore - and also BOUND_TEMPLATE_TEMPLATE_PARM, >>>>>> otherwise >>>>>> we regress on template/spec32.C and template/ttp22.C because we >>>>>> don't >>>>>> diagnose the shadowing anymore. Thus, I would say either we keep on >>>>>> using MAYBE_CLASS_TYPE_P or we pick what we need, possibly we add >>>>>> a comment? >>>>> Aha.  I guess the answer is not to restrict that test any more, but >>>>> instead to fix the code further down so it gives a proper diagnostic >>>>> rather than call warn_misplaced_attr_for_class_type. >>>> >>>> I see. Thus something like the below? It passes testing on >>>> x86_64-linux. >>> >>>> +  if ((!declared_type || TREE_CODE (declared_type) == DECLTYPE_TYPE) >>>> +      && ! saw_friend && !error_p) >>>>      permerror (input_location, "declaration does not declare >>>> anything"); >>> >>> I see no reason to make this specific to decltype.  Maybe move this >>> diagnostic into the final 'else' block with the other declspec >>> diagnostics and not look at declared_type at all? >> >> I'm not sure to fully understand: if we do that we still want to at >> least minimally check that declared_type is null, like we already do, >> and then we simply accept the new testcase. Is that Ok? Because, as I >> probably mentioned at some point, all the other compilers I have at >> hand issue a "does not declare anything" diagnostic, and we likewise >> do that for the legacy __typeof. Not looking into declared_type *at >> all* doesn't work with plain class types and enums, of course. Or you >> meant something entirely different?? >> >>>> +  if (declspecs->attributes && warn_attributes && declared_type >>>> +      && TREE_CODE (declared_type) != DECLTYPE_TYPE) >>> >>> I think we do want to give a diagnostic about useless attributes, >>> not skip it. >> >> Agreed. FWIW the attached tests fine. > > The problem here is that the code toward the bottom expects > "declared_type" to be the tagged type declared by a declaration with > no declarator, and in this testcase it's ending up as a DECLTYPE_TYPE. > > I think once we've checked for 'auto' we don't want declared_type to > be anything that isn't OVERLOAD_TYPE_P.  We can arrange that either by > checking for 'auto' first and then changing the code that sets > declared_type to use OVERLOAD_TYPE_P, or by clearing declared_type > after checking for 'auto' if it isn't OVERLOAD_TYPE_P. Thanks. I'm slowly catching up on this issue... Any suggestion about BOUND_TEMPLATE_TEMPLATE_PARM? If we don't let through such tree nodes - which are MAYBE_CLASS_TYPE_P and aren't OVERLOAD_TYPE_P - we regress on template/spec32.C, we don't reject it anymore., Paolo.