[PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jakub Jelinek]

Hi!

My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx->globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-03-08  Jakub Jelinek  <jakub@redhat.com>

	PR c++/111284
	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
	cxx_eval_constant_expression and if it doesn't have the same
	type as it should, cast the reference type to reference to type
	before convert_from_reference and instead of adjust_temp_type
	take address of the arg, cast to reference to type and then
	convert_from_reference.
	(cxx_eval_constant_expression) <case PARM_DECL>: For lval case
	on parameters with TREE_ADDRESSABLE types lookup result in
	ctx->globals if possible.  Otherwise if lookup in ctx->globals
	was successful for parameter with TREE_ADDRESSABLE type,
	recurse with vc_prvalue on the returned value.

	* g++.dg/cpp1z/constexpr-111284.C: New test.
	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
	line.

--- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
+++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
@@ -1877,13 +1877,21 @@ cxx_bind_parameters_in_call (const const
 	  x = build_address (x);
 	}
       if (TREE_ADDRESSABLE (type))
-	/* Undo convert_for_arg_passing work here.  */
-	x = convert_from_reference (x);
-      /* Normally we would strip a TARGET_EXPR in an initialization context
-	 such as this, but here we do the elision differently: we keep the
-	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
-      arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
-					  non_constant_p, overflow_p);
+	{
+	  /* Undo convert_for_arg_passing work here.  */
+	  if (TYPE_REF_P (TREE_TYPE (x))
+	      && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
+	    x = cp_fold_convert (build_reference_type (type), x);
+	  x = convert_from_reference (x);
+	  arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
+					      non_constant_p, overflow_p);
+	}
+      else
+	/* Normally we would strip a TARGET_EXPR in an initialization context
+	   such as this, but here we do the elision differently: we keep the
+	   TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
+	arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
+					    non_constant_p, overflow_p);
       /* Check we aren't dereferencing a null pointer when calling a non-static
 	 member function, which is undefined behaviour.  */
       if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
