[v5] c++: implement P2564, consteval needs to propagate up [PR107687]

On Mon, Nov 13, 2023 at 09:06:09PM -0500, Jason Merrill wrote:
> On 11/6/23 17:34, Marek Polacek wrote:
> > On Fri, Nov 03, 2023 at 01:51:07PM -0400, Jason Merrill wrote:
> > > On 11/2/23 11:28, Marek Polacek wrote:
> > > > On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
> > > > > On 10/10/23 13:20, Marek Polacek wrote:
> > > > > > I suppose some
> > > > > > functions cannot possibly be promoted because they don't contain
> > > > > > any CALL_EXPRs.  So we may be able to rule them out while doing
> > > > > > cp_fold_r early.
> > > > > 
> > > > > Yes.  Or, the only immediate-escalating functions referenced have already
> > > > > been checked.
> > > 
> > > It looks like you haven't pursued this yet?  One implementation thought:
> > 
> > Oops, I'd forgotten to address that.
> > 
> > > maybe_store_cfun... could stop skipping immediate_escalating_function_p
> > > (current_function_decl), and after we're done folding if the current
> > > function isn't in the hash_set we can go ahead and set
> > > DECL_ESCALATION_CHECKED_P?
> > 
> > Clever, I see what you mean.  IOW, we store c_f_d iff the function contains
> > an i-e expr.  If not, it can't possibly become consteval.  I've added that
> > into cp_fold_function, and it seems to work well...
> > 
> > ...except it revealed a different problem: cp_fold_r -> cp_fold will, since
> > https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443993.html, remove
> > UNARY_PLUS_EXPR, leading us into this problem:
> > 
> >    // stmt = +id(i)
> >    cp_fold (...);
> >    // stmt = id(i)
> > 
> > and the subsequent tree walk walks the CALL_EXPR's operands, so
> > cp_fold_immediate_r will never see the CALL_EXPR, so we miss an i-e expr.
> > 
> > Perhaps a better solution than the kludge I added would be to only call
> > cp_fold_immediate_r after cp_fold.  Or potentially before /and/ after if
> > cp_fold changes the expression?
> 
> Or walk everything with cp_fold_immediate_r before walking again with
> cp_fold_r?

Maybe, but I might run into complexity issues again unless I add a new
pset into cp_fold_data.  I did something else: only re-run
cp_fold_immediate_r if cp_fold turned an expression into a CALL_EXPR.

