From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68547 invoked by alias); 14 Sep 2018 20:46:11 -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 68359 invoked by uid 89); 14 Sep 2018 20:45:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Sep 2018 20:45:29 +0000 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9FCBD3078AD5 for ; Fri, 14 Sep 2018 20:45:24 +0000 (UTC) Received: from redhat.com (ovpn-121-46.rdu2.redhat.com [10.10.121.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0F75130918D4; Fri, 14 Sep 2018 20:45:23 +0000 (UTC) Date: Fri, 14 Sep 2018 20:46:00 -0000 From: Marek Polacek To: Jason Merrill Cc: GCC Patches , Jakub Jelinek Subject: Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions Message-ID: <20180914204521.GJ5587@redhat.com> References: <20180914171950.GE5587@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2018-09/txt/msg00790.txt.bz2 On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jason Merrill wrote: > On Fri, Sep 14, 2018 at 1:19 PM, Marek Polacek wrote: > > This patch implements another bit of C++20, virtual calls in constant > > expression: > > > > The basic idea is that since in a constant expression we know the dynamic > > type (to detect invalid code etc.), the restriction that prohibits virtual > > calls is unnecessary. > > > > Handling virtual function calls turned out to be fairly easy (as anticipated); > > I simply let the constexpr machinery figure out the dynamic type and then > > OBJ_TYPE_REF_TOKEN gives us the index into the virtual function table. That > > way we get the function decl we're interested in, and cxx_eval_call_expression > > takes it from there. > > > > But handling pointer-to-virtual-member-functions doesn't work like that. > > get_member_function_from_ptrfunc creates a COND_EXPR which looks like > > if (pf.__pfn & 1) // is it a virtual function? > > // yes, find the pointer in the vtable > > else > > // no, just return the pointer > > so ideally we want to evaluate the then-branch. Eventually it'll evaluate it > > to something like _ZTV2X2[2], but the vtable isn't constexpr so we'd end up > > with "not a constant expression" error. > > Then let's mark the vtable as constexpr, there's no reason for it not to be. Ok, unfortunately it wasn't as easy as merely marking it DECL_DECLARED_CONSTEXPR_P in initialize_artificial_var because then I saw "used in its own initializer" error. Which I don't know why, but now that I know you agree with this direction I can dig deeper. > > Since the vtable initializer is > > a compile-time constant, I thought we could make it work by a hack as the one > > in cxx_eval_array_reference. We'll then let cxx_eval_call_expression do its > > job and everything is hunky-dory. > > > > Except when it isn't: I noticed that the presence of _vptr doesn't make the > > class non-empty, and when cxx_eval_constant_expression saw a decl with an empty > > class type, it just evaluated it to { }. But such a class still had gotten an > > initializer that looks like {.D.2082 = {._vptr.X2 = &_ZTV2X2 + 16}}. So > > replacing it with { } will lose the proper initializer whereupon we fail. > > The check I've added to cxx_eval_constant_expression won't win any beauty > > contests but unfortunately EMPTY_CONSTRUCTOR_P doesn't work there. > > Perhaps we should check !TYPE_POLYMORPHIC_P as well as > is_really_empty_class. Perhaps there should be a predicate for that, > say, is_really_nearly_empty_class... Ack. Thanks, Marek