@@ -1909,7 +1917,16 @@ cxx_bind_parameters_in_call (const const
 	{
 	  /* Make sure the binding has the same type as the parm.  But
 	     only for constant args.  */
-	  if (!TYPE_REF_P (type))
+	  if (TREE_ADDRESSABLE (type))
+	    {
+	      if (!same_type_p (type, TREE_TYPE (arg)))
+		{
+		  arg = build_fold_addr_expr (arg);
+		  arg = cp_fold_convert (build_reference_type (type), arg);
+		  arg = convert_from_reference (arg);
+		}
+	    }
+	  else if (!TYPE_REF_P (type))
 	    arg = adjust_temp_type (type, arg);
 	  if (!TREE_CONSTANT (arg))
 	    *non_constant_args = true;
@@ -7499,9 +7516,19 @@ cxx_eval_constant_expression (const cons
 
     case PARM_DECL:
       if (lval && !TYPE_REF_P (TREE_TYPE (t)))
-	/* glvalue use.  */;
+	{
+	  /* glvalue use.  */
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    if (tree v = ctx->global->get_value (t))
+	      r = v;
+	}
       else if (tree v = ctx->global->get_value (t))
-	r = v;
+	{
+	  r = v;
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
+					      non_constant_p, overflow_p);
+	}
       else if (lval)
 	/* Defer in case this is only used for its type.  */;
       else if (ctx->global->is_outside_lifetime (t))
--- gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C.jj	2024-03-07 16:27:48.113651999 +0100
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C	2024-03-07 16:26:49.565466606 +0100
@@ -0,0 +1,19 @@
+// PR c++/111284
+// { dg-do compile { target c++17 } }
+
+struct S {
+  S () = default;
+  constexpr S (const S &) noexcept : s{this} {}
+  constexpr S & operator= (const S &) noexcept { return *this; }
+  constexpr bool foo () const noexcept { return s == this; }
+  S *s = this;
+};
+
+constexpr bool
+bar (S x) noexcept
+{
+  return x.foo ();
+}
+
+static_assert (bar (S {}), "");
+static_assert ([] (S x) { return x.foo (); } (S {}), "");
--- gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C.jj	2023-12-13 19:09:33.252657826 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C	2024-03-07 19:49:49.342334090 +0100
@@ -87,7 +87,7 @@ constexpr bool n1 = test_access<NonTrivi
 constexpr bool n2 = test_modification<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n3 = test_scope<NonTrivial>();         // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n4 = test_destroy_temp<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
-constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-error "destroying" "" { target c++20 } }
+constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n6 = test_bindings<NonTrivial>();
 #endif
 

	Jakub

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2 patch.

Thanks.

	Jakub

Re: [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jason Merrill]

On 3/8/24 03:56, Jakub Jelinek wrote:
> Hi!
> 
> My r9-6136 changes to make a copy of constexpr function bodies before
> genericization modifies it broke the constant evaluation of non-POD
> arguments passed by value.
> In the callers such arguments are passed as reference to usually a
> TARGET_EXPR, but on the callee side until genericization they are just
> direct uses of a PARM_DECL with some class type.
> In cxx_bind_parameters_in_call I've used convert_from_reference to
> pretend it is passed by value and then cxx_eval_constant_expression
> is called there and evaluates that as an rvalue, followed by
> adjust_temp_type if the types don't match exactly (e.g. const Foo
> argument and passing to it reference to Foo TARGET_EXPR).
> 
> The reason this doesn't work is that when the TARGET_EXPR in the caller
> is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
> but if the code later on pretends the PARM_DECL is just initialized to the
> rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
> is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
> is then address of the PARM_DECL in the callee.
> 
> The following patch attempts to fix that by constexpr evaluation of such
> arguments in the caller as an lvalue instead of rvalue, and on the callee
> side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
> (lvalue) saved in ctx->globals (if any), and if wanting an rvalue,
> recursing with vc_prvalue on the looked up value (because it is there
> as an lvalue, nor rvalue).
> 
> adjust_temp_type doesn't work for lvalues of non-scalarish types, for
> such types it relies on changing the type of a CONSTRUCTOR, but on the
> other side we know what we pass to the argument is addressable, so
> the patch on type mismatch takes address of the argument value, casts
> to reference to the desired type and dereferences it.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2024-03-08  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/111284
> 	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
> 	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
> 	cxx_eval_constant_expression and if it doesn't have the same
> 	type as it should, cast the reference type to reference to type
> 	before convert_from_reference and instead of adjust_temp_type
> 	take address of the arg, cast to reference to type and then
> 	convert_from_reference.
> 	(cxx_eval_constant_expression) <case PARM_DECL>: For lval case
> 	on parameters with TREE_ADDRESSABLE types lookup result in
> 	ctx->globals if possible.  Otherwise if lookup in ctx->globals
> 	was successful for parameter with TREE_ADDRESSABLE type,
> 	recurse with vc_prvalue on the returned value.
> 
> 	* g++.dg/cpp1z/constexpr-111284.C: New test.
> 	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
> 	line.
> 
> --- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
> +++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
> @@ -1877,13 +1877,21 @@ cxx_bind_parameters_in_call (const const
>   	  x = build_address (x);
>   	}
>         if (TREE_ADDRESSABLE (type))
> -	/* Undo convert_for_arg_passing work here.  */
> -	x = convert_from_reference (x);
> -      /* Normally we would strip a TARGET_EXPR in an initialization context
> -	 such as this, but here we do the elision differently: we keep the
> -	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> -      arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> -					  non_constant_p, overflow_p);
> +	{
> +	  /* Undo convert_for_arg_passing work here.  */
> +	  if (TYPE_REF_P (TREE_TYPE (x))
> +	      && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
> +	    x = cp_fold_convert (build_reference_type (type), x);
> +	  x = convert_from_reference (x);
> +	  arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
> +					      non_constant_p, overflow_p);
> +	}
> +      else
> +	/* Normally we would strip a TARGET_EXPR in an initialization context
> +	   such as this, but here we do the elision differently: we keep the
> +	   TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> +	arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> +					    non_constant_p, overflow_p);

It seems simpler to move the convert_for_reference after the 
cxx_eval_constant_expression rather than duplicate the call to 
cxx_eval_constant_expression.

>         /* Check we aren't dereferencing a null pointer when calling a non-static
>   	 member function, which is undefined behaviour.  */
>         if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
> @@ -1909,7 +1917,16 @@ cxx_bind_parameters_in_call (const const
>   	{
>   	  /* Make sure the binding has the same type as the parm.  But
>   	     only for constant args.  */
> -	  if (!TYPE_REF_P (type))
> +	  if (TREE_ADDRESSABLE (type))
> +	    {
> +	      if (!same_type_p (type, TREE_TYPE (arg)))
> +		{
> +		  arg = build_fold_addr_expr (arg);
> +		  arg = cp_fold_convert (build_reference_type (type), arg);
> +		  arg = convert_from_reference (arg);
> +		}
> +	    }

It shouldn't be necessary to convert both here and above?  In fact, the 
testcase still passes with neither conversion, just moving the 
convert_for_reference and the change below.

> +	  else if (!TYPE_REF_P (type))
>   	    arg = adjust_temp_type (type, arg);
>   	  if (!TREE_CONSTANT (arg))
>   	    *non_constant_args = true;
> @@ -7499,9 +7516,19 @@ cxx_eval_constant_expression (const cons
>   
>       case PARM_DECL:
>         if (lval && !TYPE_REF_P (TREE_TYPE (t)))
> -	/* glvalue use.  */;
> +	{
> +	  /* glvalue use.  */
> +	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
> +	    if (tree v = ctx->global->get_value (t))
> +	      r = v;
> +	}
>         else if (tree v = ctx->global->get_value (t))
> -	r = v;
> +	{
> +	  r = v;
> +	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
> +	    r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
> +					      non_constant_p, overflow_p);
> +	}
>         else if (lval)
>   	/* Defer in case this is only used for its type.  */;
>         else if (ctx->global->is_outside_lifetime (t))
> --- gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C.jj	2024-03-07 16:27:48.113651999 +0100
> +++ gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C	2024-03-07 16:26:49.565466606 +0100
> @@ -0,0 +1,19 @@
> +// PR c++/111284
> +// { dg-do compile { target c++17 } }
> +
> +struct S {
> +  S () = default;
> +  constexpr S (const S &) noexcept : s{this} {}
> +  constexpr S & operator= (const S &) noexcept { return *this; }
> +  constexpr bool foo () const noexcept { return s == this; }
> +  S *s = this;
> +};
> +
> +constexpr bool
> +bar (S x) noexcept
> +{
> +  return x.foo ();
> +}
> +
> +static_assert (bar (S {}), "");
> +static_assert ([] (S x) { return x.foo (); } (S {}), "");
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C.jj	2023-12-13 19:09:33.252657826 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C	2024-03-07 19:49:49.342334090 +0100
> @@ -87,7 +87,7 @@ constexpr bool n1 = test_access<NonTrivi
>   constexpr bool n2 = test_modification<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n3 = test_scope<NonTrivial>();         // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n4 = test_destroy_temp<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
> -constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-error "destroying" "" { target c++20 } }
> +constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n6 = test_bindings<NonTrivial>();
>   #endif
>   
> 
> 	Jakub
> 

Re: [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jakub Jelinek]

On Fri, Apr 12, 2024 at 03:05:26PM -0400, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
> > +++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
> > @@ -1877,13 +1877,21 @@ cxx_bind_parameters_in_call (const const
> >   	  x = build_address (x);
> >   	}
> >         if (TREE_ADDRESSABLE (type))
> > -	/* Undo convert_for_arg_passing work here.  */
> > -	x = convert_from_reference (x);
> > -      /* Normally we would strip a TARGET_EXPR in an initialization context
> > -	 such as this, but here we do the elision differently: we keep the
> > -	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> > -      arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> > -					  non_constant_p, overflow_p);
> > +	{
> > +	  /* Undo convert_for_arg_passing work here.  */
> > +	  if (TYPE_REF_P (TREE_TYPE (x))
> > +	      && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
> > +	    x = cp_fold_convert (build_reference_type (type), x);
> > +	  x = convert_from_reference (x);
> > +	  arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
> > +					      non_constant_p, overflow_p);
> > +	}
> > +      else
> > +	/* Normally we would strip a TARGET_EXPR in an initialization context
> > +	   such as this, but here we do the elision differently: we keep the
> > +	   TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> > +	arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> > +					    non_constant_p, overflow_p);
> 
> It seems simpler to move the convert_for_reference after the
> cxx_eval_constant_expression rather than duplicate the call to
> cxx_eval_constant_expression.

They weren't the same, one was trying to evaluate the convert_from_reference
with vc_glvalue, the other evaluates it without that and with vc_prvalue.
Now, I guess the
+     /* Undo convert_for_arg_passing work here.  */
+     if (TYPE_REF_P (TREE_TYPE (x))
+         && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
+       x = cp_fold_convert (build_reference_type (type), x);
part could be thrown away, given the other !same_type_p check (that one is
needed because adjust_temp_type can't deal with that), at least
when I remove that
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTFLAGS="dg.exp='constexpr-dtor* pr114426.C constexpr-111284.C constexpr-lifetime7.C'"
still passes.  But if I try to remove even more, like in the patch below,
then I see
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++23 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++26 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++20  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++23  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++23 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++26  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++26 (test for excess errors)
regressions.
E.g.
.../g++.dg/cpp2a/constexpr-dtor5.C:30:20: error: non-constant condition for static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:31:20: error: non-constant condition for static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:32:20: error: non-constant condition for static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '<anonymous>' from outside current evaluation is not a constant expression

--- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
+++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
@@ -1871,9 +1871,6 @@ cxx_bind_parameters_in_call (const const
 	  x = ctx->object;
 	  x = build_address (x);
 	}
-      if (TREE_ADDRESSABLE (type))
-	/* Undo convert_for_arg_passing work here.  */
-	x = convert_from_reference (x);
       /* Normally we would strip a TARGET_EXPR in an initialization context
 	 such as this, but here we do the elision differently: we keep the
 	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
@@ -1904,7 +1901,13 @@ cxx_bind_parameters_in_call (const const
 	{
 	  /* Make sure the binding has the same type as the parm.  But
 	     only for constant args.  */
-	  if (!TYPE_REF_P (type))
+	  if (TREE_ADDRESSABLE (type))
+	    {
+	      if (!same_type_p (type, TREE_TYPE (TREE_TYPE (arg))))
+		arg = cp_fold_convert (build_reference_type (type), arg);
+	      arg = convert_from_reference (arg);
+	    }
+	  else if (!TYPE_REF_P (type))
 	    arg = adjust_temp_type (type, arg);
 	  if (!TREE_CONSTANT (arg))
 	    *non_constant_args = true;
@@ -7494,9 +7497,19 @@ cxx_eval_constant_expression (const cons
 
     case PARM_DECL:
       if (lval && !TYPE_REF_P (TREE_TYPE (t)))
-	/* glvalue use.  */;
+	{
+	  /* glvalue use.  */
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    if (tree v = ctx->global->get_value (t))
+	      r = v;
+	}
       else if (tree v = ctx->global->get_value (t))
-	r = v;
+	{
+	  r = v;
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
+					      non_constant_p, overflow_p);
+	}
       else if (lval)
 	/* Defer in case this is only used for its type.  */;
       else if (ctx->global->is_outside_lifetime (t))

	Jakub

[PATCH] c++, v2: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
> They weren't the same, one was trying to evaluate the convert_from_reference
> with vc_glvalue, the other evaluates it without that and with vc_prvalue.
> Now, I guess the
> +     /* Undo convert_for_arg_passing work here.  */
> +     if (TYPE_REF_P (TREE_TYPE (x))
> +         && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
> +       x = cp_fold_convert (build_reference_type (type), x);
> part could be thrown away, given the other !same_type_p check (that one is
> needed because adjust_temp_type can't deal with that), at least
> when I remove that
> GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTFLAGS="dg.exp='constexpr-dtor* pr114426.C constexpr-111284.C constexpr-lifetime7.C'"
> still passes.

I've now tested that version and it passed bootstrap/regtest on x86_64-linux
and i686-linux.  But as I said earlier, trying to tweak the patch further
doesn't work on the constexpr-dtor{5,6}.C tests.

2024-04-23  Jakub Jelinek  <jakub@redhat.com>

	PR c++/111284
	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
	cxx_eval_constant_expression and if it doesn't have the same
	type as it should, cast the reference type to reference to type
	before convert_from_reference and instead of adjust_temp_type
	take address of the arg, cast to reference to type and then
	convert_from_reference.
	(cxx_eval_constant_expression) <case PARM_DECL>: For lval case
	on parameters with TREE_ADDRESSABLE types lookup result in
	ctx->globals if possible.  Otherwise if lookup in ctx->globals
	was successful for parameter with TREE_ADDRESSABLE type,
	recurse with vc_prvalue on the returned value.

	* g++.dg/cpp1z/constexpr-111284.C: New test.
	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
	line.

--- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
+++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
@@ -1877,13 +1877,18 @@ cxx_bind_parameters_in_call (const const
 	  x = build_address (x);
 	}
       if (TREE_ADDRESSABLE (type))
-	/* Undo convert_for_arg_passing work here.  */
-	x = convert_from_reference (x);
-      /* Normally we would strip a TARGET_EXPR in an initialization context
-	 such as this, but here we do the elision differently: we keep the
-	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
-      arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
-					  non_constant_p, overflow_p);
+	{
+	  /* Undo convert_for_arg_passing work here.  */
+	  x = convert_from_reference (x);
+	  arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
+					      non_constant_p, overflow_p);
+	}
+      else
+	/* Normally we would strip a TARGET_EXPR in an initialization context
+	   such as this, but here we do the elision differently: we keep the
+	   TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
+	arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
+					    non_constant_p, overflow_p);
       /* Check we aren't dereferencing a null pointer when calling a non-static
 	 member function, which is undefined behaviour.  */
       if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
@@ -1909,7 +1914,16 @@ cxx_bind_parameters_in_call (const const
 	{
 	  /* Make sure the binding has the same type as the parm.  But
 	     only for constant args.  */
-	  if (!TYPE_REF_P (type))
+	  if (TREE_ADDRESSABLE (type))
+	    {
+	      if (!same_type_p (type, TREE_TYPE (arg)))
+		{
+		  arg = build_fold_addr_expr (arg);
+		  arg = cp_fold_convert (build_reference_type (type), arg);
+		  arg = convert_from_reference (arg);
+		}
+	    }
+	  else if (!TYPE_REF_P (type))
 	    arg = adjust_temp_type (type, arg);
 	  if (!TREE_CONSTANT (arg))
 	    *non_constant_args = true;
@@ -7499,9 +7513,19 @@ cxx_eval_constant_expression (const cons
 
     case PARM_DECL:
       if (lval && !TYPE_REF_P (TREE_TYPE (t)))
-	/* glvalue use.  */;
+	{
+	  /* glvalue use.  */
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    if (tree v = ctx->global->get_value (t))
+	      r = v;
+	}
       else if (tree v = ctx->global->get_value (t))
-	r = v;
+	{
+	  r = v;
+	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+	    r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
+					      non_constant_p, overflow_p);
+	}
       else if (lval)
 	/* Defer in case this is only used for its type.  */;
       else if (ctx->global->is_outside_lifetime (t))
--- gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C.jj	2024-03-07 16:27:48.113651999 +0100
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C	2024-03-07 16:26:49.565466606 +0100
@@ -0,0 +1,19 @@
+// PR c++/111284
+// { dg-do compile { target c++17 } }
+
+struct S {
+  S () = default;
+  constexpr S (const S &) noexcept : s{this} {}
+  constexpr S & operator= (const S &) noexcept { return *this; }
+  constexpr bool foo () const noexcept { return s == this; }
+  S *s = this;
+};
+
+constexpr bool
+bar (S x) noexcept
+{
+  return x.foo ();
+}
+
+static_assert (bar (S {}), "");
+static_assert ([] (S x) { return x.foo (); } (S {}), "");
--- gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C.jj	2023-12-13 19:09:33.252657826 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C	2024-03-07 19:49:49.342334090 +0100
@@ -87,7 +87,7 @@ constexpr bool n1 = test_access<NonTrivi
 constexpr bool n2 = test_modification<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n3 = test_scope<NonTrivial>();         // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n4 = test_destroy_temp<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
-constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-error "destroying" "" { target c++20 } }
+constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-message "in .constexpr." "" { target c++20 } }
 constexpr bool n6 = test_bindings<NonTrivial>();
 #endif
 


	Jakub

Re: [PATCH] c++, v2: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jason Merrill]

On 4/23/24 08:52, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
>> They weren't the same, one was trying to evaluate the convert_from_reference
>> with vc_glvalue, the other evaluates it without that and with vc_prvalue.
>> Now, I guess the
>> +     /* Undo convert_for_arg_passing work here.  */
>> +     if (TYPE_REF_P (TREE_TYPE (x))
>> +         && !same_type_p (type, TREE_TYPE (TREE_TYPE (x))))
>> +       x = cp_fold_convert (build_reference_type (type), x);
>> part could be thrown away, given the other !same_type_p check (that one is
>> needed because adjust_temp_type can't deal with that), at least
>> when I remove that
>> GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTFLAGS="dg.exp='constexpr-dtor* pr114426.C constexpr-111284.C constexpr-lifetime7.C'"
>> still passes.
> 
> I've now tested that version and it passed bootstrap/regtest on x86_64-linux
> and i686-linux.  But as I said earlier, trying to tweak the patch further
> doesn't work on the constexpr-dtor{5,6}.C tests.

OK.

> 2024-04-23  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/111284
> 	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
> 	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
> 	cxx_eval_constant_expression and if it doesn't have the same
> 	type as it should, cast the reference type to reference to type
> 	before convert_from_reference and instead of adjust_temp_type
> 	take address of the arg, cast to reference to type and then
> 	convert_from_reference.
> 	(cxx_eval_constant_expression) <case PARM_DECL>: For lval case
> 	on parameters with TREE_ADDRESSABLE types lookup result in
> 	ctx->globals if possible.  Otherwise if lookup in ctx->globals
> 	was successful for parameter with TREE_ADDRESSABLE type,
> 	recurse with vc_prvalue on the returned value.
> 
> 	* g++.dg/cpp1z/constexpr-111284.C: New test.
> 	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
> 	line.
> 
> --- gcc/cp/constexpr.cc.jj	2024-02-13 10:29:57.979155641 +0100
> +++ gcc/cp/constexpr.cc	2024-03-07 19:35:01.032412221 +0100
> @@ -1877,13 +1877,18 @@ cxx_bind_parameters_in_call (const const
>   	  x = build_address (x);
>   	}
>         if (TREE_ADDRESSABLE (type))
> -	/* Undo convert_for_arg_passing work here.  */
> -	x = convert_from_reference (x);
> -      /* Normally we would strip a TARGET_EXPR in an initialization context
> -	 such as this, but here we do the elision differently: we keep the
> -	 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> -      arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> -					  non_constant_p, overflow_p);
> +	{
> +	  /* Undo convert_for_arg_passing work here.  */
> +	  x = convert_from_reference (x);
> +	  arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
> +					      non_constant_p, overflow_p);
> +	}
> +      else
> +	/* Normally we would strip a TARGET_EXPR in an initialization context
> +	   such as this, but here we do the elision differently: we keep the
> +	   TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> +	arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> +					    non_constant_p, overflow_p);
>         /* Check we aren't dereferencing a null pointer when calling a non-static
>   	 member function, which is undefined behaviour.  */
>         if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
> @@ -1909,7 +1914,16 @@ cxx_bind_parameters_in_call (const const
>   	{
>   	  /* Make sure the binding has the same type as the parm.  But
>   	     only for constant args.  */
> -	  if (!TYPE_REF_P (type))
> +	  if (TREE_ADDRESSABLE (type))
> +	    {
> +	      if (!same_type_p (type, TREE_TYPE (arg)))
> +		{
> +		  arg = build_fold_addr_expr (arg);
> +		  arg = cp_fold_convert (build_reference_type (type), arg);
> +		  arg = convert_from_reference (arg);
> +		}
> +	    }
> +	  else if (!TYPE_REF_P (type))
>   	    arg = adjust_temp_type (type, arg);
>   	  if (!TREE_CONSTANT (arg))
>   	    *non_constant_args = true;
> @@ -7499,9 +7513,19 @@ cxx_eval_constant_expression (const cons
>   
>       case PARM_DECL:
>         if (lval && !TYPE_REF_P (TREE_TYPE (t)))
> -	/* glvalue use.  */;
> +	{
> +	  /* glvalue use.  */
> +	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
> +	    if (tree v = ctx->global->get_value (t))
> +	      r = v;
> +	}
>         else if (tree v = ctx->global->get_value (t))
> -	r = v;
> +	{
> +	  r = v;
> +	  if (TREE_ADDRESSABLE (TREE_TYPE (t)))
> +	    r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
> +					      non_constant_p, overflow_p);
> +	}
>         else if (lval)
>   	/* Defer in case this is only used for its type.  */;
>         else if (ctx->global->is_outside_lifetime (t))
> --- gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C.jj	2024-03-07 16:27:48.113651999 +0100
> +++ gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C	2024-03-07 16:26:49.565466606 +0100
> @@ -0,0 +1,19 @@
> +// PR c++/111284
> +// { dg-do compile { target c++17 } }
> +
> +struct S {
> +  S () = default;
> +  constexpr S (const S &) noexcept : s{this} {}
> +  constexpr S & operator= (const S &) noexcept { return *this; }
> +  constexpr bool foo () const noexcept { return s == this; }
> +  S *s = this;
> +};
> +
> +constexpr bool
> +bar (S x) noexcept
> +{
> +  return x.foo ();
> +}
> +
> +static_assert (bar (S {}), "");
> +static_assert ([] (S x) { return x.foo (); } (S {}), "");
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C.jj	2023-12-13 19:09:33.252657826 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C	2024-03-07 19:49:49.342334090 +0100
> @@ -87,7 +87,7 @@ constexpr bool n1 = test_access<NonTrivi
>   constexpr bool n2 = test_modification<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n3 = test_scope<NonTrivial>();         // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n4 = test_destroy_temp<NonTrivial>();  // { dg-message "in .constexpr." "" { target c++20 } }
> -constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-error "destroying" "" { target c++20 } }
> +constexpr bool n5 = test_parameter(NonTrivial{});     // { dg-message "in .constexpr." "" { target c++20 } }
>   constexpr bool n6 = test_bindings<NonTrivial>();
>   #endif
>   
> 
> 
> 	Jakub
> 

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2

https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html
PR114409 (part of a P1)

https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648381.html
PR114426 P1

Thanks.

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645781
[PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]
The thread contains two possible further versions of the patch.

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645782
[PATCH] dwarf2out: Emit DW_AT_export_symbols on anon unions/structs [PR113918]
The thread contains another version of the patch at the end.

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645916
[PATCH] c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange
Seems Richi would like to use MEM_REF in the c-family code, that is then
the https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646040.html
version.

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a couple of C++ patches.  All of them together
with the 2 updated patches posted yesterday have been
bootstrapped/regtested on x86_64-linux and i686-linux again yesterday.

- c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342]
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628375.html

