From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42027 invoked by alias); 27 Sep 2018 23:08:48 -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 42014 invoked by uid 89); 27 Sep 2018 23:08:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham 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; Thu, 27 Sep 2018 23:08:45 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 737C83082A51; Thu, 27 Sep 2018 23:08:44 +0000 (UTC) Received: from redhat.com (ovpn-120-207.rdu2.redhat.com [10.10.120.207]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C5455600C5; Thu, 27 Sep 2018 23:08:43 +0000 (UTC) Date: Thu, 27 Sep 2018 23:18:00 -0000 From: Marek Polacek To: Jason Merrill Cc: Jakub Jelinek , Andreas Schwab , GCC Patches Subject: Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4) Message-ID: <20180927230841.GH5587@redhat.com> References: <20180918185534.GR16755@redhat.com> <20180919140518.GN5587@redhat.com> <20180919151023.GO5587@redhat.com> <20180920092059.GE8250@tucnak> 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/msg01700.txt.bz2 On Thu, Sep 27, 2018 at 01:15:46AM -0400, Jason Merrill wrote: > On Thu, Sep 20, 2018 at 5:20 AM, Jakub Jelinek wrote: > > On Thu, Sep 20, 2018 at 09:12:53AM +0200, Andreas Schwab wrote: > >> On Sep 19 2018, Jason Merrill wrote: > >> > >> > Andreas, do the new testcases pass? That would surprise me, but OK if so. > >> > >> No, they don't. > >> > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:29:26: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:29:23: error: expression '((& X2::_ZTV2X2) + 16)' does not designate a 'constexpr' function > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:26: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:23: error: expression '((& X2::_ZTV2X2) + 16)' does not designate a 'constexpr' function > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:37:27: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:37:24: error: expression '((& X2::_ZTV2X2) + 16)' does not designate a 'constexpr' function > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:41:26: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:41:23: error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' function > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:45:26: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:45:23: error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' function > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:49:27: error: non-constant condition for static assertion > >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:49:24: error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' function > >> compiler exited with status 1 > >> FAIL: g++.dg/cpp2a/constexpr-virtual2.C (test for excess errors) > > > > I think the primary problem here is: > > /* When using function descriptors, the address of the > > vtable entry is treated as a function pointer. */ > > if (TARGET_VTABLE_USES_DESCRIPTORS) > > e2 = build1 (NOP_EXPR, TREE_TYPE (e2), > > cp_build_addr_expr (e2, complain)); > > in typeck.c, on non-descriptor targets we have an INDIRECT_REF where we > > read the vtable function pointer. On ia64, the above optimizes the > > INDIRECT_REF away, so what the cxx_eval_call_expression actually gets > > after constexpr evaluating the CALL_FN is not ADDR_EXPR of a function, > > but the address of the function descriptor (e.g. &_ZTV2X2 + 16 ). > > > > So, perhaps in cxx_eval_call_expression we need: > > if (TREE_CODE (fun) == ADDR_EXPR) > > fun = TREE_OPERAND (fun, 0); > > + else if (TARGET_VTABLE_USES_DESCRIPTORS > > + && TREE_CODE (fun) == POINTER_PLUS_EXPR > > + && ...) > > where we verify that p+ first argument is ADDR_EXPR of a virtual table, > > second arg is INTEGER_CST and just walk the DECL_INITIAL of that, finding > > the FDESC_EXPR at the right offset (therefore, I believe you need following > > rather than the patch you've posted, so that you can actually find it) and > > finally pick the function from the FDESC_EXPR entry. > > Makes me wonder what happens with indirect calls in constexpr evaluation, > > e.g. if I do: > > constexpr int bar () { return 42; } > > constexpr int foo () { int (*fn) () = bar; return fn (); } > > static_assert (foo () == 42); > > but apparently this works. > > > > --- gcc/cp/class.c.jj 2018-09-20 09:56:59.229751895 +0200 > > +++ gcc/cp/class.c 2018-09-20 10:12:17.447370890 +0200 > > @@ -9266,7 +9266,6 @@ build_vtbl_initializer (tree binfo, > > tree vcall_index; > > tree fn, fn_original; > > tree init = NULL_TREE; > > - tree idx = size_int (jx++); > > > > fn = BV_FN (v); > > fn_original = fn; > > @@ -9370,7 +9369,7 @@ build_vtbl_initializer (tree binfo, > > int i; > > if (init == size_zero_node) > > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i) > > - CONSTRUCTOR_APPEND_ELT (*inits, idx, init); > > + CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init); > > else > > for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i) > > { > > @@ -9378,11 +9377,11 @@ build_vtbl_initializer (tree binfo, > > fn, build_int_cst (NULL_TREE, i)); > > TREE_CONSTANT (fdesc) = 1; > > > > - CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc); > > + CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), fdesc); > > } > > } > > else > > - CONSTRUCTOR_APPEND_ELT (*inits, idx, init); > > + CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init); > > } > > } > > This patch is OK. And your suggestion for cxx_eval_call_expression > sounds right, too. Marek, will you follow up on that? Ok, I will (provided I can get a box that has TARGET_VTABLE_USES_DESCRIPTORS, I think ppc64 BE should be enough). Marek