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