- c++: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628378.html

- c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628487.html
  (from this one Richi approved the middle-end changes)

- c++: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341]
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628490.html

- libcpp, v2: Small incremental patch for P1854R4 [PR110341]
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628586.html

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the:

https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590276.html
PR102586 - reject __builtin_clear_padding on non-trivially-copyable types with one exception

https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590641.html
PR104568 - fix up constexpr evaluation of new with zero sized types

patches.

Thanks

	Jakub

Re: C++ patch ping

[Jason Merrill]

On 9/1/21 4:11 PM, Jakub Jelinek wrote:
> On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
>> On 8/30/21 3:11 AM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> I'd like to ping the following patches
>>>
>>> libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
>>> together with your
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
>>> incremental patch (successfully tested on x86_64-linux and i686-linux).
>>
>> OK, thanks.
> 
> Thanks, committed both patches.
> 
>> My reply to that patch approved it with a suggestion for a tweak to
>> ucn_valid_in_identifier.  Quoting it here:
>>
>>> I might check invalid_start_flags first, and return 1 if not set, then
>>> check all the other flags when not pedantic, and finally return 2 if
>>> nothing matches.  OK with or without this change.
> 
> Sorry for missing this, didn't scroll down enough.
> 
> I don't think something like:
>    if (CPP_OPTION (pfile, cxx23_identifiers))
>      invalid_start_flags = NXX23;
>    else if (CPP_OPTION (pfile, c11_identifiers))
>      invalid_start_flags = N11;
>    else if (CPP_OPTION (pfile, c99))
>      invalid_start_flags = N99;
>    else
>      invalid_start_flags = 0;
> 
>    /* In C99, UCN digits may not begin identifiers.  In C11 and C++11,
>       UCN combining characters may not begin identifiers.  */
>    if ((ucnranges[mn].flags & invalid_start_flags) == 0)
>      return 1;
> 
>    /* If not -pedantic, accept as character that may
>       begin an identifier a union of characters allowed
>       at that position in each of the character sets.  */
>    if (!CPP_PEDANTIC (pfile)
>        && ((ucnranges[mn].flags & (C99 | N99)) == C99
>            || (ucnranges[mn].flags & CXX) != 0
>            || (ucnranges[mn].flags & (C11 | N11)) == C11
>            || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23))
>      return 1;
> 
>    return 2;
> would work, e.g. for C++98 invalid_start_flags is 0, so it would return
> always 1, while the previous patch returned 2 for non-pedantic if the char
> wasn't in the CXX set but was e.g. in the C99 set that wasn't allowed
> as the first char (i.e. in & (C99 | N99) == (C99 | N99) set) etc.
> While all C99 | N99 characters are C11 | 0, e.g.
> \u0304 (and many others) are not in C99 at all, not in CXX, and in
> C11 | N11 and in CXX23 | NXX23.  So they are never valid as start
> characters.  There are also some characters like
> \u1dfa which are not in C99 at all, not in CXX, not in CXX23 and in
> C11 | N11, so again not valid as start character in any of the pedantic
> modes.  IMHO we want to return 2 for them in non-pedantic.
> And testing first
>    if (ucnranges[mn].flags & invalid_start_flags)
>      return 2;
> and then doing the if !CPP_PEDANTIC stuff wouldn't work either, e.g.
> \U0001d18b is in CXX23 | NXX23 and in C11 | 0, so we IMHO want to return
> 1 for that (allowed as start character in -pedantic -std=c++20, disallowed
> as start character in -pedantic -std=c++23) but we would return 2
> in -std=c++23 mode.

