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

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:
> > > > On Tue, Aug 29, 2023 at 03:26:46PM -0400, Jason Merrill wrote:
> > > > > On 8/23/23 15:49, Marek Polacek wrote:
> > > > > > +struct A {
> > > > > > +  int x;
> > > > > > +  int y = id(x);
> > > > > > +};
> > > > > > +
> > > > > > +template<class T>
> > > > > > +constexpr int k(int) {          // k<int> is not an immediate function because A(42) is a
> > > > > > +  return A(42).y;               // constant expression and thus not immediate-escalating
> > > > > > +}
> > > > > 
> > > > > Needs use(s) of k to test the comment.
> > > > 
> > > > True, and that revealed what I think is a bug in the standard.
> > > > In the test I'm saying:
> > > > 
> > > > // ??? [expr.const]#example-9 says:
> > > > //   k<int> is not an immediate function because A(42) is a
> > > > //   constant expression and thus not immediate-escalating
> > > > // But I think the call to id(x) is *not* a constant expression and thus
> > > > // it is an immediate-escalating expression.  Therefore k<int> *is*
> > > > // an immediate function.  So we get the error below.  clang++ agrees.
> > > > id(x) is not a constant expression because x isn't constant.
> > > 
> > > Not when considering id(x) by itself, but in the evaluation of A(42), the
> > > member x has just been initialized to constant 42.  And A(42) is
> > > constant-evaluated because "An aggregate initialization is an immediate
> > > invocation if it evaluates a default member initializer that has a
> > > subexpression that is an immediate-escalating expression."
> > > 
> > > I assume clang doesn't handle this passage properly yet because it was added
> > > during core review of the paper, for parity between aggregate initialization
> > > and constructor escalation.
> > > 
> > > This can be a follow-up patch.
> > 
> > I see.  So the fix will be to, for the aggregate initialization case, pass
> > the whole A(42).y thing to cxx_constant_eval, not just id(x).
> 
> Well, A(42) is the immediate invocation, the .y is not part of it.

Ah right, like the comment above says.

> > > > 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?

