From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80534 invoked by alias); 7 Mar 2018 20:59:20 -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 80518 invoked by uid 89); 7 Mar 2018 20:59:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Mar 2018 20:59:18 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w27KvOu3166813; Wed, 7 Mar 2018 20:59:16 GMT Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2gjqfar2kw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Mar 2018 20:59:16 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w27KnFWg017800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Mar 2018 20:49:15 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w27KnEGs019270; Wed, 7 Mar 2018 20:49:15 GMT Received: from [192.168.1.4] (/82.61.149.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Mar 2018 12:49:14 -0800 Subject: Re: [C++ Patch/RFC] PR 71169 ("[7/8 Regression] ICE on invalid C++ code in pop_nested_class"), PR 71832 and more To: Jason Merrill Cc: "gcc-patches@gcc.gnu.org" References: <08cb94c2-f549-cf3a-47da-1447782a3796@oracle.com> <1cd142d6-4349-90a6-a6f9-f3043976435e@oracle.com> <3b0c214e-57a6-7c78-542e-f115b744f261@oracle.com> <7BDBFCD0-9F51-437E-B4B4-B7BC4A407F55@oracle.com> From: Paolo Carlini Message-ID: <27acd6d6-ad08-b88b-867a-a05f492bc44f@oracle.com> Date: Wed, 07 Mar 2018 20:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8825 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803070238 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00352.txt.bz2 Hi, On 07/03/2018 21:23, Jason Merrill wrote: > On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini wrote: >> Hi, >> >> [snip the various clarifications] >> >> Il 7 Marzo 2018 17:57:07 CET, Jason Merrill ha scritto: >>> My thought was that this patch adds a lot of managing of the flag in >>> different places in the parser, whereas looking for error_mark_node in >>> the template parms here would be just in one place. But if you prefer >>> the current approach, that's fine, it's straightforward enough. >> Thanks a lot for the various clarifications above, where essentially turns out that some details of my patch are correct essentially by chance ;) Seriously, I'm thinking the following: since 8 is getting real close, what if, for 8, for the known mild regressions, we go ahead with my super safe Plan B which I mentioned at beginning of the thread, then as soon as trunk branches we immediately apply my patch and we give it a serious spin, say we rebuild distros with it, and see what happens? > This is what I was suggesting, what do you think? Eh, eh, certainly I don't have anything to say from the correctness point of view. As I already tried to explain, what I find annoying in this kind of approach, no matter how well is implemented, is that at parsing time we have to go anyway over all the parameters of all the template lists and then we know once and for all, for the corresponding class, whether there are erroneous parameters or not. In this kind of approach we go again through all the parameters, and, for example, multiple times when there are nested classes for example, I'm pretty sure in some (other) cases too (I should think more about that to be more specific). If you ask my opinion, at the moment I still believe that the best solution would be doing something at parsing time, save the information, in a more elegant way, maybe adding a special "erroneous TREE_VEC" flag to the TREE_VECs. I don't know exactly. Even better a unique flag for all the template parameter lists of each class. That said, if you don't foresee immediate performance-related issues, it's of course your call ;) If/when I will have a more concrete alternate proposal I will speak up ;) Nice anyway that we agree about the basic idea :-) Paolo.