[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2020-09-25 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Marek Polacek  ---
Implemented in GCC 11.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2020-06-24 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #20 from Jakub Jelinek  ---
Not working on this further.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #19 from Jakub Jelinek  ---
Also note the update_vtable_entry_for_fn changes (except the formatting one)
were done just in desperate attempt to avoid various ICEs, I'm afraid I have no
idea what would need to be done to diagnose consteval method covariant returns
are valid, but without ICEing because we can't find those in structures that
don't have those already, or e.g. that we don't try to create thunks.  And,
guess the cxx_eval_constant_call or somewhere similar it needs to be able to
deal with what thunks would normally deal with.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #18 from Jakub Jelinek  ---
Testcase for pmf (incomplete, guess the non-pmf calls should be converted too):
struct S {
  constexpr S () : s (0) {}
  virtual int foo () const { return 42; }
  consteval virtual int bar () const { return 43; }
  consteval virtual int baz () const { return 44; }
  int s;
};
struct T : public S {
  constexpr T () : t (0) {}
  consteval int bar () const { return 45; }
  consteval virtual int baz () const { return 46; }
  int t;
};

consteval int
foo ()
{
  S s;
  T t;
  S *u = (S *) 
  T *v = 
  auto pmf1 = ::bar;
  auto pmf2 = ::baz;
  if ((s.*pmf1) () != 43) throw 1;
  if ((s.*pmf2) () != 44) throw 2;
  if ((t.*pmf1) () != 45) throw 3;
  if ((t.*pmf2) () != 46) throw 4;
  if ((u->*pmf1) () != 45) throw 5;
  if ((u->*pmf2) () != 46) throw 6;
  return 0;
}

constexpr S s;
constexpr T t;

constexpr const S *
bar (bool x)
{
  return x ?  : (const S *) 
}

int a = foo ();
int b = bar (false)->bar ();
int c = bar (true)->baz ();
static_assert (bar (false)->bar () == 45);
static_assert (bar (true)->baz () == 44);

Not sure what to do there, expand_ptrmemfunc_cst uses DECL_VINDEX which for
immediate virtual functions is negative.  It could transform those into
positive say by adding list_length (BINFO_VIRTUALS ()) to it, but during the
constexpr evaluation it isn't evaluated as some kind of OBJ_TYPE_REF, but
rather dereference of the vtable.  And, for vtable decls we don't want the
consteval methods in there, so maybe cxx_eval_constant_call would need to
figure out it is a PMF call to a consteval method and look it up in
BINFO_VIRTUALS chain rather than actually in the vtable.

Testcase for covariants, this one compiles, but fails the assertion.  It is
covariant2.C where I had to s/virtual/public/ on the D prototype, so that D's
ctor could be constexpr, so maybe it is ok it works this way.
// { dg-do compile { target c++2a } }

struct B1;
struct B2;
struct D;

struct B1
{
  virtual consteval const B1 *foo1 () const {return this;}
  consteval virtual const B2 *foo2 (const D *) const;
};
struct B2
{
  consteval virtual const B2 *baz1 () const {return this;}
  consteval virtual const B1 *baz2 (const D *) const;
};

struct D : public B1, B2
{
  virtual consteval const D *foo1 () const {return this;}
  virtual consteval const D *foo2 (const D *d) const {return d;}
  consteval virtual const D *baz1 () const {return this;}
  virtual consteval const D *baz2 (const D *d) const {return d;}
};

consteval const B2 *B1::foo2 (const D *d) const {return d;}
consteval const B1 *B2::baz2 (const D *d) const {return d;}

consteval int
test (const B1 *b1, const B2 *b2, const D *d)
{
  if (b1->foo1 () != b1)
return 1;
  if (b2->baz1 () != b2)
return 2;
  if (b1->foo2 (d) != b2)
return 3;
  if (b2->baz2 (d) != b1)
return 4;
  return 0;
}

consteval int
test (const D *d)
{
  if (d->foo2 (d) != d)
return 11;
  if (d->baz2 (d) != d)
return 12;
  if (d->foo1 () != d)
return 13;
  if (d->baz1 () != d)
return 14;
  return 0;
}

constexpr D d;
constexpr auto e = test (, , );
constexpr auto f = test ();
//static_assert (e == 0);
static_assert (f == 0);
int g = e;

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #17 from Jakub Jelinek  ---
Created attachment 47506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47506=edit
gcc10-wip-consteval-virtual.patch

I've tried to make further progress on this, and while simple testcases like
those included in the patch work, consteval pmf for consteval virtual methods
doesn't work and covariants don't work either and I'm stuck.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #16 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #15)
> Would it work to include them at the end of BINFO_VIRTUALS but omit them 
> in build_vtbl_initializer?

With my very limited understanding, I thought that for the vtables it is
important that if a base defines some virtual method that for a derived type
which either doesn't override it or overrides it the same virtual method has
the same index.  Now, if the consteval virtuals are at the end of
BINFO_VIRTUALS but indexed from the start as others, if say base has 3 normal
and 2 consteval virtual methods, 0/1/2 indexes will be the normal and 3/4 will
be the consteval ones.  If I derive a class from this, don't override the first
normal virtual method, override the second one (dtor, two entries), don't
override the first consteval method, override the second one and add one new
normal and one new consteval methods, like:
struct base {
  virtual int foo ();
  virtual ~base ();
  virtual consteval int bar () { return 42; }
  virtual consteval int baz () { return 43; }
};
struct derived : public base {
  virtual ~derived ();
  virtual consteval int baz () { return 44; }
  virtual int qux ();
  virtual consteval int quux () { return 45; }
};
what would happen with indexes in derived BINFO_VIRTUALS?  If the non-consteval
ones need to go first as that is what we emit into vtables, then qux needs to
have index 3, but doesn't bar already have that?

The only thing that comes to my mind is to use  e.g. negative indexes for the
consteval methods and count in that case from the end, i.e. foo would get
DECL_VINDEX 0, dtors DECL_VINDEX 1/2, bar DECL_VINDEX -1, baz DECL_VINDEX -2,
qux DECL_VINDEX 3 and quux DECL_VINDEX -3 and when actually looking up the
entry in BINFO_VIRTUALS, transform negative indexes into chain_length
(BINFO_VIRTUALS) + DECL_VINDEX, i.e. bar would be the last in BINFO_VIRTUALS
chain of both base and derived, baz the penultimate and quux in derived the
antepenultimate.
Thoughts on that?

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-12-12 Thread jason at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #15 from Jason Merrill  ---
On 11/28/19 12:58 PM, jakub at gcc dot gnu.org wrote:
> Now, the issues:
> 1) (so far ignored); the standard says that classes where all virtual members 
> are immediate are still polymorphic,
> but I guess for the ABI we don't want a vtable pointer there.  So, I 
> think we want TYPE_POLYMORPHIC_P set on
> those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; 
> do we want TYPE_REALLY_POLYMORPHIC_P or
> similar for polymorphic types that contain at least one non-immediate 
> virtual function and thus need a vtable?