> > > We can also do some escalation during constexpr evaluation: all the
> > > functions involved need to be instantiated for the evaluation, and if we
> > > encounter an immediate-escalating expression while evaluating a call to an
> > > immediate-escalating function, we can promote it then.  Though we can't
> > > necessarily mark it as not needing promotion, as there might be i-e exprs in
> > > branches that the particular evaluation doesn't take.
> > 
> > I've tried but I didn't get anywhere.  The patch was basically
> > 
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -2983,7 +2983,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t,
> >     } fb (new_call.bindings);
> > 
> >     if (*non_constant_p)
> > -    return t;
> > +    {
> > +      if (cxx_dialect >= cxx20
> > +	  && ctx->manifestly_const_eval == mce_false
> > +	  && DECL_IMMEDIATE_FUNCTION_P (fun))
> > +	maybe_promote_function_to_consteval (current_function_decl);
> > +      return t;
> > +    }
> > 
> >     /* We can't defer instantiating the function any longer.  */
> >     if (!DECL_INITIAL (fun)
> > 
> > but since I have to check mce_false, it didn't do anything useful
> > in practice (that is, it wouldn't escalate anything in my tests).
> 
> Makes sense.
> 
> > > > @@ -55,6 +64,8 @@ enum fold_flags {
> > > >      ff_mce_false = 1 << 1,
> > > >      /* Whether we're being called from cp_fold_immediate.  */
> > > >      ff_fold_immediate = 1 << 2,
> > > > +  /* Whether we're escalating immediate-escalating functions.  */
> > > > +  ff_escalating = 1 << 3,
> > > 
> > > If we always escalate when we see a known immediate invocation, this means
> > > recurse.  And maybe we could use at_eof for that?
> > 
> > Yes.  Though, at_eof == 1 doesn't imply that all templates have been
> > instantiated, only that we got to c_parse_final_cleanups.  Rather than
> > keeping the ff_ flag, I've updated at_eof to mean that 2 signals that
> > all templates have been instantiated, and 3 that we're into cgraph
> > territory.  (Might should use an enum rather than magic numbers.)
> 
> Sounds good.
> 
> > > >    };
> > > >    using fold_flags_t = int;
> > > > @@ -428,6 +439,176 @@ lvalue_has_side_effects (tree e)
> > > >        return TREE_SIDE_EFFECTS (e);
> > > >    }
> > > > +/* Return true if FN is an immediate-escalating function.  */
> > > > +
> > > > +static bool
> > > > +immediate_escalating_function_p (tree fn)
> > > > +{
> > > > +  if (!fn || !flag_immediate_escalation)
> > > > +    return false;
> > > > +
> > > > +  gcc_checking_assert (TREE_CODE (fn) == FUNCTION_DECL);
> > > 
> > > Maybe check DECL_IMMEDIATE_FUNCTION_P early, rather than multiple times
> > > below...
> > > 
> > > > +  /* An immediate-escalating function is
> > > > +      -- the call operator of a lambda that is not declared with the consteval
> > > > +	 specifier  */
> > > > +  if (LAMBDA_FUNCTION_P (fn) && !DECL_IMMEDIATE_FUNCTION_P (fn))
> > > > +    return true;
> > > > +  /* -- a defaulted special member function that is not declared with the
> > > > +	consteval specifier  */
> > > > +  special_function_kind sfk = special_memfn_p (fn);
> > > > +  if (sfk != sfk_none
> > > > +      && DECL_DEFAULTED_FN (fn)
> > > > +      && !DECL_IMMEDIATE_FUNCTION_P (fn))
> > > > +    return true;
> > > > +  /* -- a function that results from the instantiation of a templated entity
> > > > +	defined with the constexpr specifier.  */
> > > > +  return is_instantiation_of_constexpr (fn);
> > > > +}
> > > > +
> > > > +/* Promote FN to an immediate function, including its clones, if it is
> > > > +   an immediate-escalating function.  Return true if we did promote;
> > > > +   false otherwise.  */
> > > > +
> > > > +static bool
> > > > +maybe_promote_function_to_consteval (tree fn)
> > > > +{
> > > > +  if (fn
> > > > +      && !DECL_IMMEDIATE_FUNCTION_P (fn)
> > > 
> > > ...and in all the callers?
> > 
> > Ah, beautiful.  And likewise for DECL_ESCALATION_CHECKED_P.
> 
> Agreed, but the function comment should mention that it returns false for an
> immediate-escalating function that is no longer a candidate for escalation.
> And maybe the function name should be something like
> unchecked_immediate_escalating_function_p to clarify that it implements
> something different from the term in the standard?

I've added unchecked_immediate_escalating_function_p, but I've kept
immediate_escalating_function_p; I like having functions that correspond
1:1 to terms defined in the standard.

> > > > +    return;
> > > > +
> > > > +  vec_safe_push (deferred_escalating_exprs, current_function_decl);
> > > > +}
> > > > +
> > > > +/* Find an immediate-escalating expression or conversion in *TP.
> > > > +   If DATA_ is non-null, this function will promote function to
> > > > +   consteval as it goes; otherwise, we're just looking for what
> > > > +   made a function consteval, for diagnostic purposes.  This
> > > > +   function assumes that *TP was instantiated.  */
> > > > +
> > > > +static tree
> > > > +find_escalating_expr_r (tree *tp, int *walk_subtrees, void *data)
> > > 
> > > Can this merge with cp_fold_immediate_r?  They seem to be doing essentially
> > > the same thing.
> > 
> > I did not do it, sorry.  I thought it would not make things more readable
> > as I don't see a whole lot of code to share.
> 
> The code is significantly different, sure, but both are walking the tree to
> look for immediate-escalating expressions.  Why do we need two of those?

I've merged find_escalating_expr_r into cp_fold_immediate_r in this patch.
It involves a goto and a new ff_ flag but overall it should be a win.

> > > > +		if (code == ADDR_EXPR || !data->pset.add (stmt))
> > > > +		  {
> > > > +		    taking_address_of_imm_fn_error (stmt, decl);
> > > > +		    *stmt_p = build_zero_cst (TREE_TYPE (stmt));
> > > > +		  }
> > > > +		/* If we're giving hard errors, continue the walk rather than
> > > > +		   bailing out after the first error.  */
> > > > +		break;
> > > > +	      }
> > > > +	    return error_mark_node;
> > > > +	  }
> > > > +	/* Not consteval yet, but could become one, in which case it's invalid
> > > > +	   to take its address.  */
> > > > +	else if (!(data->flags & ff_fold_immediate)
> > > 
> > > Why check ff_fold_immediate?  Don't we want to do deferred checking of
> > > immediate invocations in discarded branches?
> > 
> > On reflection, I was papering over a different problem here.
> > 
> > Inserting a new element to a hash table while we're traversing it is
> > dangerous because a new element might mean calling hash_table::expand
> > which creates a new table, std::moves the elements, and calls ggc_free
> > on the old table.  Then iterating to the next element is going to crash
> > because it has been freed.
> > 
> > We were trying to add a new element while being called from
> > process_pending_immediate_escalating_fns.  This should not happen.
> > The problem was that the DECL_ESCALATION_CHECKED_P flag may not have
> > been properly set for functions without any CALL_EXPRs in them, and that
> > immediate_escalating_function_p was not checking it, either.
> > 
> > The code is just
> > 
> > +   else if (immediate_escalating_function_p (decl))
> > +     remember_escalating_expr (stmt);
> > now.
> > 
> > The problem triggered in Wfree-nonheap-object-3.C.  Unfortunately, I could
> > not reduce it very far so I don't have a test suitable for the testsuite.
> > The tricky thing is that the problem only manifests when we expand() a hash
> > table which is unlikely to happen in a small test and I don't see a --param
> > I could use.
> 
> You could save the value of deferred_escalating_exprs->elements() before the
> loop and if it changes, abort in checking mode or goto back before the loop
> when not checking?

Right, that should work, but I don't think we want to ever add a new
element during process_pending_immediate_escalating_fns.  I've added a new
assert:

  gcc_checking_assert (at_eof <= 1);

> > > 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,

Bootstrapped/regtested on x86_64-pc-linux-gnu.

-- >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_ESCALATED_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.

	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_escalating.
	(struct cp_fold_data): New delegating ctor.
	(immediate_escalating_function_p): New.
	(unchecked_immediate_escalating_function_p): New.
	(promote_function_to_consteval): New.
	(maybe_promote_function_to_consteval): New.
	(maybe_store_cfun_for_late_checking): New.
	(maybe_explain_promoted_consteval): New.
	(maybe_escalate_decl_and_cfun): 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_immediate): Return true if any errors were emitted.
	(cp_fold_r): If a CALL_EXPR is wrapped in UNARY_PLUS_EXPR, 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                         | 447 ++++++++++++++++--
 gcc/cp/cp-tree.h                              |  18 +-
 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, 1650 insertions(+), 97 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: 91d7b036ebd650494f96828cfeacb6d90e7bd376

