From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18724 invoked by alias); 24 Jun 2019 08:54:43 -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 18708 invoked by uid 89); 24 Jun 2019 08:54:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=friend, day, HContent-Transfer-Encoding:8bit X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jun 2019 08:54:40 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5O8nHhs142965; Mon, 24 Jun 2019 08:54:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=ddkQRKgfhVRFht03IH3DFbNbMS5gkmOpUuJzwM3GzDM=; b=0ZFQpou8Nd0M3T+5bY8YZ4DyuhtmUAKpmGGe239cau40spDT7lQ2Ht12NO9HTQBXVGRN WFdRI43NkqLi4UpbsGX6Q7YhUoecrInJcSmjtvDmL6sRNP2Z9z99kofif1ulFn+w28YC yRROC6vYi3f8kkydSHsNyXVWUVMa/8jIgrEiN1n0N6z3Qc1lvkvMMThvtRnmFRsYVSKO R8H7CtTdaUFhVda3bF6kROwuYStSX4VeE2nvVS3POqcm6RH5I3l9h8oU0S5fkaZGAeGk eyBe/6mmbdx2Ek8nS/1qibwoamLQnFivBUUERk3zJVIfY0hjTd4R1uJ4Uhw0i+XQS0eT EA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2t9cyq51xn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 Jun 2019 08:54:38 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5O8pRmn076711; Mon, 24 Jun 2019 08:52:37 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2t9acbd0bg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 Jun 2019 08:52:37 +0000 Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5O8qW1P003055; Mon, 24 Jun 2019 08:52:33 GMT Received: from [192.168.1.4] (/87.13.236.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jun 2019 01:52:32 -0700 Subject: Re: [C++ Patch] PR 90909 ("[10 Regression] call devirtualized to pure virtual") To: Jason Merrill , "gcc-patches@gcc.gnu.org" References: <44e13170-109c-e540-9fc5-0c8e24737a96@oracle.com> <774030a9-7b07-b1e0-3219-b6acbf7f3240@redhat.com> <5bf0b3c7-4010-b077-8cf1-9f2935d52931@oracle.com> <2a75dae4-df42-2597-767b-4f4180a9b140@oracle.com> From: Paolo Carlini Message-ID: Date: Mon, 24 Jun 2019 08:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg01424.txt.bz2 Hi, On 23/06/19 19:45, Jason Merrill wrote: > On 6/23/19 7:53 AM, Paolo Carlini wrote: >> ... hi again ;) >> >> The other day I was having a look at using declarations for this >> issue and noticed that only a few lines below the de-virtualization >> check we have to handle functions found by a using declaration, for >> various reasons. In particular, we know whether we found a function >> fn where has been declared or in a derived class. Thus the idea: for >> the purpose of making some progress, in particular all the cases in >> c++/67184 & co, would it make sense for the time being to simply add >> a check to the de-virtualization condition restricting it to >> non-using declarations? See the below (it also moves the conditional >> a few lines below only for clarity and consistency with the code >> handling using declarations, no functional impact) What do you think? > > Hmm, perhaps we should check CLASSTYPE_FINAL in > resolves_to_fixed_type_p rather than in build_over_call at all; then > the code in build_new_method_call ought to set LOOKUP_NONVIRTUAL when > appropriate. I think your suggestion has to do with the initial implementation of this optimization, as contributed by my friend Roberto Agostino: we had the issue that it didn't handle at all user-defined operators and Vincenzo filed c++/53186. Thus, upon your suggestion, we moved the code to build_over_call, the current place:     https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00246.html where it catched both member functions and operators. Now - before we get to the details - if I move the CLASSTYPE_FINAL check to resolves_to_fixed_type_p we exactly regress on c++/53186, that is other/final2.C, because resolves_to_fixed_type_p is *never* called. The pending final4.C, also involving operators (I constructed it exactly because I knew operators could be tricky) is also not fixed, but in that case at least resolves_to_fixed_type_p *is* called, only, too late (I think, I more details later, if you like). All the other existing and pending testcases - involving member functions - appear to be Ok, even with a draft implementation of your suggestion (I slapped a 'if (CLASS_TYPE_P (t) && CLASSTYPE_FINAL (t)) return true;' in the middle of resolves_to_fixed_type_p. Thanks, Paolo.