Fair enough.  Go ahead without changes, then.

Jason

Re: C++ patch ping

[Jakub Jelinek]

On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
> On 8/30/21 3:11 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping the following patches
> > 
> > libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
> > together with your
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
> > incremental patch (successfully tested on x86_64-linux and i686-linux).
> 
> OK, thanks.

Thanks, committed both patches.

> My reply to that patch approved it with a suggestion for a tweak to
> ucn_valid_in_identifier.  Quoting it here:
>
> > I might check invalid_start_flags first, and return 1 if not set, then
> > check all the other flags when not pedantic, and finally return 2 if
> > nothing matches.  OK with or without this change.

Sorry for missing this, didn't scroll down enough.

I don't think something like:
  if (CPP_OPTION (pfile, cxx23_identifiers))
    invalid_start_flags = NXX23;
  else if (CPP_OPTION (pfile, c11_identifiers))
    invalid_start_flags = N11;
  else if (CPP_OPTION (pfile, c99))
    invalid_start_flags = N99;
  else
    invalid_start_flags = 0;

  /* In C99, UCN digits may not begin identifiers.  In C11 and C++11,
     UCN combining characters may not begin identifiers.  */
  if ((ucnranges[mn].flags & invalid_start_flags) == 0)
    return 1;

  /* If not -pedantic, accept as character that may
     begin an identifier a union of characters allowed
     at that position in each of the character sets.  */
  if (!CPP_PEDANTIC (pfile)
      && ((ucnranges[mn].flags & (C99 | N99)) == C99
          || (ucnranges[mn].flags & CXX) != 0
          || (ucnranges[mn].flags & (C11 | N11)) == C11
          || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23))
    return 1;

  return 2;