We still need a vtable for typeinfo, so I think we don't need to worry 
about this.

> 2) initially I thought I'd just always emit a direct call to the immediate
> virtual method found by lookup and do the  remapping of that during constexpr 
> call evaluation; unfortunately as the
> v->S::bar () etc. calls show, we only want to do that if LOOKUP_NONVIRTUAL 
> wasn't set; unfortunately, when immediate
> functions aren't in the binfo structures, DECL_VINDEX is error_mark_node and 
> so I think we need some hack how to
> preserve the info that we are going to call a virtual consteval method; could 
> we e.g. abuse OBJ_TYPE_REF with
> different arguments that would make it clear it is something different, or 
> new tree?  We need to store the instance
> on which it is called and the virtual consteval method originally chosen e.g. 
> to compare the type

> 3) I'm afraid one can't use a lookup_member on the actual instance type, 
> because it could find all kinds of things,
> static member functions, typedefs, data members etc. in derived classes, 
> where we actually are only interested in
> in virtual methods.  So, shall we use something like look_for_overrides 
> does, except with the fndecl from the
> base rather than derived and of course don't do anything except return 
> the first found method (and ignore static member
> functions rather than handling them)?

Would it work to include them at the end of BINFO_VIRTUALS but omit them 
in build_vtbl_initializer?

> 4) guess covariant returns need to be handled at the end too somehow

Yep.

Jason

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-11-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #14 from Jakub Jelinek  ---
I think we should remove the __cpp_consteval define until we implement virtual
consteval and should also mention in cxx-status.html that it is only partially
implemented.

I've tried to play with the virtual consteval support, but am stuck.