> > > > > It also seems odd that the ADDR_EXPR case calls vec_safe_push
> > > > > (deferred_escalating_exprs, while the CALL_EXPR case calls
> > > > > maybe_store_cfun_for_late_checking, why the different handling?
> > > > 
> > > > maybe_store_cfun_for_late_checking saves current_function_decl
> > > > so that we can check:
> > > > 
> > > > void g (int i) {
> > > >     fn (i); // error if fn promotes to consteval
> > > > }
> > > 
> > > Yes, but why don't we want the same handling for ADDR_EXPR?
> > 
> > The handling can't be exactly the same due to global vars like
> > 
> >    auto p1 = &f5<int>;
> > 
> > ...but it's wrong to only save the ADDR_EXPR if it's enclosed in
> > a function, because the ADDR_EXPR could be inside a consteval if
> > block, in which case I think we're not supposed to error.  Tested
> > in consteval-prop20.C.  Thanks,
> 
> And we don't need the !current_function_decl handling for CALL_EXPR?

I don't think so: we should see the call when cp_fold_function gets to
__static_i_and_d.  I added a comment.

> The only significant difference I see between &f and f() for escalation is
> that the latter might be an immediate invocation.  Once we've determined
> that it's not, so we are in fact looking at an immediate-escalating
> expression, I'd expect the promotion handling to be identical.

I'm not certain if I understand the immediate invocation remark but in
v5 I've tried to unify both as much as possible.

> > +  /* Whether cp_fold_immediate_r is looking for immediate-escalating
> > +     expressions.  */
> 
> Isn't that always what it's doing?
> 
> The uses of ff_escalating in maybe_explain_promoted_consteval and
> maybe_escalate_decl_and_cfun seem to have different purposes that I'm having
> trouble following.
> 
> For the former, it seems to control returning the offending expression
> rather than error_mark_node.  Why don't we always do that?
> 
> For the latter, it seems to control recursion, which seems redundant with
> the recursion in that latter function itself.  And the use of the flag seems
> redundant with at_eof.

You're absolutely correct, the code was a knotty mess.  In v5, I tried to
untangle it to make it something more straightforward.

I still need a new ff_ flag to signal that we can return immediately
after seeing an i-e expr.

> > +/* Remember that the current function declaration contains a call to
> > +   a function that might be promoted to consteval later.  */
> > +
> > +static void
> > +maybe_store_cfun_for_late_checking ()
> 
> This name could say more about escalation?  Maybe
> ...for_escalation_checking?
> 
> Or, better, merge this with maybe_store_immediate_escalating_fn?

I got rid of the former function.

> > +/* Figure out if DECL should be promoted to consteval and if so, maybe also
> > +   promote the function we are in currently.  CALL is the CALL_EXPR of DECL.
> > +   EVALP is where we may store the result of cxx_constant_value so that we
> > +   don't have to evaluate the same tree again in cp_fold_immediate_r.  */
> > +
> > +static void
> > +maybe_escalate_decl_and_cfun (tree decl, tree call, tree *evalp)
> > +{
> > +  if (cp_unevaluated_operand)
> > +    return;
> > +
> > +  /* What we're calling is not a consteval function but it may become
> > +     one.  This requires recursing; DECL may be promoted to consteval
> > +     because it contains an escalating expression E, but E itself may
> > +     have to be promoted first, etc.  */
> > +  if (unchecked_immediate_escalating_function_p (decl))
> > +    {
> > +      cp_fold_data data (ff_escalating, decl);
> > +      cp_walk_tree (&DECL_SAVED_TREE (decl), cp_fold_immediate_r,
> > +		    &data, nullptr);
> > +      DECL_ESCALATION_CHECKED_P (decl) = true;
> 
> Why recurse both here and in cp_fold_immediate_r?

Gone now.

> > +    }
> > +
> > +  /* In turn, maybe promote the function we find ourselves in...  */
> > +  if (DECL_IMMEDIATE_FUNCTION_P (decl)
> > +      /* ...but not if the call to DECL was constant; that is the
> > +	 "an immediate invocation that is not a constant expression"
> > +	 case.  We do this here and not in cp_fold_immediate_r,
> > +	 because DECL could have already been consteval and we'd
> > +	 never call cp_fold_immediate_r.  */
> > +      && (*evalp = cxx_constant_value (call, tf_none),
> > +	  *evalp == error_mark_node))
> 
> Why check this both here and immediately after the call in
> cp_fold_immediate_r?

This should no longer happen.

> > +escalate:
> > +  /* Not consteval yet, but could be.  Have to look deeper.  */
> > +  if (unchecked_immediate_escalating_function_p (decl))
> > +    {
> > +      /* Set before the actual walk to avoid endless recursion.  */
> > +      DECL_ESCALATION_CHECKED_P (decl) = true;
> > +      cp_fold_data d (ff_escalating, data->caller ? decl : NULL_TREE);
> 
> It seems like the "caller" field is in place of setting
> current_function_decl to decl while walking its trees.  Some other places
> instead override current_function_decl and call cp_fold_immediate.  Can we
> unify on the latter pattern, and factor it into a separate function?

Done -- see find_escalating_expr.

> > +      cp_walk_tree (&DECL_SAVED_TREE (decl), cp_fold_immediate_r, &d, nullptr);
> > +    }
> > +
> > +  /* If it turned out to be consteval, maybe promote the caller.  */
> > +  if (DECL_IMMEDIATE_FUNCTION_P (decl)
> > +      && (!call || cxx_constant_value (call, tf_none) == error_mark_node))
> > +    {
> > +      /* We found the escalating expression.  */
> > +      if (data->caller)
> > +	promote_function_to_consteval (data->caller);
> > +      *walk_subtrees = 0;
> > +      return stmt;
> > +    }
> 
> Why different promotion code depending on whether we're recursing?

Gone now, and hopefully less unwieldy.

> > +/* We've stashed immediate-escalating functions.  Now see if they indeed
> > +   ought to be promoted to consteval.  */
> > +
> > +void
> > +process_pending_immediate_escalating_fns ()
> > +{
> > +  /* This will be null for -fno-immediate-escalation.  */
> > +  if (!deferred_escalating_exprs)
> > +    return;
> > +
> > +  for (auto e : *deferred_escalating_exprs)
> > +    if (TREE_CODE (e) == FUNCTION_DECL)
> > +      {
> > +	if (!DECL_ESCALATION_CHECKED_P (e))
> > +	  {
> > +	    temp_override<tree> cfd (current_function_decl, e);
> > +	    cp_fold_immediate (&DECL_SAVED_TREE (e), mce_false);
> > +	  }
> > +	if (DECL_IMMEDIATE_FUNCTION_P (e))
> > +	  deferred_escalating_exprs->remove (e);
> > +      }
> > +}
> > +
> > +/* We've escalated every function that could have been promoted to
> > +   consteval.  Check that we are not taking the address of a consteval
> > +   function.  */
> > +
> > +void
> > +check_immediate_escalating_refs ()
> > +{
> > +  /* This will be null for -fno-immediate-escalation.  */
> > +  if (!deferred_escalating_exprs)
> > +    return;
> > +
> > +  for (auto ref : *deferred_escalating_exprs)
> > +    {
> > +      if (TREE_CODE (ref) == FUNCTION_DECL)
> > +	/* We saw a function call to an immediate-escalating function in
> > +	   the body of REF.  Check that it's a constant if it was promoted
> > +	   to consteval.  */
> > +	{
> > +	  temp_override<tree> cfd (current_function_decl, ref);
> > +	  cp_fold_immediate (&DECL_SAVED_TREE (ref), mce_false);
> 
> Shouldn't we skip functions here since we just processed them in the
> function above?

I think so.  Done.

Thanks a lot.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
This patch implements P2564, described at <wg21.link/p2564>, whereby
certain functions are promoted to consteval.  For example:

  consteval int id(int i) { return i; }

  template <typename T>
  constexpr int f(T t)
  {
    return t + id(t); // id causes f<int> to be promoted to consteval
  }

  void g(int i)
  {
    f (3);
  }

now compiles.  Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression.  Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval
functions composition.  But making 'f<int>' consteval also means that
the call to 'f' in 'g' must yield a constant; failure to do so results
in an error.  I made the effort to have cc1plus explain to us what's
going on.  For example, calling f(i) produces this neat diagnostic:

w.C:11:11: error: call to consteval function 'f<int>(i)' is not a constant expression
   11 |         f (i);
      |         ~~^~~
w.C:11:11: error: 'i' is not a constant expression
w.C:6:22: note: 'constexpr int f(T) [with T = int]' was promoted to an immediate function because its body contains an immediate-escalating expression 'id(t)'
    6 |         return t + id(t); // id causes f<int> to be promoted to consteval
      |                    ~~^~~

which hopefully makes it clear what's going on.

Implementing this proposal has been tricky.  One problem was delayed
instantiation: instantiating a function can set off a domino effect
where one call promotes a function to consteval but that then means
that another function should also be promoted, etc.

In v1, I addressed the delayed instantiation problem by instantiating
trees early, so that we can escalate functions right away.  That caused
a number of problems, and in certain cases, like consteval-prop3.C, it
can't work, because we need to wait till EOF to see the definition of
the function anyway.  Overeager instantiation tends to cause diagnostic
problems too.

In v2, I attempted to move the escalation to the gimplifier, at which
point all templates have been instantiated.  That attempt flopped,
however, because once we've gimplified a function, its body is discarded
and as a consequence, you can no longer evaluate a call to that function
which is required for escalating, which needs to decide if a call is
a constant expression or not.

Therefore, we have to perform the escalation before gimplifying, but
after instantiate_pending_templates.  That's not easy because we have
no way to walk all the trees.  In the v2 patch, I use two vectors: one
to store function decls that may become consteval, and another to
remember references to immediate-escalating functions.  Unfortunately
the latter must also stash functions that call immediate-escalating
functions.  Consider:

  int g(int i)
  {
    f<int>(i); // f is immediate-escalating
  }

where g itself is not immediate-escalating, but we have to make sure
that if f gets promoted to consteval, we give an error.

A new option, -fno-immediate-escalation, is provided to suppress
escalating functions.

v2 also adds a new flag, DECL_ESCALATION_CHECKED_P, so that we don't
escalate a function multiple times, and so that we can distinguish between
explicitly consteval functions and functions that have been promoted
to consteval.

In v3, I removed one of the new vectors and changed the other one
to a hash set.  This version also contains numerous cleanups.

v4 merges find_escalating_expr_r into cp_fold_immediate_r.  It also
adds a new optimization in cp_fold_function.

v5 greatly simplifies the code.

	PR c++/107687
	PR c++/110997

gcc/c-family/ChangeLog:

	* c-cppbuiltin.cc (c_cpp_builtins): Update __cpp_consteval.
	* c-opts.cc (c_common_post_options): Pre-C++20, unset
	flag_immediate_escalation.
	* c.opt (fimmediate-escalation): New option.

gcc/cp/ChangeLog:

	* call.cc (in_immediate_context): No longer static.
	* constexpr.cc (cxx_eval_call_expression): Adjust assert.
	* cp-gimplify.cc (deferred_escalating_exprs): New vec.
	(remember_escalating_expr): New.
	(enum fold_flags): Rename ff_fold_immediate to ff_find_escalating_expr.
	(immediate_escalating_function_p): New.
	(unchecked_immediate_escalating_function_p): New.
	(promote_function_to_consteval): New.
	(maybe_promote_function_to_consteval): New.
	(cp_fold_immediate): Move above.  Return true if any errors were
	emitted.
	(find_escalating_expr): New.
	(maybe_explain_promoted_consteval): New.
	(cp_gimplify_expr) <case CALL_EXPR>: Assert we've handled all
	immediate invocations.
	(taking_address_of_imm_fn_error): New.
	(cp_fold_immediate_r): Merge ADDR_EXPR and PTRMEM_CST cases.  Implement
	P2564 - promoting functions to consteval.
	<case CALL_EXPR>: Implement P2564 - promoting functions to consteval.
	(cp_fold_r): If an expression turns into a CALL_EXPR after cp_fold,
	call cp_fold_immediate_r on the CALL_EXPR.
	(cp_fold_function): Set DECL_ESCALATION_CHECKED_P if
	deferred_escalating_exprs does not contain current_function_decl.
	(maybe_store_immediate_escalating_fn): New.
	(process_pending_immediate_escalating_fns): New.
	(check_immediate_escalating_refs): New.
	* cp-tree.h (struct lang_decl_fn): Add escalated_p bit-field.
	(DECL_ESCALATION_CHECKED_P): New.
	(immediate_invocation_p): Declare.
	(check_immediate_escalating_refs): Likewise.
	(maybe_store_immediate_escalating_fn): Likewise.
	(process_pending_immediate_escalating_fns): Likewise.
	* decl.cc (finish_function): Call maybe_store_immediate_escalating_fn.
	* decl2.cc (c_parse_final_cleanups): Set at_eof to 2 after all
	templates have been instantiated; and to 3 at the end of the function.
	Call process_pending_immediate_escalating_fns and
	check_immediate_escalating_refs.
	* error.cc (dump_template_bindings): Check at_eof against an updated
	value.
	* module.cc (trees_out::lang_decl_bools): Stream escalated_p.
	(trees_in::lang_decl_bools): Likewise.
	* pt.cc (push_tinst_level_loc): Set at_eof to 3, not 2.
	* typeck.cc (cp_build_addr_expr_1): Don't check
	DECL_IMMEDIATE_FUNCTION_P.

gcc/ChangeLog:

	* doc/invoke.texi: Document -fno-immediate-escalation.

libstdc++-v3/ChangeLog:

	* testsuite/18_support/comparisons/categories/zero_neg.cc: Add
	dg-prune-output.
	* testsuite/std/format/string_neg.cc: Add dg-error.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/consteval-if10.C: Remove dg-error.
	* g++.dg/cpp23/consteval-if2.C: Likewise.
	* g++.dg/cpp23/feat-cxx2b.C: Adjust expected value of __cpp_consteval.
	* g++.dg/cpp26/feat-cxx26.C: Likewise.
	* g++.dg/cpp2a/consteval-memfn1.C: Add dg-error.
	* g++.dg/cpp2a/consteval11.C: Likewise.
	* g++.dg/cpp2a/consteval3.C: Adjust dg-error.
	* g++.dg/cpp2a/consteval34.C: Add dg-error.
	* g++.dg/cpp2a/consteval9.C: Likewise.
	* g++.dg/cpp2a/feat-cxx2a.C: Adjust expected value of __cpp_consteval.
	* g++.dg/cpp2a/spaceship-synth9.C: Adjust dg-error.
	* g++.dg/cpp2a/consteval-prop1.C: New test.
	* g++.dg/cpp2a/consteval-prop10.C: New test.
	* g++.dg/cpp2a/consteval-prop11.C: New test.
	* g++.dg/cpp2a/consteval-prop12.C: New test.
	* g++.dg/cpp2a/consteval-prop13.C: New test.
	* g++.dg/cpp2a/consteval-prop14.C: New test.
	* g++.dg/cpp2a/consteval-prop15.C: New test.
	* g++.dg/cpp2a/consteval-prop16.C: New test.
	* g++.dg/cpp2a/consteval-prop17.C: New test.
	* g++.dg/cpp2a/consteval-prop18.C: New test.
	* g++.dg/cpp2a/consteval-prop19.C: New test.
	* g++.dg/cpp2a/consteval-prop20.C: New test.
	* g++.dg/cpp2a/consteval-prop2.C: New test.
	* g++.dg/cpp2a/consteval-prop3.C: New test.
	* g++.dg/cpp2a/consteval-prop4.C: New test.
	* g++.dg/cpp2a/consteval-prop5.C: New test.
	* g++.dg/cpp2a/consteval-prop6.C: New test.
	* g++.dg/cpp2a/consteval-prop7.C: New test.
	* g++.dg/cpp2a/consteval-prop8.C: New test.
	* g++.dg/cpp2a/consteval-prop9.C: New test.
---
 gcc/c-family/c-cppbuiltin.cc                  |   2 +-
 gcc/c-family/c-opts.cc                        |   5 +
 gcc/c-family/c.opt                            |   4 +
 gcc/cp/call.cc                                |   2 +-
 gcc/cp/constexpr.cc                           |   4 +-
 gcc/cp/cp-gimplify.cc                         | 409 +++++++++++++++---
 gcc/cp/cp-tree.h                              |  21 +-
 gcc/cp/decl.cc                                |   5 +-
 gcc/cp/decl2.cc                               |  20 +-
 gcc/cp/error.cc                               |   2 +-
 gcc/cp/module.cc                              |   4 +
 gcc/cp/pt.cc                                  |   2 +-
 gcc/cp/typeck.cc                              |   6 +-
 gcc/doc/invoke.texi                           |  34 ++
 gcc/testsuite/g++.dg/cpp23/consteval-if10.C   |   7 +-
 gcc/testsuite/g++.dg/cpp23/consteval-if2.C    |  14 +-
 gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C       |   4 +-
 gcc/testsuite/g++.dg/cpp26/feat-cxx26.C       |   4 +-
 gcc/testsuite/g++.dg/cpp2a/consteval-memfn1.C |   3 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop1.C  | 169 ++++++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop10.C |  41 ++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop11.C |  49 +++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop12.C |  30 ++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop13.C |  23 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop14.C |  78 ++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop15.C | 107 +++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop16.C |  73 ++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop17.C |  17 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop18.C |  20 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop19.C |   7 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop2.C  |  90 ++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop20.C |  21 +
 gcc/testsuite/g++.dg/cpp2a/consteval-prop3.C  |  27 ++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop4.C  |  30 ++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop5.C  |  27 ++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C  |  59 +++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop7.C  |  76 ++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop8.C  |  82 ++++
 gcc/testsuite/g++.dg/cpp2a/consteval-prop9.C  |  67 +++
 gcc/testsuite/g++.dg/cpp2a/consteval11.C      |  18 +
 gcc/testsuite/g++.dg/cpp2a/consteval3.C       |   4 +-
 gcc/testsuite/g++.dg/cpp2a/consteval34.C      |   8 +
 gcc/testsuite/g++.dg/cpp2a/consteval36.C      |  26 +-
 gcc/testsuite/g++.dg/cpp2a/consteval9.C       |   2 +
 gcc/testsuite/g++.dg/cpp2a/feat-cxx2a.C       |   4 +-
 gcc/testsuite/g++.dg/cpp2a/spaceship-synth9.C |   2 +-
 .../comparisons/categories/zero_neg.cc        |   1 +
 .../testsuite/std/format/string_neg.cc        |   2 +-
 48 files changed, 1596 insertions(+), 116 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop10.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop11.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop12.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop13.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop14.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop15.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop16.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop17.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop19.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop20.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop3.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop4.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop5.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop7.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop8.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop9.C

base-commit: b9dbdefac626ba20222ca534b58f7e493d713b9a

Message ID	ZV+B5aYQheJ347xT@redhat.com
State	New
Headers	show Return-Path: <gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=f6ZxHyOM; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4SbkYT5gLBz1yRg for <incoming@patchwork.ozlabs.org>; Fri, 24 Nov 2023 03:47:25 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5D6F2384F498 for <incoming@patchwork.ozlabs.org>; Thu, 23 Nov 2023 16:47:22 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id A6DA43858D33 for <gcc-patches@gcc.gnu.org>; Thu, 23 Nov 2023 16:46:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A6DA43858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A6DA43858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700758011; cv=none; b=ldEWTB7V1B0/otcCv2SZkiZP/rZ0rJ/b9CpIIqDWFolsT3/+HntmGGTK9Ticd1WyeJLUI3VSb4koycQuuSeeD9eBqhjP7NOqrbBnZsxlm3NdqKTpdiULaJ70B5McPBE7p2j7BSFK9ve/fNd2iJoSgxWkyaNYA3EvDaGQAjd5fEQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700758011; c=relaxed/simple; bh=0f3yn1sbZ1TPoAZbrb9VgacVwv+sOgY9Hi8xI3FJsRg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=OsCQVfMTKknwlLtX3GhZy4Af9RHAf8aBLvKig/yoSqzRzJcvgNFEx7YNHH1YBqakbVfVbsWJs/CQQ1NvzZkyVuAp/6IrM2nm+CLdj+ZkvgZW0Nti55ldix+tq+AwqDzTHZ8AbeDpOamRPgh4twSWGAh9XvHRbJAIPzaGaw3jKig= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700758000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rs4Rs3+gkp+N8tCqoWQMXA/ZBvikSTSou+KzXIcU3W0=; b=f6ZxHyOMuGGWV1Gdqc4Fqlt0XGjEsh0/e6LjZBdS8MOUnrNePw9J48XFjY0sLzSix8Klxe A1UX/fVK9yZ2tdeK730Yr3XD6A0jod3ayLZCLdlCHHEEOiO4Z/wErHHG9BJnw/CjFPcULE ezaF6KMGv0TKbH6/HJU1RoxZ8p7pc7g= Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-290-Dtu6glUgOJSU1EfYVT-3ng-1; Thu, 23 Nov 2023 11:46:36 -0500 X-MC-Unique: Dtu6glUgOJSU1EfYVT-3ng-1 Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-6d646f61253so1007798a34.0 for <gcc-patches@gcc.gnu.org>; Thu, 23 Nov 2023 08:46:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700757995; x=1701362795; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cab1M8DiNyZoqe+pHB4kJBx5OWQQgkWj1dOUHj0L1cg=; b=G91hgiB+Z6BjVnYbtEfnC1dX75Pf+eTluzWpke5ZzbMxWkUdo/iiHwDplw2ugE0SGp YofvSh73+LwlrXQOFaeqX/qXmp7VbQ9S/5T6Tr1QeyxtoLMdu40gAfjIpIe4O99JRAw2 C7W1mGIF7ysgDwWz3FtWqafmAb1vhxQv7XFhy9/mh693kO5mkKgkCNgEYJ9OHXHxRL/H 0IKs4YRsDNKgq++aJWi692ghVWaKFAWmyKl0L+UmS2zSqcNBhs7wuK0rVeZLsU7ibT2R 4EDL38Z6N1g2eVdAS6Rq0CJo41DRn5Rrk863AtXpQfPZibsZjwVcNijEqpR1OMsxxxQp FLdQ== X-Gm-Message-State: AOJu0YyhPlEACaXJABEgd+vsM8VGgETuPv0C6AhEgz9eQg8JowQXpD12 YvPrONI+RWnFAYIgoo0mGhydqoGIkmEi3yewOJLsBRKEvcubzJLnS0t3ia/aRAHJvG7hYbzgQO1 TqZGCRVEyrzIReXcTAynVtWf3eQ== X-Received: by 2002:a9d:6181:0:b0:6b9:146a:f1c9 with SMTP id g1-20020a9d6181000000b006b9146af1c9mr133847otk.0.1700757993541; Thu, 23 Nov 2023 08:46:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IF0QaynRfVSaADoTr0v86TevmZ/rmjrFfxkC7jBq6qxdQGAbk830to3g0shy9vmptE49ygRfw== X-Received: by 2002:a9d:6181:0:b0:6b9:146a:f1c9 with SMTP id g1-20020a9d6181000000b006b9146af1c9mr133797otk.0.1700757992450; Thu, 23 Nov 2023 08:46:32 -0800 (PST) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id b1-20020a0c9b01000000b00679dad5b3f7sm648294qve.84.2023.11.23.08.46.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 08:46:31 -0800 (PST) Date: Thu, 23 Nov 2023 11:46:29 -0500 From: Marek Polacek <polacek@redhat.com> To: Jason Merrill <jason@redhat.com> Cc: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH v5] c++: implement P2564, consteval needs to propagate up [PR107687] Message-ID: <ZV+B5aYQheJ347xT@redhat.com> References: <20230823194904.1925591-1-polacek@redhat.com> <974dbde5-e1d8-90dc-a023-df214883403c@redhat.com> <ZSWHycEfs6r1Wvki@redhat.com> <462dd81b-cfb2-4066-bca4-403335147f5d@redhat.com> <ZUPAK/ZeelV4yAIa@redhat.com> <a0e8f057-99b1-4306-8772-553c1c4d9c9f@redhat.com> <ZUlp93ZwnARyoEia@redhat.com> <6a3303b5-85b3-4d8f-a4e3-4f41455ec6d1@redhat.com> MIME-Version: 1.0 In-Reply-To: <6a3303b5-85b3-4d8f-a4e3-4f41455ec6d1@redhat.com> User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-20.4 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_WEB, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org
Series	[v5] c++: implement P2564, consteval needs to propagate up [PR107687] \| expand [v5] c++: implement P2564, consteval needs to propagate up [PR107687]

[v5] c++: implement P2564, consteval needs to propagate up [PR107687]

Commit Message

Comments

Patch