would work, e.g. for C++98 invalid_start_flags is 0, so it would return
always 1, while the previous patch returned 2 for non-pedantic if the char
wasn't in the CXX set but was e.g. in the C99 set that wasn't allowed
as the first char (i.e. in & (C99 | N99) == (C99 | N99) set) etc.
While all C99 | N99 characters are C11 | 0, e.g.
\u0304 (and many others) are not in C99 at all, not in CXX, and in
C11 | N11 and in CXX23 | NXX23.  So they are never valid as start
characters.  There are also some characters like
\u1dfa which are not in C99 at all, not in CXX, not in CXX23 and in
C11 | N11, so again not valid as start character in any of the pedantic
modes.  IMHO we want to return 2 for them in non-pedantic.
And testing first
  if (ucnranges[mn].flags & invalid_start_flags)
    return 2;
and then doing the if !CPP_PEDANTIC stuff wouldn't work either, e.g.
\U0001d18b is in CXX23 | NXX23 and in C11 | 0, so we IMHO want to return
1 for that (allowed as start character in -pedantic -std=c++20, disallowed
as start character in -pedantic -std=c++23) but we would return 2
in -std=c++23 mode.

	Jakub

Re: C++ patch ping

[Jason Merrill]

On 8/30/21 3:11 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping the following patches
> 
> libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
> together with your
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
> incremental patch (successfully tested on x86_64-linux and i686-linux).

OK, thanks.

> libcpp, v2: Implement C++23 P1949R7 - C++ Identifier Syntax using Unicode Standard Annex 31 [PR100977]
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576854.html
> The incremental patch for splitting tokens at unsupported characters
> withdrawn, the above is the base patch.

My reply to that patch approved it with a suggestion for a tweak to 
ucn_valid_in_identifier.  Quoting it here:

>> @@ -998,6 +998,28 @@ ucn_valid_in_identifier (cpp_reader *pfi
>>       nst->previous = c;
>>     nst->prev_class = ucnranges[mn].combine;
>>   +  if (!CPP_PEDANTIC (pfile))
>> +    {
>> +      /* If not -pedantic, accept as character that may
>> +     begin an identifier a union of characters allowed
>> +     at that position in each of the character sets.  */
>> +      if ((ucnranges[mn].flags & (C99 | N99)) == C99
>> +      || (ucnranges[mn].flags & CXX) != 0
>> +      || (ucnranges[mn].flags & (C11 | N11)) == C11
>> +      || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23)
>> +    return 1;
>> +      return 2;
>> +    }
>> +
>> +  if (CPP_OPTION (pfile, cxx23_identifiers))
>> +    invalid_start_flags = NXX23;
>> +  else if (CPP_OPTION (pfile, c11_identifiers))
>> +    invalid_start_flags = N11;
>> +  else if (CPP_OPTION (pfile, c99))
>> +    invalid_start_flags = N99;
>> +  else
>> +    invalid_start_flags = 0;
>> +
>>     /* In C99, UCN digits may not begin identifiers.  In C11 and C++11,
>>        UCN combining characters may not begin identifiers.  */
>>     if (ucnranges[mn].flags & invalid_start_flags)
> 
> I might check invalid_start_flags first, and return 1 if not set, then check all the other flags when not pedantic, and finally return 2 if nothing matches.  OK with or without this change. 

Jason

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following patches

libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
together with your
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
incremental patch (successfully tested on x86_64-linux and i686-linux).

libcpp, v2: Implement C++23 P1949R7 - C++ Identifier Syntax using Unicode Standard Annex 31 [PR100977]
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576854.html
The incremental patch for splitting tokens at unsupported characters
withdrawn, the above is the base patch.

Thanks.

	Jakub

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

c++: Add C++20 #__VA_OPT__ support
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html

libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html

libcpp, v2: Implement C++23 P1949R7 - C++ Identifier Syntax using Unicode Standard Annex 31 [PR100977]
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576854.html

Thanks

	Jakub

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

c++: Add C++20 #__VA_OPT__ support
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html

libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html

c++: Accept C++11 attribute-definition [PR101582]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575897.html

Thanks

	Jakub

Re: C++ Patch ping

[Jason Merrill]

On 1/5/21 11:34 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping the:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html
> patch.

OK, thanks.

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html
patch.

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560372.html
- v3 of the __builtin_bit_cast (with (hopefully) all earlier feedback
incorporated).

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the updated bit_cast patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557781.html

Thanks
	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

- https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556370.html
  PR95808 - diagnose constexpr delete [] new int; and delete new int[N];

- https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556548.html
  PR97388 - fix up constexpr evaluation of arguments passed by invisible reference

Thanks

	Jakub

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
  https://gcc.gnu.org/ml/gcc-patches/2020-March/541542.html
  P2 PR91993 patch

If you think it is too dangerous for GCC10 and should be postponed,
I can ping it after 10.1 is released, or e.g. if you think for GCC10
we should for all codes handle that way only orig_op0 and not orig_op1,
I can tweak that too (in that case, unless something reorders the operands
of the binary expressions, it shouldn't evaluate side-effects differently
from the order we've been using in the past).

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00581.html
  PR92414, Fix error-recovery with constexpr dtor

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00808.html
  PR92458, Fix concepts vs. PCH

Thanks.

	Jakub

Re: C++ patch ping

[Jason Merrill]

On 12/4/18 9:47 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping
>    PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html
> 
> You've acked the patch with the asserts but that FAILs as mentioned
> in the above mail.  The following has been bootstrapped/regtested
> and works, can it be committed without those asserts and let those
> be handled incrementally later (though, I'm afraid I'm not familiar enough
> with resolving those).

OK>

Jason

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping
  PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html

You've acked the patch with the asserts but that FAILs as mentioned
in the above mail.  The following has been bootstrapped/regtested
and works, can it be committed without those asserts and let those
be handled incrementally later (though, I'm afraid I'm not familiar enough
with resolving those).

Thanks.

2018-11-21  Jakub Jelinek  <jakub@redhat.com>

	PR c++/87506
	* constexpr.c (adjust_temp_type): Handle EMPTY_CLASS_EXPR.

	* g++.dg/cpp0x/constexpr-87506.C: New test.

--- gcc/cp/constexpr.c.jj	2018-11-16 21:35:34.551110868 +0100
+++ gcc/cp/constexpr.c	2018-11-19 09:35:06.880386449 +0100
@@ -1280,6 +1280,8 @@ adjust_temp_type (tree type, tree temp)
   /* Avoid wrapping an aggregate value in a NOP_EXPR.  */
   if (TREE_CODE (temp) == CONSTRUCTOR)
     return build_constructor (type, CONSTRUCTOR_ELTS (temp));
+  if (TREE_CODE (temp) == EMPTY_CLASS_EXPR)
+    return build0 (EMPTY_CLASS_EXPR, type);
   gcc_assert (scalarish_type_p (type));
   return cp_fold_convert (type, temp);
 }
--- gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C.jj	2018-11-19 09:33:07.795341369 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C	2018-11-19 09:33:07.795341369 +0100
@@ -0,0 +1,12 @@
+// PR c++/87506
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B { constexpr B (const A) {} };
+struct C : B { using B::B; };
+
+void
+foo ()
+{
+  C c (A{});
+}


	Jakub

Re: C++ patch ping

[Jakub Jelinek]

On Fri, Jul 13, 2018 at 12:24:02PM -0400, Nathan Sidwell wrote:
> On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping the following C++ patches:
> > 
> > - PR c++/85515
> >    make range for temporaries unspellable during parsing and only
> >    turn them into spellable for debug info purposes
> >    http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html
> 
> 
> How hard would it be to add the 6 special identifiers to the C++ global
> table via initialize_predefined_identifiers (decl.c) and then use them
> directly in the for range machinery?  repeated get_identifier
> ("string-const") just smells bad.

Probably not too hard, but we have hundreds of other
get_identifier ("string-const") calls in the middle-end, C++ FE, other FEs.
Are those 6 more important than say "abi_tag", "gnu", "begin", "end", "get",
"tuple_size", "tuple_element", and many others?

Is it worth caching those?

	Jakub

Re: C++ patch ping

[Nathan Sidwell]

On 07/13/2018 09:49 AM, Jakub Jelinek wrote:

> - PR c++/3698, PR c++/86208
>    extern_decl_map & TREE_USED fix (plus 2 untested variants)
>    http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00084.html

ok, thanks

-- 
Nathan Sidwell

Re: C++ patch ping

[Nathan Sidwell]

On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping the following C++ patches:
> 
> - PR c++/85515
>    make range for temporaries unspellable during parsing and only
>    turn them into spellable for debug info purposes
>    http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html


How hard would it be to add the 6 special identifiers to the C++ global 
table via initialize_predefined_identifiers (decl.c) and then use them 
directly in the for range machinery?  repeated get_identifier 
("string-const") just smells bad.

nathan

-- 
Nathan Sidwell

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following C++ patches:

- PR c++/85515
  make range for temporaries unspellable during parsing and only
  turn them into spellable for debug info purposes
  http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html

- PR c++/3698, PR c++/86208
  extern_decl_map & TREE_USED fix (plus 2 untested variants)
  http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00084.html

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patches:

http://gcc.gnu.org/ml/gcc-patches/2018-01/msg02066.html
  - PR83993 - fix constexpr handling of arrays with unknown bound

http://gcc.gnu.org/ml/gcc-patches/2018-01/msg02067.html
  - PR83993 - don't clear TREE_CONSTANT on ADDR_EXPRs in constexpr.c

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the:

http://gcc.gnu.org/ml/gcc-patches/2017-12/msg01499.html
  - PR83556 fix replace_placeholders

patch.

Thanks.

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping two patches:

http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02521.html
  PR c++/83205 - diagnose invalid std::tuple_size<X>::value for structured
		 bindings; the follow-up with plural spelling is approved
		 already

http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02629.html
  PR c++/83217 - handle references to non-complete type in structured
		 bindings

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 C++2A patches:
  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01235.html
    P0683R1 - default member initializers for bit-fields

  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01237.html
    P0704R1 - fixing const-qualified pointers to members

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg00937.html
  - fix compile time hog in replace_placeholders
patch.

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 C++ patches:

- P1 PR79232 - ICEs and wrong-code with COMPOUND_EXPR on lhs of assignment
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02341.html

- P1 PR79288 - wrong default TLS model for __thread static data members
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02349.html

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR77830 fix for out of bounds constexpr stores:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01319.html

	Jakub

Re: C++ Patch Ping

[Nathan Sidwell]

On 12/15/2016 07:26 AM, Jakub Jelinek wrote:

> I don't think so.  complete_type (error_mark_node) returns error_mark_node,
> and COMPLETE_TYPE_P (error_mark_node) is invalid (should fail TYPE_CHECK in
> checking compiler).
>
> I can write it as
>   inst = complete_type (inst);
>   if (inst == error_mark_node || !COMPLETE_TYPE_P (inst))
>     return NULL_TREE;

that's probably better, because complete_type can return error_mark_node 
if 'something goes horribly wrong'


-- 
Nathan Sidwell

Re: C++ Patch Ping

[Jakub Jelinek]

On Thu, Dec 15, 2016 at 07:14:15AM -0500, Nathan Sidwell wrote:
> On 12/15/2016 03:34 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping the
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
> > P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early
> 
> +  if (inst == error_mark_node)
> +    return NULL_TREE;
> 
> This check is unneeded, because complete_type DTRT with error_mark_node
> 
> +  inst = complete_type (inst);
> +  if (!COMPLETE_TYPE_P (inst))
> +    return NULL_TREE;

I don't think so.  complete_type (error_mark_node) returns error_mark_node,
and COMPLETE_TYPE_P (error_mark_node) is invalid (should fail TYPE_CHECK in
checking compiler).

I can write it as
  inst = complete_type (inst);
  if (inst == error_mark_node || !COMPLETE_TYPE_P (inst))
    return NULL_TREE;

	Jakub

Re: C++ Patch Ping

[Nathan Sidwell]

On 12/15/2016 03:34 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the
>
> http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
> P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early

+  if (inst == error_mark_node)
+    return NULL_TREE;

This check is unneeded, because complete_type DTRT with error_mark_node

+  inst = complete_type (inst);
+  if (!COMPLETE_TYPE_P (inst))
+    return NULL_TREE;


-- 
Nathan Sidwell

C++ Patch Ping

[Jakub Jelinek]

Hi!

I'd like to ping the

http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early 

patch.

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches from a week ago:

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html
  - PR77375 - wrong-code with mutable members in base classes

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html
  - PR77338 - fix constexpr ICE on PARM_DECL with incomplete type

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg02002.html
  - PR77379 - fix testcase mangling regexps for 32-bit targets

	Jakub

Re: C++ patch ping

[Jason Merrill]

OK.

Jason

Re: C++ patch ping

[Jakub Jelinek]

On Mon, Jan 11, 2016 at 05:04:16PM -0500, Jason Merrill wrote:
> >You mean:
> >
> >--- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c	2016-01-11 21:33:09.065184178 +0100
> >@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
> >  	    DECL_TEMPLATE_INSTANTIATED (r) = 0;
> >  	    if (type == error_mark_node)
> >  	      RETURN (error_mark_node);
> >+	    if (DECL_LANG_SPECIFIC (r))
> >+	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
> >  	    if (TREE_CODE (type) == FUNCTION_TYPE)
> >  	      {
> >  		/* It may seem that this case cannot occur, since:
> >
> >I'm almost through bootstrapping that, but regtesting will take some more
> >time.

That version regressed:
+FAIL: g++.dg/cpp1y/var-templ16.C  -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ16.C  -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp1y/var-templ18.C  -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ18.C  -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp1y/var-templ27.C  -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ27.C  -std=c++14 (test for excess errors)

> >Do you mean:
> >
> >--- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c	2016-01-11 22:49:12.303477700 +0100
> >@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
> >  	    SET_DECL_IMPLICIT_INSTANTIATION (r);
> >  	    register_specialization (r, gen_tmpl, argvec, false, hash);
> >  	  }
> >-	else if (!cp_unevaluated_operand)
> >-	  register_local_specialization (r, t);
> >+	else
> >+	  {
> >+	    if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
> >+	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
> >+	    if (!cp_unevaluated_operand)
> >+	      register_local_specialization (r, t);
> >+	  }
> >
> >  	DECL_CHAIN (r) = NULL_TREE;
> >
> >or something different?  Or should it be cleared also for non-VAR_DECLs
> >if they have DECL_LANG_SPECIFIC?
> 
> Yes, like that.  You don't need to check VAR_P, since TYPE_DECL also has
> DECL_TEMPLATE_INFO.

But following patch passed bootstrap on x86_64-linux and bootstrap + regtest
on i686-linux, ok for trunk if it also passes regtest on x86_64-linux?

2016-01-12  Jakub Jelinek  <jakub@redhat.com>

	PR c++/66808
	PR c++/69000
	* pt.c (tsubst_decl): If not local_p, clear DECL_TEMPLATE_INFO.

	* g++.dg/tls/pr66808.C: New test.
	* g++.dg/tls/pr69000.C: New test.

--- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c	2016-01-11 23:22:54.742344987 +0100
@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
 	    SET_DECL_IMPLICIT_INSTANTIATION (r);
 	    register_specialization (r, gen_tmpl, argvec, false, hash);
 	  }
-	else if (!cp_unevaluated_operand)
-	  register_local_specialization (r, t);
+	else
+	  {
+	    if (DECL_LANG_SPECIFIC (r))
+	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
+	    if (!cp_unevaluated_operand)
+	      register_local_specialization (r, t);
+	  }
 
 	DECL_CHAIN (r) = NULL_TREE;
 
--- gcc/testsuite/g++.dg/tls/pr69000.C.jj	2015-12-21 14:03:38.362847547 +0100
+++ gcc/testsuite/g++.dg/tls/pr69000.C	2015-12-21 14:04:17.839291295 +0100
@@ -0,0 +1,19 @@
+// PR c++/69000
+// { dg-do compile }
+// { dg-require-effective-target tls }
+
+class A {};
+
+template <typename T>
+struct B
+{
+  static int *& foo () { static __thread int *c = 0; return c; }
+};
+
+B<A> d;
+
+void
+bar ()
+{
+  d.foo ();
+}
--- gcc/testsuite/g++.dg/tls/pr66808.C.jj	2015-12-21 14:06:06.791756074 +0100
+++ gcc/testsuite/g++.dg/tls/pr66808.C	2015-12-21 14:06:02.651814409 +0100
@@ -0,0 +1,10 @@
+// PR c++/66808
+// { dg-do compile { target c++11 } }
+// { dg-require-effective-target tls }
+
+template <typename>
+class A {
+  int *b = foo ();
+  int *foo () { static __thread int a; return &a; }
+};
+A<int> b;


	Jakub

Re: C++ patch ping

[Jason Merrill]

On 01/11/2016 04:52 PM, Jakub Jelinek wrote:
> On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
>> On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
>>> On 01/09/16 02:41, Jakub Jelinek wrote:
>>>> Hi!
>>>>
>>>> I'd like to ping the PR c++/66808, PR c++/69000
>>>> http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
>>>> patch, fixing ICE with GNU __thread vars in templates.
>>>
>>> Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
>>>
>>> if (DECL_LANG_SPECIFIC(r))
>>>    DECL_TEMPLATE_INFO(r) == NULL_TREE;
>>> ?
>
> You mean:
>
> --- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
> +++ gcc/cp/pt.c	2016-01-11 21:33:09.065184178 +0100
> @@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
>   	    DECL_TEMPLATE_INSTANTIATED (r) = 0;
>   	    if (type == error_mark_node)
>   	      RETURN (error_mark_node);
> +	    if (DECL_LANG_SPECIFIC (r))
> +	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
>   	    if (TREE_CODE (type) == FUNCTION_TYPE)
>   	      {
>   		/* It may seem that this case cannot occur, since:
>
> I'm almost through bootstrapping that, but regtesting will take some more
> time.
>
>> Or clear it for local_p down by where we're setting it for !local_p.
>
> Do you mean:
>
> --- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
> +++ gcc/cp/pt.c	2016-01-11 22:49:12.303477700 +0100
> @@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
>   	    SET_DECL_IMPLICIT_INSTANTIATION (r);
>   	    register_specialization (r, gen_tmpl, argvec, false, hash);
>   	  }
> -	else if (!cp_unevaluated_operand)
> -	  register_local_specialization (r, t);
> +	else
> +	  {
> +	    if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
> +	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
> +	    if (!cp_unevaluated_operand)
> +	      register_local_specialization (r, t);
> +	  }
>
>   	DECL_CHAIN (r) = NULL_TREE;
>
> or something different?  Or should it be cleared also for non-VAR_DECLs
> if they have DECL_LANG_SPECIFIC?

Yes, like that.  You don't need to check VAR_P, since TYPE_DECL also has 
DECL_TEMPLATE_INFO.

Jason

Re: C++ patch ping

[Jakub Jelinek]

On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
> On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
> >On 01/09/16 02:41, Jakub Jelinek wrote:
> >>Hi!
> >>
> >>I'd like to ping the PR c++/66808, PR c++/69000
> >>http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
> >>patch, fixing ICE with GNU __thread vars in templates.
> >
> >Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
> >
> >if (DECL_LANG_SPECIFIC(r))
> >   DECL_TEMPLATE_INFO(r) == NULL_TREE;
> >?

You mean:

--- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c	2016-01-11 21:33:09.065184178 +0100
@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
 	    DECL_TEMPLATE_INSTANTIATED (r) = 0;
 	    if (type == error_mark_node)
 	      RETURN (error_mark_node);
+	    if (DECL_LANG_SPECIFIC (r))
+	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
 	    if (TREE_CODE (type) == FUNCTION_TYPE)
 	      {
 		/* It may seem that this case cannot occur, since:

I'm almost through bootstrapping that, but regtesting will take some more
time.

> Or clear it for local_p down by where we're setting it for !local_p.

Do you mean:

--- gcc/cp/pt.c.jj	2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c	2016-01-11 22:49:12.303477700 +0100
@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
 	    SET_DECL_IMPLICIT_INSTANTIATION (r);
 	    register_specialization (r, gen_tmpl, argvec, false, hash);
 	  }
-	else if (!cp_unevaluated_operand)
-	  register_local_specialization (r, t);
+	else
+	  {
+	    if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
+	      DECL_TEMPLATE_INFO (r) = NULL_TREE;
+	    if (!cp_unevaluated_operand)
+	      register_local_specialization (r, t);
+	  }
 
 	DECL_CHAIN (r) = NULL_TREE;
 
or something different?  Or should it be cleared also for non-VAR_DECLs
if they have DECL_LANG_SPECIFIC?

	Jakub

Re: C++ patch ping

[Jason Merrill]

On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
> On 01/09/16 02:41, Jakub Jelinek wrote:
>> Hi!
>>
>> I'd like to ping the PR c++/66808, PR c++/69000
>> http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
>> patch, fixing ICE with GNU __thread vars in templates.
>
> Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
>
> if (DECL_LANG_SPECIFIC(r))
>    DECL_TEMPLATE_INFO(r) == NULL_TREE;
> ?

Or clear it for local_p down by where we're setting it for !local_p.

Jason

Re: C++ patch ping

[Nathan Sidwell]

On 01/09/16 02:41, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the PR c++/66808, PR c++/69000
> http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
> patch, fixing ICE with GNU __thread vars in templates.

Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?

if (DECL_LANG_SPECIFIC(r))
   DECL_TEMPLATE_INFO(r) == NULL_TREE;
?

nathan

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.

Thanks

	Jakub

Re: C++ patch ping

[Mark Mitchell]

Jakub Jelinek wrote:

> So, if I should use error_operand_p instead, I guess it should be changed
> consistently for all 3 cases, or none.

Oh, I see.  My brain's being a little dumb.  Yes, we can rely on 
cp_build_modify_expr to return an error_mark_node on error, and in that 
case it's fine as is.  So, go with your original patch.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: C++ patch ping

[Jakub Jelinek]

On Mon, Apr 28, 2008 at 10:06:35AM -0700, Mark Mitchell wrote:
> Jakub Jelinek wrote:
> 
> >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html	PR c++/35650
> 
> I think this patch is OK.  As you say, we could also change 

Thanks.

> >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html	PR c++/35987
> 
> This is OK, too, though I would prefer using error_operand_p to the 
> direct comparision with error_mark_node.  In this case, error_mark_node 
> is probably correct -- but using error_operand_p for expressions is more 
> mnemonic.

cp_build_modify_expr starts with:

  /* Avoid duplicate error messages from operands that had errors.  */
  if (error_operand_p (lhs) || error_operand_p (rhs))
    return error_mark_node;

so it should turn many results
res != error_mark_node && TREE_TYPE (res) == error_mark_node
into error_mark_node.  And the following cases also use direct
error_mark_node comparison:

      /* Handle (a, b) used as an "lvalue".  */
    case COMPOUND_EXPR:
      newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 1),
                                     modifycode, rhs, complain);
      if (newrhs == error_mark_node)