First, some testcases I've been playing with:
One for diagnostics:
struct S {
  virtual int foo () { return 42; } // { dg-message "overridden
function is 'virtual consteval int S::foo\\\(\\\)'" }
  consteval virtual int bar () { return 43; }   // { dg-message "overridden
function is 'virtual consteval int S::bar\\\(\\\)'" }
};
struct T : public S {
  int bar () { return 44; } // { dg-error "non-'consteval' function
'virtual int T::bar\\\(\\\)' overriding 'consteval' function" }
};
struct U : public S {
  consteval virtual int foo () { return 45; }   // { dg-error "'consteval'
function 'virtual consteval int U::foo\\\(\\\)' overriding non-'consteval'
function" }
};
And the main one:
struct S {
  constexpr S () : s (0) {}
  virtual int foo () const { return 42; }
  consteval virtual int bar () const { return 43; }
  consteval virtual int baz () const { return 44; }
  int s;
};
struct T : public S {
  constexpr T () : t (0) {}
  consteval int bar () const { return 45; }
  consteval virtual int baz () const { return 46; }
  int t;
};
struct U : public T {
  typedef int bar;
  typedef int baz;
};

consteval int
foo ()
{
  S s;
  T t;
  U u;
  S *v = (S *) 
  S *w = (S *) 
  if (s.bar () != 43) throw 1;
  if (s.baz () != 44) throw 2;
  if (t.bar () != 45) throw 3;
  if (t.baz () != 46) throw 4;
  if (v->bar () != 45) throw 5;
  if (v->baz () != 46) throw 6;
  if (w->bar () != 45) throw 7;
  if (w->baz () != 46) throw 8;
  if (t.S::bar () != 43) throw 9;
  if (t.T::baz () != 46) throw 10;
  if (v->S::bar () != 43) throw 11;
  if (w->S::baz () != 44) throw 12;
  return 0;
}

constexpr S s;
constexpr T t;

constexpr const S *
bar (bool x)
{
  return x ?  : (const S *) 
}

int a = foo ();
int b = bar (false)->bar ();
int c = bar (true)->baz ();
static_assert (bar (false)->bar () == 45);
static_assert (bar (true)->baz () == 44);

Now, the issues:
1) (so far ignored); the standard says that classes where all virtual members
are immediate are still polymorphic,
   but I guess for the ABI we don't want a vtable pointer there.  So, I think
we want TYPE_POLYMORPHIC_P set on
   those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; do
we want TYPE_REALLY_POLYMORPHIC_P or
   similar for polymorphic types that contain at least one non-immediate
virtual function and thus need a vtable?
2) initially I thought I'd just always emit a direct call to the immediate
virtual method found by lookup and do the
   remapping of that during constexpr call evaluation; unfortunately as the
v->S::bar () etc. calls show, we only want
   to do that if LOOKUP_NONVIRTUAL wasn't set; unfortunately, when immediate
functions aren't in the binfo structures,
   DECL_VINDEX is error_mark_node and so I think we need some hack how to
preserve the info that we are going to
   call a virtual consteval method; could we e.g. abuse OBJ_TYPE_REF with
different arguments that would make it
   clear it is something different, or new tree?  We need to store the instance
on which it is called and the virtual
   consteval method originally chosen e.g. to compare the type
3) I'm afraid one can't use a lookup_member on the actual instance type,
because it could find all kinds of things,
   static member functions, typedefs, data members etc. in derived classes,
where we actually are only interested in
   in virtual methods.  So, shall we use something like look_for_overrides
does, except with the fndecl from the
   base rather than derived and of course don't do anything except return the
first found method (and ignore static member
   functions rather than handling them)?
4) guess covariant returns need to be handled at the end too somehow