Message ID	ZUlp93ZwnARyoEia@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=UDmjHq3K; 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 4SPR4k42dnz1yQ5 for <incoming@patchwork.ozlabs.org>; Tue, 7 Nov 2023 09:35:18 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DEE1B385DC19 for <incoming@patchwork.ozlabs.org>; Mon, 6 Nov 2023 22:35:15 +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 78307385841B for <gcc-patches@gcc.gnu.org>; Mon, 6 Nov 2023 22:34:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78307385841B 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 78307385841B 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=1699310092; cv=none; b=Zq0EXH9qjPlsxJTP+ort+SctuomZwYu7Gadxd6RaBFP6ABlQnHX5X1wm3qnBRkvuWV42iwM3PrPcae/BpkWMtgoL9LTDpxqV6UD4qu1QfeKMVQRjdFVI9g6FXjw7B1mc0m5s8NdQJo6zHrY8O0D1CO0MqV0dSoyQNQRZgIEtlys= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699310092; c=relaxed/simple; bh=CEkGIV6Z85Qe/B5DXoAsl+2cB244CcMu4J6H2M4plEU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=I41D7Lqv1Z06twM4Jych78kQnOiDwpgeLaXeGpm5vVBbuAflPAHMAxVxprZYktj8HAe/+kXM6EwcD8zVRAkFvPpZ0jPlfcxBYTqzC0YsNjzGUuks9En+Ftiw8RlpoyKRjboeHLe5UCaC6oFWq9eimWuFSPRSUbRYFAikZWZG8Ck= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699310081; 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=XXpJXLMjxq/Wu6Sm92KtZYbuQp9cGFykzRV47UBU2pc=; b=UDmjHq3KPVuS9sLLIuyBsGZ9SPwdGxssBgaZNMNEFDiZzrkq+4oywQXQWyJYZka3feMndx bRWl4AI/+BLdE2WJ69SUdJmQN4NBe+WmgXNUd08nTW3CHG5Ifs/ES5JQ4+mOlJ7+bNl+AA xvnzCw6bUdUD+vFWZsWw44MA8jindew= Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-172-5Wd-TdAUOO-EFSmgeCOHsA-1; Mon, 06 Nov 2023 17:34:38 -0500 X-MC-Unique: 5Wd-TdAUOO-EFSmgeCOHsA-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-5b31e000e97so69040467b3.1 for <gcc-patches@gcc.gnu.org>; Mon, 06 Nov 2023 14:34:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699310077; x=1699914877; 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=VxU+DEbAiUOYqf5D8vszxzlGgeoY1Q5fWtQXjxN/Aa0=; b=M2KjCyFayzXXg+wRV0DJyXR0W0LwNA8TdTL4surVKS0YLVlWKaa8xQwBrfQgMNvsu2 W/BgTw0xFTcdTJ5yhInDezrSMy7uSZzA4YHSrziDd4Ady1/NL7vW2m9+6LLUSFICwcJh eU3TGTQUanJSERDpPrb7xdSDPqC2PFSnfeJXdIdDF7C5tiAopKgVQsW5Wn/cYSWEkWMM KwSP06AB/yV7mH3EpYYRdHO4rZuAXq6XMSn8CmAWEEmYgHB86cuU3pGsyxSLogo5dbaj RJhVgSeH6DwtIhFP7r4PBp95A+NAuq1XeFO1JAJFPM4jvW38tmC+eqhmU8pMK2psZ5vD Czhg== X-Gm-Message-State: AOJu0YxnlAbExfa7Xvr3ZOrcp4BJegTRlRqp2AXkLYv+LNI798Y16/P5 XMCc26RSWKQJAsFkxoPb1FLi5WodGUUH/mua/purhcYYKfZnQdFozyV1puu6v13w5b8GGDsRph2 bpT8OkFqQsigk8/SrE6yM5lDyxw== X-Received: by 2002:a0d:d693:0:b0:5a7:af46:d79d with SMTP id y141-20020a0dd693000000b005a7af46d79dmr12014598ywd.43.1699310075583; Mon, 06 Nov 2023 14:34:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IFUF/is72wtdVvlW5zj323GFD3VonHxxhWmqqB5ATFjuHV61vPNnFDTo66F9XYrcMlmgGt5yw== X-Received: by 2002:a0d:d693:0:b0:5a7:af46:d79d with SMTP id y141-20020a0dd693000000b005a7af46d79dmr12014545ywd.43.1699310073880; Mon, 06 Nov 2023 14:34:33 -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 b10-20020a056214002a00b0067169e210b3sm3824934qvr.70.2023.11.06.14.34.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 14:34:33 -0800 (PST) Date: Mon, 6 Nov 2023 17:34:31 -0500 From: Marek Polacek <polacek@redhat.com> To: Jason Merrill <jason@redhat.com> Cc: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH v4] c++: implement P2564, consteval needs to propagate up [PR107687] Message-ID: <ZUlp93ZwnARyoEia@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> MIME-Version: 1.0 In-Reply-To: <a0e8f057-99b1-4306-8772-553c1c4d9c9f@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=-22.2 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, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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	[v4] c++: implement P2564, consteval needs to propagate up [PR107687] \| expand [v4] c++: implement P2564, consteval needs to propagate up [PR107687]

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

Commit Message

Comments

Patch