^^^^ here
        return error_mark_node;
      return build2 (COMPOUND_EXPR, lhstype,
                     TREE_OPERAND (lhs, 0), newrhs);

    case MODIFY_EXPR:
      if (TREE_SIDE_EFFECTS (TREE_OPERAND (lhs, 0)))
        lhs = build2 (TREE_CODE (lhs), TREE_TYPE (lhs),
                      stabilize_reference (TREE_OPERAND (lhs, 0)),
                      TREE_OPERAND (lhs, 1));
      newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 0), modifycode, rhs,
                                     complain);
      if (newrhs == error_mark_node)
^^^^ and here
        return error_mark_node;
      return build2 (COMPOUND_EXPR, lhstype, lhs, newrhs);
(and later code in the function does similarly).

So, if I should use error_operand_p instead, I guess it should be changed
consistently for all 3 cases, or none.

	Jakub

Re: C++ patch ping

[Mark Mitchell]

Jakub Jelinek wrote:

> - http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html	PR c++/35650

I think this patch is OK.  As you say, we could also change 
reference_binding or initialize_reference, but the general policy in the 
front end has been to resolve single OVERLOADs at the point of lookup. 
In fact, if we were you going to make a more substantial change here, it 
would probably be to have the USING_DECL record only a FUNCTION_DECL, 
rather than an OVERLOAD.

> - http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html	PR c++/35987

This is OK, too, though I would prefer using error_operand_p to the 
direct comparision with error_mark_node.  In this case, error_mark_node 
is probably correct -- but using error_operand_p for expressions is more 
mnemonic.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

C++ patch ping

[Jakub Jelinek]

Hi!

- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html	PR c++/35650
- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html	PR c++/35987

	Jakub

Re: C++ patch ping

[Mark Mitchell]

Giovanni Bajo wrote:
> Hello,
> 
> [PR19508] Do not apply attributes to template parms
> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01325.html
> 
> OK with the suggested modification (sorry() instead of warning())? 

OK.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

C++ patch ping

[Giovanni Bajo]

Hello,

[PR19508] Do not apply attributes to template parms
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01325.html

OK with the suggested modification (sorry() instead of warning())? 

Giovanni Bajo