Current WIP patch (though as mentioned in 2), in build_over_call we probably
just need some way note that it needs to be a virtual consteval call and
evaluate that only during constexpr evaluation):
--- gcc/cp/call.c.jj2019-11-28 09:02:26.953819534 +0100
+++ gcc/cp/call.c   2019-11-28 18:18:31.646444362 +0100
@@ -8369,6 +8369,7 @@ build_over_call (struct z_candidate *can
current_function_returns_abnormally = 1;
   if (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && !DECL_VINDEX (fn)
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
@@ -8962,7 +8963,40 @@ build_over_call (struct z_candidate *can
   && DECL_BUILT_IN_CLASS (fn) == BUILT_IN_NORMAL)
 maybe_warn_class_memaccess (input_location, fn, args);

-  if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0)
+  if 

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-11-01 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  1 23:28:20 2019
New Revision: 277733

URL: https://gcc.gnu.org/viewcvs?rev=277733=gcc=rev
Log:
PR c++/88335 - Implement P1073R3: Immediate functions
c-family/
* c-common.h (enum rid): Add RID_CONSTEVAL.
* c-common.c (c_common_reswords): Add consteval.
cp/
* cp-tree.h (struct lang_decl_fn): Add immediate_fn_p bit.
(DECL_IMMEDIATE_FUNCTION_P, SET_DECL_IMMEDIATE_FUNCTION_P): Define.
(enum cp_decl_spec): Add ds_consteval.
(fold_non_dependent_expr): Add another tree argument defaulted to
NULL_TREE.
* name-lookup.h (struct cp_binding_level): Add immediate_fn_ctx_p
member.
* parser.c (cp_keyword_starts_decl_specifier_p): Adjust comments
for C++11 and C++20 specifiers.  Handle RID_CONSTEVAL.
(CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Adjust comment.
(CP_PARSER_FLAGS_CONSTEVAL): New.
(cp_parser_skip_balanced_tokens): New forward declaration.
(cp_parser_lambda_declarator_opt): Handle ds_consteval.  Set
current_binding_level->immediate_fn_ctx_p before parsing parameter
list if decl-specifier-seq contains consteval specifier.
(cp_parser_decl_specifier_seq): Handle RID_CONSTEVAL.
(cp_parser_explicit_instantiation): Diagnose explicit instantiation
with consteval specifier.
(cp_parser_init_declarator): For consteval or into flags
CP_PARSER_FLAGS_CONSTEVAL.
(cp_parser_direct_declarator): If CP_PARSER_FLAGS_CONSTEVAL, set
current_binding_level->immediate_fn_ctx_p in the sk_function_parms
scope.
(set_and_check_decl_spec_loc): Add consteval entry, formatting fix.
* call.c (build_addr_func): For direct calls to immediate functions
use build_address rather than decay_conversion.
(build_over_call): Evaluate immediate function invocations.
* error.c (dump_function_decl): Handle DECL_IMMEDIATE_FUNCTION_P.
* semantics.c (expand_or_defer_fn_1): Use tentative linkage and don't
call mark_needed for immediate functions.
* typeck.c (cxx_sizeof_or_alignof_expr): Likewise.  Formatting fix.
(cp_build_addr_expr_1): Reject taking address of immediate function
outside of immediate function.
* decl.c (validate_constexpr_redeclaration): Diagnose consteval
vs. non-consteval or vice versa redeclaration.  Use
SET_DECL_IMMEDIATE_FUNCTION_P if new_decl is immediate function.
(check_tag_decl): Use %qs with keyword string to simplify translation.
Handle ds_consteval.
(start_decl): Adjust diagnostics for static or thread_local variables
in immediate functions.
(grokfndecl): Call sorry_at on virtual consteval.  Use %qs with keyword
to string to simplify translation.  Diagnose consteval main.  Use
SET_DECL_IMMEDIATE_FUNCTION_P for consteval.
(grokdeclarator): Handle consteval.  Use %qs with keyword strings to
simplify translation.  Use separate ifs instead of chained else if
for invalid specifiers.  For constinit clear constinit_p rather than
constexpr_p.
* constexpr.c (find_immediate_fndecl): New function.
(cxx_eval_outermost_constant_expr): Allow consteval calls returning
void.  Diagnose returning address of immediate function from consteval
evaluation.
(fold_non_dependent_expr_template): Add OBJECT argument, pass it
through to cxx_eval_outermost_constant_expr.
(fold_non_dependent_expr): Add OBJECT argument, pass it through to
fold_non_dependent_expr_template.
(fold_non_dependent_init): Adjust fold_non_dependent_expr_template
caller.
* method.c (defaulted_late_check): Adjust diagnostics for consteval.
* lambda.c (maybe_add_lambda_conv_op): Copy over
DECL_DECLARED_CONSTEXPR_P and DECL_IMMEDIATE_FUNCTION_P bits from
callop to both artificial functions.
* init.c (build_value_init): Don't do further processing if
build_special_member_call returned a TREE_CONSTANT.  Formatting fix.
testsuite/
* g++.dg/cpp2a/consteval1.C: New test.
* g++.dg/cpp2a/consteval2.C: New test.
* g++.dg/cpp2a/consteval3.C: New test.
* g++.dg/cpp2a/consteval4.C: New test.
* g++.dg/cpp2a/consteval5.C: New test.
* g++.dg/cpp2a/consteval6.C: New test.
* g++.dg/cpp2a/consteval7.C: New test.
* g++.dg/cpp2a/consteval8.C: New test.
* g++.dg/cpp2a/consteval9.C: New test.
* g++.dg/cpp2a/consteval10.C: New test.
* g++.dg/cpp2a/consteval11.C: New test.
* g++.dg/cpp2a/consteval12.C: New test.
* g++.dg/cpp2a/consteval13.C: New test.
* g++.dg/cpp2a/consteval14.C: New test.
* g++.dg/ext/consteval1.C: New test.

Added:

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #47032|0   |1
is obsolete||
  Attachment #47042|0   |1
is obsolete||

--- Comment #12 from Jakub Jelinek  ---
Created attachment 47094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47094=edit
gcc10-pr88335.patch

Just for the record, this is a variant of the patch that has testsuite coverage
for immediate function calls in discarded statements (at least how I believe it
should work), still using the cxx_eval_consteval rather than using again
build_cxx_call.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #11 from Jakub Jelinek  ---
Created attachment 47042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47042=edit
gcc10-pr88335.patch

Untested patch.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #47031|0   |1
is obsolete||

--- Comment #10 from Jakub Jelinek  ---
Created attachment 47032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47032=edit
gcc10-pr88335-wip.patch

Small improvements and one bugfix.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46429|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 47031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47031=edit
gcc10-pr88335-wip.patch

As the first step, here is the previous patch updated so that it applies to
current trunk (various changes due to constinit etc.), no further functional
changes so far.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #8 from Marek Polacek  ---
Work has been restarted, we should have this feature fairly soon.  Certainly
the plan is to have it in GCC 10.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-10-14 Thread lutztonineubert at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Toni Neubert  changed:

   What|Removed |Added

 CC||lutztonineubert at gmail dot 
com

--- Comment #7 from Toni Neubert  ---
Any progress on this? How can we help?

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #6 from Jakub Jelinek  ---
The above patch:
1) adds sorry_at for virtual consteval, that is quite a lot of work
2) still doesn't handle ctors properly (perhaps sorry_at too)?
3) fixes the testcase from the paper with decltype containing call to void
returning consteval fn
4) adds diagnostics for immediate invocation returning address of some
immediate function
Unfortunately 4) breaks consteval2.C testcase, my reading of the spec is we
should treat default arguments of immediate functions as in immediate function
context and not evaluate immediately, but current_function_decl at that point
doesn't indicate we are in immediate function context, and I guess we don't
even have such a decl.  Jason, any thoughts on that?

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46390|0   |1
is obsolete||

