From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42504 invoked by alias); 14 Sep 2018 20:31: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 42438 invoked by uid 89); 14 Sep 2018 20:31:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Sep 2018 20:31:16 +0000 Received: by mail-oi0-f65.google.com with SMTP id t68-v6so13922275oie.12 for ; Fri, 14 Sep 2018 13:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:1522:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 13:30:46 -0700 (PDT) In-Reply-To: <20180914171950.GE5587@redhat.com> References: <20180914171950.GE5587@redhat.com> From: Jason Merrill Date: Fri, 14 Sep 2018 20:32:00 -0000 Message-ID: Subject: Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions To: Marek Polacek Cc: GCC Patches , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00786.txt.bz2 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. > 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... Jason