Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

[Jason Merrill <jason at redhat dot com>]

On Thu, Sep 27, 2018, 7:08 PM Marek Polacek <polacek@redhat.com> wrote:

> On Thu, Sep 27, 2018 at 01:15:46AM -0400, Jason Merrill wrote:
> > On Thu, Sep 20, 2018 at 5:20 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > > On Thu, Sep 20, 2018 at 09:12:53AM +0200, Andreas Schwab wrote:
> > >> On Sep 19 2018, Jason Merrill <jason@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?
>
> Ok, I will (provided I can get a box that has
> TARGET_VTABLE_USES_DESCRIPTORS, I
> think ppc64 BE should be enough).
>

Since this is a compile time issue, I would think a cross compiler would do
the trick?

>