--- Comment #5 from Jakub Jelinek  ---
Created attachment 46429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46429=edit
gcc10-pr88335-wip.patch

Slightly updated patch.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-21 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #4 from Jakub Jelinek  ---
Not working on this anymore.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-21 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46388|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46390=edit
gcc10-pr88335-wip.patch

Updated patch.  This one tries to evaluate immediate function calls immediately
in build_over_call, adds some testsuite coverage etc.
What still doesn't work is:
1) consteval constructors, I think evaluating those in build_over_call is too
early, we need a TARGET_EXPR for them or something similar that supplies to the
constexpr evaluation the object that is being initialized; so, where should we
do that and should we do that that way only for ctors, or everything?
2) the example added to the end of [expr.const] doesn't work - we have in
cxx_eval_outermost_constant_expr:
  if (VOID_TYPE_P (type))
return t;
early exit.  Is that something that is correct for anything?  I mean, aren't we
supposed to evaluate the constexpr (and consteval) functions anyway?
constexpr void foo (bool x) { if (x) throw 1; }
constexpr int a = (foo (false), 1);
constexpr int b = (foo (true), 2);
is handled correctly though, because in that case the void type expressions are
the outermost ones.  Perhaps we should do this early exit only if the
expression isn't a call to an immediate function?
3) consteval virtual members not handled at all, and I'm afraid that is out of
my area of expertise

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-20 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Jason, thoughts on this?

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-20 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46388=edit
gcc10-pr88335.patch

Untested WIP patch.  Need to decide now from where exactly to call the
immediate functions when not in immediate function contexts, shall that be done
say from build_call_a/build_over_call once the expression is built and if
nothing in the expression is dependent, or shall it be done say only from
cp_fold?  The latter seems better conceptually (that we don't fold stuff too
early), but might need to handle it also in various unevaluated codepaths.
Also, I guess if during !ctx->manifestly_const_eval constexpr evaluation we
encounter immediate function call, we need to evaluate the call separately in a
manifestly_const_eval mode and only then return back to the normal constexpr
evaluation.
Some work will need to be done to make sure we don't hand over immediate
functions to the middle-end, another question is what to do about virtual
immediate functions, for the constexpr evaluations we want to see them in
whatever data structures we have for virtual tables, but what we later hand
over to the middle-end and emit should not include those, what shall we do with
classes that don't have any virtual members other than immediate functions,
etc.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

2019-05-20 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-20
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1