On Thu, Sep 20, 2018 at 5:20 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Sep 20, 2018 at 09:12:53AM +0200, Andreas Schwab wrote: >> On Sep 19 2018, Jason Merrill <ja...@redhat.com> 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? Jason