public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* C++ patch ping
@ 2018-07-13 13:49 Jakub Jelinek
  2018-07-13 16:24 ` Nathan Sidwell
  2018-07-13 16:42 ` C++ patch ping Nathan Sidwell
  0 siblings, 2 replies; 54+ messages in thread
From: Jakub Jelinek @ 2018-07-13 13:49 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2018-07-13 13:49 C++ patch ping Jakub Jelinek
@ 2018-07-13 16:24 ` Nathan Sidwell
  2018-07-13 16:53   ` Jakub Jelinek
  2018-07-13 16:42 ` C++ patch ping Nathan Sidwell
  1 sibling, 1 reply; 54+ messages in thread
From: Nathan Sidwell @ 2018-07-13 16:24 UTC (permalink / raw)
  To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2018-07-13 13:49 C++ patch ping Jakub Jelinek
  2018-07-13 16:24 ` Nathan Sidwell
@ 2018-07-13 16:42 ` Nathan Sidwell
  1 sibling, 0 replies; 54+ messages in thread
From: Nathan Sidwell @ 2018-07-13 16:42 UTC (permalink / raw)
  To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2018-07-13 16:24 ` Nathan Sidwell
@ 2018-07-13 16:53   ` Jakub Jelinek
  2018-07-18 10:19     ` [C++ PATCH] Hide __for_{range,begin,end} symbols (PR c++/85515, take 2) Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2018-07-13 16:53 UTC (permalink / raw)
  To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* [C++ PATCH] Hide __for_{range,begin,end} symbols (PR c++/85515, take 2)
  2018-07-13 16:53   ` Jakub Jelinek
@ 2018-07-18 10:19     ` Jakub Jelinek
  2018-07-18 21:05       ` [C++ PATCH] Further get_identifier ("string literal") C++ FE caching Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2018-07-18 10:19 UTC (permalink / raw)
  To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches

On Fri, Jul 13, 2018 at 06:53:30PM +0200, Jakub Jelinek wrote:
> 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?

Anyway, here is an updated patch that uses the get_identifier caching.
Ok for trunk?

Shall I submit an incremental patch for the "abi_tag", "gnu", "begin", "end", "get",
"tuple_size", "tuple_element" etc. identifiers?

2018-07-18  Jakub Jelinek  <jakub@redhat.com>

	PR c++/85515
	* cp-tree.h (enum cp_tree_index): Add
	CPTI_FOR_{RANGE,BEGIN,END}{,_}_IDENTIFIER.
	(for_range__identifier, for_begin__identifier, for_end__identifier,
	for_range_identifier, for_begin_identifier, for_end_identifier):
	Define.
	* decl.c (initialize_predefined_identifiers): Initialize
	for_{range,begin,end}{,_}_identifier.
	* parser.c (build_range_temp): Use for_range__identifier instead of
	get_identifier ("__for_range").
	(cp_convert_range_for): Use for_begin__identifier and
	for_end__identifier instead of get_identifier ("__for_begin") and
	get_identifier ("__for_end").
	* semantics.c (finish_for_stmt): Rename "__for_{range,begin,end} "
	local symbols to "__for_{range,begin,end}".

	* g++.dg/pr85515-2.C: Add expected dg-error.
	* g++.dg/cpp0x/range-for36.C: New test.

--- gcc/cp/cp-tree.h.jj	2018-06-29 09:38:17.790306399 +0200
+++ gcc/cp/cp-tree.h	2018-07-18 11:57:55.980529748 +0200
@@ -154,6 +154,12 @@ enum cp_tree_index
     CPTI_AUTO_IDENTIFIER,
     CPTI_DECLTYPE_AUTO_IDENTIFIER,
     CPTI_INIT_LIST_IDENTIFIER,
+    CPTI_FOR_RANGE__IDENTIFIER,
+    CPTI_FOR_BEGIN__IDENTIFIER,
+    CPTI_FOR_END__IDENTIFIER,
+    CPTI_FOR_RANGE_IDENTIFIER,
+    CPTI_FOR_BEGIN_IDENTIFIER,
+    CPTI_FOR_END_IDENTIFIER,
 
     CPTI_LANG_NAME_C,
     CPTI_LANG_NAME_CPLUSPLUS,
@@ -274,6 +280,12 @@ extern GTY(()) tree cp_global_trees[CPTI
 #define auto_identifier			cp_global_trees[CPTI_AUTO_IDENTIFIER]
 #define decltype_auto_identifier	cp_global_trees[CPTI_DECLTYPE_AUTO_IDENTIFIER]
 #define init_list_identifier		cp_global_trees[CPTI_INIT_LIST_IDENTIFIER]
+#define for_range__identifier		cp_global_trees[CPTI_FOR_RANGE__IDENTIFIER]
+#define for_begin__identifier		cp_global_trees[CPTI_FOR_BEGIN__IDENTIFIER]
+#define for_end__identifier		cp_global_trees[CPTI_FOR_END__IDENTIFIER]
+#define for_range_identifier		cp_global_trees[CPTI_FOR_RANGE_IDENTIFIER]
+#define for_begin_identifier		cp_global_trees[CPTI_FOR_BEGIN_IDENTIFIER]
+#define for_end_identifier		cp_global_trees[CPTI_FOR_END_IDENTIFIER]
 #define lang_name_c			cp_global_trees[CPTI_LANG_NAME_C]
 #define lang_name_cplusplus		cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
 
--- gcc/cp/decl.c.jj	2018-07-12 21:34:44.798598796 +0200
+++ gcc/cp/decl.c	2018-07-18 11:59:06.220595473 +0200
@@ -4044,6 +4044,12 @@ initialize_predefined_identifiers (void)
     {"auto", &auto_identifier, cik_normal},
     {"decltype(auto)", &decltype_auto_identifier, cik_normal},
     {"initializer_list", &init_list_identifier, cik_normal},
+    {"__for_range ", &for_range__identifier, cik_normal},
+    {"__for_begin ", &for_begin__identifier, cik_normal},
+    {"__for_end ", &for_end__identifier, cik_normal},
+    {"__for_range", &for_range_identifier, cik_normal},
+    {"__for_begin", &for_begin_identifier, cik_normal},
+    {"__for_end", &for_end_identifier, cik_normal},
     {NULL, NULL, cik_normal}
   };
 
--- gcc/cp/parser.c.jj	2018-07-18 10:09:10.655030931 +0200
+++ gcc/cp/parser.c	2018-07-18 12:00:22.907667232 +0200
@@ -11952,8 +11952,8 @@ build_range_temp (tree range_expr)
 				  type_uses_auto (range_type));
 
   /* Create the __range variable.  */
-  range_temp = build_decl (input_location, VAR_DECL,
-			   get_identifier ("__for_range"), range_type);
+  range_temp = build_decl (input_location, VAR_DECL, for_range__identifier,
+			   range_type);
   TREE_USED (range_temp) = 1;
   DECL_ARTIFICIAL (range_temp) = 1;
 
@@ -12060,8 +12060,8 @@ cp_convert_range_for (tree statement, tr
     }
 
   /* The new for initialization statement.  */
-  begin = build_decl (input_location, VAR_DECL,
-		      get_identifier ("__for_begin"), iter_type);
+  begin = build_decl (input_location, VAR_DECL, for_begin__identifier,
+		      iter_type);
   TREE_USED (begin) = 1;
   DECL_ARTIFICIAL (begin) = 1;
   pushdecl (begin);
@@ -12071,8 +12071,7 @@ cp_convert_range_for (tree statement, tr
 
   if (cxx_dialect >= cxx17)
     iter_type = cv_unqualified (TREE_TYPE (end_expr));
-  end = build_decl (input_location, VAR_DECL,
-		    get_identifier ("__for_end"), iter_type);
+  end = build_decl (input_location, VAR_DECL, for_end__identifier, iter_type);
   TREE_USED (end) = 1;
   DECL_ARTIFICIAL (end) = 1;
   pushdecl (end);
--- gcc/cp/semantics.c.jj	2018-07-10 09:11:24.254062152 +0200
+++ gcc/cp/semantics.c	2018-07-18 12:03:24.482837137 +0200
@@ -1060,7 +1060,35 @@ finish_for_stmt (tree for_stmt)
 		     : &FOR_SCOPE (for_stmt));
   tree scope = *scope_ptr;
   *scope_ptr = NULL;
+
+  /* During parsing of the body, range for uses "__for_{range,begin,end} "
+     decl names to make those unaccessible by code in the body.
+     Change it to ones with underscore instead of space, so that it can
+     be inspected in the debugger.  */
+  tree range_for_decl[3] = { NULL_TREE, NULL_TREE, NULL_TREE };
+  gcc_assert (CPTI_FOR_BEGIN__IDENTIFIER == CPTI_FOR_RANGE__IDENTIFIER + 1
+	      && CPTI_FOR_END__IDENTIFIER == CPTI_FOR_RANGE__IDENTIFIER + 2
+	      && CPTI_FOR_RANGE_IDENTIFIER == CPTI_FOR_RANGE__IDENTIFIER + 3
+	      && CPTI_FOR_BEGIN_IDENTIFIER == CPTI_FOR_BEGIN__IDENTIFIER + 3
+	      && CPTI_FOR_END_IDENTIFIER == CPTI_FOR_END__IDENTIFIER + 3);
+  for (int i = 0; i < 3; i++)
+    {
+      tree id = cp_global_trees[CPTI_FOR_RANGE__IDENTIFIER + i];
+      if (IDENTIFIER_BINDING (id)
+	  && IDENTIFIER_BINDING (id)->scope == current_binding_level)
+	{
+	  range_for_decl[i] = IDENTIFIER_BINDING (id)->value;
+	  gcc_assert (VAR_P (range_for_decl[i])
+		      && DECL_ARTIFICIAL (range_for_decl[i]));
+	}
+    }
+
   add_stmt (do_poplevel (scope));
+
+  for (int i = 0; i < 3; i++)
+    if (range_for_decl[i])
+      DECL_NAME (range_for_decl[i])
+	= cp_global_trees[CPTI_FOR_RANGE_IDENTIFIER + i];
 }
 
 /* Begin a range-for-statement.  Returns a new RANGE_FOR_STMT.
--- gcc/testsuite/g++.dg/pr85515-2.C.jj	2018-07-05 11:41:51.439718304 +0200
+++ gcc/testsuite/g++.dg/pr85515-2.C	2018-07-18 11:27:36.452850086 +0200
@@ -15,8 +15,7 @@ int test_2 ()
   int sum = 0;
   for (const auto v: arr) {
     sum += v;
-    // TODO: should we issue an error for the following assignment?
-    __for_begin = __for_end;
+    __for_begin = __for_end;	// { dg-error "was not declared in this scope" }
   }
   return sum;
 }
--- gcc/testsuite/g++.dg/cpp0x/range-for36.C.jj	2018-07-18 11:27:36.452850086 +0200
+++ gcc/testsuite/g++.dg/cpp0x/range-for36.C	2018-07-18 11:27:36.452850086 +0200
@@ -0,0 +1,32 @@
+// PR c++/85515
+// { dg-do compile { target c++11 } }
+
+int a[10];
+
+void
+foo ()
+{
+  for (auto &i : a)
+    if (i != *__for_begin		// { dg-error "was not declared in this scope" }
+	|| &i == __for_end		// { dg-error "was not declared in this scope" }
+	|| &__for_range[0] != &a[0])	// { dg-error "was not declared in this scope" }
+      __builtin_abort ();
+}
+
+template <int N>
+void
+bar ()
+{
+  for (auto &i : a)
+    if (i != *__for_begin		// { dg-error "was not declared in this scope" }
+	|| &i == __for_end		// { dg-error "was not declared in this scope" }
+	|| &__for_range[0] != &a[0])	// { dg-error "was not declared in this scope" }
+      __builtin_abort ();
+}
+
+void
+baz ()
+{
+  foo ();
+  bar <0> ();
+}


	Jakub

^ permalink raw reply	[flat|nested] 54+ messages in thread

* [C++ PATCH] Further get_identifier ("string literal") C++ FE caching
  2018-07-18 10:19     ` [C++ PATCH] Hide __for_{range,begin,end} symbols (PR c++/85515, take 2) Jakub Jelinek
@ 2018-07-18 21:05       ` Jakub Jelinek
  2018-07-18 22:00         ` Nathan Sidwell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2018-07-18 21:05 UTC (permalink / raw)
  To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches

On Wed, Jul 18, 2018 at 12:19:31PM +0200, Jakub Jelinek wrote:
> Shall I submit an incremental patch for the "abi_tag", "gnu", "begin", "end", "get",
> "tuple_size", "tuple_element" etc. identifiers?

Here it is in an incremental patch.  I've tried to do it only for
get_identifier ("string literal") calls that can be called many times during
parsing rather than just at most once, and aren't related to -fgnu-tm,
-fopenmp, Obj-C++ or vtv.

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

2018-07-18  Jakub Jelinek  <jakub@redhat.com>

	* cp-tree.h (enum cp_tree_index): Add
	CPTI_{ABI_TAG,ALIGNED,BEGIN,END,GET,TUPLE_{ELEMENT,SIZE}}_IDENTIFIER
	and CPTI_{GNU,TYPE,VALUE,FUN,CLOSURE}_IDENTIFIER.
	(abi_tag_identifier, aligned_identifier, begin_identifier,
	end_identifier, get__identifier, gnu_identifier,
	tuple_element_identifier, tuple_size_identifier, type_identifier,
	value_identifier, fun_identifier, closure_identifier): Define.
	* decl.c (initialize_predefined_identifiers): Initialize the above
	identifiers.
	(get_tuple_size): Use tuple_size_identifier instead of
	get_identifier ("tuple_size") and value_identifier instead of
	get_identifier ("value").
	(get_tuple_element_type): Use tuple_element_identifier instead of
	get_identifier ("tuple_element") and type_identifier instead of
	get_identifier ("type").
	(get_tuple_decomp_init): Use get__identifier instead of
	get_identifier ("get").
	* lambda.c (maybe_add_lambda_conv_op): Use fun_identifier instead of
	get_identifier ("_FUN").
	* parser.c (cp_parser_lambda_declarator_opt): Use closure_identifier
	instead of get_identifier ("__closure").
	(cp_parser_std_attribute): Use gnu_identifier instead of
	get_identifier ("gnu").
	(cp_parser_std_attribute_spec): Likewise.  Use aligned_identifier
	instead of get_identifier ("aligned").
	* class.c (check_abi_tags, inherit_targ_abi_tags): Use
	abi_tag_identifier instead of get_identifier ("abi_tag").

--- gcc/cp/cp-tree.h.jj	2018-07-18 11:57:55.980529748 +0200
+++ gcc/cp/cp-tree.h	2018-07-18 18:52:44.805248036 +0200
@@ -160,6 +160,18 @@ enum cp_tree_index
     CPTI_FOR_RANGE_IDENTIFIER,
     CPTI_FOR_BEGIN_IDENTIFIER,
     CPTI_FOR_END_IDENTIFIER,
+    CPTI_ABI_TAG_IDENTIFIER,
+    CPTI_ALIGNED_IDENTIFIER,
+    CPTI_BEGIN_IDENTIFIER,
+    CPTI_END_IDENTIFIER,
+    CPTI_GET_IDENTIFIER,
+    CPTI_GNU_IDENTIFIER,
+    CPTI_TUPLE_ELEMENT_IDENTIFIER,
+    CPTI_TUPLE_SIZE_IDENTIFIER,
+    CPTI_TYPE_IDENTIFIER,
+    CPTI_VALUE_IDENTIFIER,
+    CPTI_FUN_IDENTIFIER,
+    CPTI_CLOSURE_IDENTIFIER,
 
     CPTI_LANG_NAME_C,
     CPTI_LANG_NAME_CPLUSPLUS,
@@ -286,6 +298,18 @@ extern GTY(()) tree cp_global_trees[CPTI
 #define for_range_identifier		cp_global_trees[CPTI_FOR_RANGE_IDENTIFIER]
 #define for_begin_identifier		cp_global_trees[CPTI_FOR_BEGIN_IDENTIFIER]
 #define for_end_identifier		cp_global_trees[CPTI_FOR_END_IDENTIFIER]
+#define abi_tag_identifier		cp_global_trees[CPTI_ABI_TAG_IDENTIFIER]
+#define aligned_identifier		cp_global_trees[CPTI_ALIGNED_IDENTIFIER]
+#define begin_identifier		cp_global_trees[CPTI_BEGIN_IDENTIFIER]
+#define end_identifier			cp_global_trees[CPTI_END_IDENTIFIER]
+#define get__identifier			cp_global_trees[CPTI_GET_IDENTIFIER]
+#define gnu_identifier			cp_global_trees[CPTI_GNU_IDENTIFIER]
+#define tuple_element_identifier	cp_global_trees[CPTI_TUPLE_ELEMENT_IDENTIFIER]
+#define tuple_size_identifier		cp_global_trees[CPTI_TUPLE_SIZE_IDENTIFIER]
+#define type_identifier			cp_global_trees[CPTI_TYPE_IDENTIFIER]
+#define value_identifier		cp_global_trees[CPTI_VALUE_IDENTIFIER]
+#define fun_identifier			cp_global_trees[CPTI_FUN_IDENTIFIER]
+#define closure_identifier		cp_global_trees[CPTI_CLOSURE_IDENTIFIER]
 #define lang_name_c			cp_global_trees[CPTI_LANG_NAME_C]
 #define lang_name_cplusplus		cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
 
--- gcc/cp/decl.c.jj	2018-07-18 11:59:06.220595473 +0200
+++ gcc/cp/decl.c	2018-07-18 18:52:58.676265952 +0200
@@ -4050,6 +4050,18 @@ initialize_predefined_identifiers (void)
     {"__for_range", &for_range_identifier, cik_normal},
     {"__for_begin", &for_begin_identifier, cik_normal},
     {"__for_end", &for_end_identifier, cik_normal},
+    {"abi_tag", &abi_tag_identifier, cik_normal},
+    {"aligned", &aligned_identifier, cik_normal},
+    {"begin", &begin_identifier, cik_normal},
+    {"end", &end_identifier, cik_normal},
+    {"get", &get__identifier, cik_normal},
+    {"gnu", &gnu_identifier, cik_normal},
+    {"tuple_element", &tuple_element_identifier, cik_normal},
+    {"tuple_size", &tuple_size_identifier, cik_normal},
+    {"type", &type_identifier, cik_normal},
+    {"value", &value_identifier, cik_normal},
+    {"_FUN", &fun_identifier, cik_normal},
+    {"__closure", &closure_identifier, cik_normal},
     {NULL, NULL, cik_normal}
   };
 
@@ -7334,14 +7346,14 @@ get_tuple_size (tree type)
 {
   tree args = make_tree_vec (1);
   TREE_VEC_ELT (args, 0) = type;
-  tree inst = lookup_template_class (get_identifier ("tuple_size"), args,
+  tree inst = lookup_template_class (tuple_size_identifier, args,
 				     /*in_decl*/NULL_TREE,
 				     /*context*/std_node,
 				     /*entering_scope*/false, tf_none);
   inst = complete_type (inst);
   if (inst == error_mark_node || !COMPLETE_TYPE_P (inst))
     return NULL_TREE;
-  tree val = lookup_qualified_name (inst, get_identifier ("value"),
+  tree val = lookup_qualified_name (inst, value_identifier,
 				    /*type*/false, /*complain*/false);
   if (TREE_CODE (val) == VAR_DECL || TREE_CODE (val) == CONST_DECL)
     val = maybe_constant_value (val);
@@ -7359,12 +7371,12 @@ get_tuple_element_type (tree type, unsig
   tree args = make_tree_vec (2);
   TREE_VEC_ELT (args, 0) = build_int_cst (integer_type_node, i);
   TREE_VEC_ELT (args, 1) = type;
-  tree inst = lookup_template_class (get_identifier ("tuple_element"), args,
+  tree inst = lookup_template_class (tuple_element_identifier, args,
 				     /*in_decl*/NULL_TREE,
 				     /*context*/std_node,
 				     /*entering_scope*/false,
 				     tf_warning_or_error);
-  return make_typename_type (inst, get_identifier ("type"),
+  return make_typename_type (inst, type_identifier,
 			     none_type, tf_warning_or_error);
 }
 
@@ -7373,7 +7385,6 @@ get_tuple_element_type (tree type, unsig
 static tree
 get_tuple_decomp_init (tree decl, unsigned i)
 {
-  tree get_id = get_identifier ("get");
   tree targs = make_tree_vec (1);
   TREE_VEC_ELT (targs, 0) = build_int_cst (integer_type_node, i);
 
@@ -7386,7 +7397,7 @@ get_tuple_decomp_init (tree decl, unsign
       || TYPE_REF_IS_RVALUE (etype))
     e = move (e);
 
-  tree fns = lookup_qualified_name (TREE_TYPE (e), get_id,
+  tree fns = lookup_qualified_name (TREE_TYPE (e), get__identifier,
 				    /*type*/false, /*complain*/false);
   bool use_member_get = false;
 
@@ -7418,7 +7429,7 @@ get_tuple_decomp_init (tree decl, unsign
   else
     {
       vec<tree,va_gc> *args = make_tree_vector_single (e);
-      fns = lookup_template_function (get_id, targs);
+      fns = lookup_template_function (get__identifier, targs);
       fns = perform_koenig_lookup (fns, args, tf_warning_or_error);
       return finish_call_expr (fns, &args, /*novirt*/false,
 			       /*koenig*/true, tf_warning_or_error);
--- gcc/cp/lambda.c.jj	2018-06-16 08:49:51.377795726 +0200
+++ gcc/cp/lambda.c	2018-07-18 18:50:03.840040093 +0200
@@ -1214,8 +1214,7 @@ maybe_add_lambda_conv_op (tree type)
 
   /* Now build up the thunk to be returned.  */
 
-  name = get_identifier ("_FUN");
-  tree statfn = build_lang_decl (FUNCTION_DECL, name, stattype);
+  tree statfn = build_lang_decl (FUNCTION_DECL, fun_identifier, stattype);
   SET_DECL_LANGUAGE (statfn, lang_cplusplus);
   fn = statfn;
   DECL_SOURCE_LOCATION (fn) = DECL_SOURCE_LOCATION (callop);
--- gcc/cp/parser.c.jj	2018-07-18 12:00:22.907667232 +0200
+++ gcc/cp/parser.c	2018-07-18 18:50:46.361095022 +0200
@@ -10638,7 +10638,7 @@ cp_parser_lambda_declarator_opt (cp_pars
 	DECL_INITIALIZED_IN_CLASS_P (fco) = 1;
 	DECL_ARTIFICIAL (fco) = 1;
 	/* Give the object parameter a different name.  */
-	DECL_NAME (DECL_ARGUMENTS (fco)) = get_identifier ("__closure");
+	DECL_NAME (DECL_ARGUMENTS (fco)) = closure_identifier;
       }
     if (template_param_list)
       {
@@ -25341,13 +25341,13 @@ cp_parser_std_attribute (cp_parser *pars
 				   NULL_TREE);
       /* C++11 noreturn attribute is equivalent to GNU's.  */
       if (is_attribute_p ("noreturn", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* C++14 deprecated attribute is equivalent to GNU's.  */
       else if (is_attribute_p ("deprecated", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* C++17 fallthrough attribute is equivalent to GNU's.  */
       else if (is_attribute_p ("fallthrough", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* Transactional Memory TS optimize_for_synchronized attribute is
 	 equivalent to GNU transaction_callable.  */
       else if (is_attribute_p ("optimize_for_synchronized", attr_id))
@@ -25367,7 +25367,7 @@ cp_parser_std_attribute (cp_parser *pars
     vec<tree, va_gc> *vec;
     int attr_flag = normal_attr;
 
-    if (attr_ns == get_identifier ("gnu")
+    if (attr_ns == gnu_identifier
 	&& attribute_takes_identifier_p (attr_id))
       /* A GNU attribute that takes an identifier in parameter.  */
       attr_flag = id_attr;
@@ -25580,10 +25580,9 @@ cp_parser_std_attribute_spec (cp_parser
 
       /* Build the C++-11 representation of an 'aligned'
 	 attribute.  */
-      attributes =
-	build_tree_list (build_tree_list (get_identifier ("gnu"),
-					  get_identifier ("aligned")),
-			 alignas_expr);
+      attributes
+	= build_tree_list (build_tree_list (gnu_identifier,
+					    aligned_identifier), alignas_expr);
     }
 
   return attributes;
--- gcc/cp/class.c.jj	2018-07-16 23:24:23.326390997 +0200
+++ gcc/cp/class.c	2018-07-18 18:39:49.184244081 +0200
@@ -1517,8 +1517,7 @@ check_abi_tags (tree t, tree subob, bool
 	TREE_VALUE (attr) = chainon (data.tags, TREE_VALUE (attr));
       else
 	DECL_ATTRIBUTES (t)
-	  = tree_cons (get_identifier ("abi_tag"), data.tags,
-		       DECL_ATTRIBUTES (t));
+	  = tree_cons (abi_tag_identifier, data.tags, DECL_ATTRIBUTES (t));
     }
 
   mark_abi_tags (t, false);
@@ -1590,8 +1589,7 @@ inherit_targ_abi_tags (tree t)
 	TREE_VALUE (attr) = chainon (data.tags, TREE_VALUE (attr));
       else
 	TYPE_ATTRIBUTES (t)
-	  = tree_cons (get_identifier ("abi_tag"), data.tags,
-		       TYPE_ATTRIBUTES (t));
+	  = tree_cons (abi_tag_identifier, data.tags, TYPE_ATTRIBUTES (t));
     }
 
   mark_abi_tags (t, false);


	Jakub

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [C++ PATCH] Further get_identifier ("string literal") C++ FE caching
  2018-07-18 21:05       ` [C++ PATCH] Further get_identifier ("string literal") C++ FE caching Jakub Jelinek
@ 2018-07-18 22:00         ` Nathan Sidwell
  2018-07-18 22:43           ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Nathan Sidwell @ 2018-07-18 22:00 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

So cool! Thanks.
Sorry for the top posting
nathan-- Nathan Sidwell
-------- Original message --------From: Jakub Jelinek <jakub@redhat.com> Date: 7/18/18  17:04  (GMT-05:00) To: Nathan Sidwell <nathan@acm.org> Cc: Jason Merrill <jason@redhat.com>, gcc-patches@gcc.gnu.org Subject: [C++ PATCH] Further get_identifier ("string literal") C++ FE caching 
On Wed, Jul 18, 2018 at 12:19:31PM +0200, Jakub Jelinek wrote:
> Shall I submit an incremental patch for the "abi_tag", "gnu", "begin", "end", "get",
> "tuple_size", "tuple_element" etc. identifiers?

Here it is in an incremental patch.  I've tried to do it only for
get_identifier ("string literal") calls that can be called many times during
parsing rather than just at most once, and aren't related to -fgnu-tm,
-fopenmp, Obj-C++ or vtv.

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

2018-07-18  Jakub Jelinek  <jakub@redhat.com>

	* cp-tree.h (enum cp_tree_index): Add
	CPTI_{ABI_TAG,ALIGNED,BEGIN,END,GET,TUPLE_{ELEMENT,SIZE}}_IDENTIFIER
	and CPTI_{GNU,TYPE,VALUE,FUN,CLOSURE}_IDENTIFIER.
	(abi_tag_identifier, aligned_identifier, begin_identifier,
	end_identifier, get__identifier, gnu_identifier,
	tuple_element_identifier, tuple_size_identifier, type_identifier,
	value_identifier, fun_identifier, closure_identifier): Define.
	* decl.c (initialize_predefined_identifiers): Initialize the above
	identifiers.
	(get_tuple_size): Use tuple_size_identifier instead of
	get_identifier ("tuple_size") and value_identifier instead of
	get_identifier ("value").
	(get_tuple_element_type): Use tuple_element_identifier instead of
	get_identifier ("tuple_element") and type_identifier instead of
	get_identifier ("type").
	(get_tuple_decomp_init): Use get__identifier instead of
	get_identifier ("get").
	* lambda.c (maybe_add_lambda_conv_op): Use fun_identifier instead of
	get_identifier ("_FUN").
	* parser.c (cp_parser_lambda_declarator_opt): Use closure_identifier
	instead of get_identifier ("__closure").
	(cp_parser_std_attribute): Use gnu_identifier instead of
	get_identifier ("gnu").
	(cp_parser_std_attribute_spec): Likewise.  Use aligned_identifier
	instead of get_identifier ("aligned").
	* class.c (check_abi_tags, inherit_targ_abi_tags): Use
	abi_tag_identifier instead of get_identifier ("abi_tag").

--- gcc/cp/cp-tree.h.jj	2018-07-18 11:57:55.980529748 +0200
+++ gcc/cp/cp-tree.h	2018-07-18 18:52:44.805248036 +0200
@@ -160,6 +160,18 @@ enum cp_tree_index
     CPTI_FOR_RANGE_IDENTIFIER,
     CPTI_FOR_BEGIN_IDENTIFIER,
     CPTI_FOR_END_IDENTIFIER,
+    CPTI_ABI_TAG_IDENTIFIER,
+    CPTI_ALIGNED_IDENTIFIER,
+    CPTI_BEGIN_IDENTIFIER,
+    CPTI_END_IDENTIFIER,
+    CPTI_GET_IDENTIFIER,
+    CPTI_GNU_IDENTIFIER,
+    CPTI_TUPLE_ELEMENT_IDENTIFIER,
+    CPTI_TUPLE_SIZE_IDENTIFIER,
+    CPTI_TYPE_IDENTIFIER,
+    CPTI_VALUE_IDENTIFIER,
+    CPTI_FUN_IDENTIFIER,
+    CPTI_CLOSURE_IDENTIFIER,
 
     CPTI_LANG_NAME_C,
     CPTI_LANG_NAME_CPLUSPLUS,
@@ -286,6 +298,18 @@ extern GTY(()) tree cp_global_trees[CPTI
 #define for_range_identifier		cp_global_trees[CPTI_FOR_RANGE_IDENTIFIER]
 #define for_begin_identifier		cp_global_trees[CPTI_FOR_BEGIN_IDENTIFIER]
 #define for_end_identifier		cp_global_trees[CPTI_FOR_END_IDENTIFIER]
+#define abi_tag_identifier		cp_global_trees[CPTI_ABI_TAG_IDENTIFIER]
+#define aligned_identifier		cp_global_trees[CPTI_ALIGNED_IDENTIFIER]
+#define begin_identifier		cp_global_trees[CPTI_BEGIN_IDENTIFIER]
+#define end_identifier			cp_global_trees[CPTI_END_IDENTIFIER]
+#define get__identifier			cp_global_trees[CPTI_GET_IDENTIFIER]
+#define gnu_identifier			cp_global_trees[CPTI_GNU_IDENTIFIER]
+#define tuple_element_identifier	cp_global_trees[CPTI_TUPLE_ELEMENT_IDENTIFIER]
+#define tuple_size_identifier		cp_global_trees[CPTI_TUPLE_SIZE_IDENTIFIER]
+#define type_identifier			cp_global_trees[CPTI_TYPE_IDENTIFIER]
+#define value_identifier		cp_global_trees[CPTI_VALUE_IDENTIFIER]
+#define fun_identifier			cp_global_trees[CPTI_FUN_IDENTIFIER]
+#define closure_identifier		cp_global_trees[CPTI_CLOSURE_IDENTIFIER]
 #define lang_name_c			cp_global_trees[CPTI_LANG_NAME_C]
 #define lang_name_cplusplus		cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
 
--- gcc/cp/decl.c.jj	2018-07-18 11:59:06.220595473 +0200
+++ gcc/cp/decl.c	2018-07-18 18:52:58.676265952 +0200
@@ -4050,6 +4050,18 @@ initialize_predefined_identifiers (void)
     {"__for_range", &for_range_identifier, cik_normal},
     {"__for_begin", &for_begin_identifier, cik_normal},
     {"__for_end", &for_end_identifier, cik_normal},
+    {"abi_tag", &abi_tag_identifier, cik_normal},
+    {"aligned", &aligned_identifier, cik_normal},
+    {"begin", &begin_identifier, cik_normal},
+    {"end", &end_identifier, cik_normal},
+    {"get", &get__identifier, cik_normal},
+    {"gnu", &gnu_identifier, cik_normal},
+    {"tuple_element", &tuple_element_identifier, cik_normal},
+    {"tuple_size", &tuple_size_identifier, cik_normal},
+    {"type", &type_identifier, cik_normal},
+    {"value", &value_identifier, cik_normal},
+    {"_FUN", &fun_identifier, cik_normal},
+    {"__closure", &closure_identifier, cik_normal},
     {NULL, NULL, cik_normal}
   };
 
@@ -7334,14 +7346,14 @@ get_tuple_size (tree type)
 {
   tree args = make_tree_vec (1);
   TREE_VEC_ELT (args, 0) = type;
-  tree inst = lookup_template_class (get_identifier ("tuple_size"), args,
+  tree inst = lookup_template_class (tuple_size_identifier, args,
 				     /*in_decl*/NULL_TREE,
 				     /*context*/std_node,
 				     /*entering_scope*/false, tf_none);
   inst = complete_type (inst);
   if (inst == error_mark_node || !COMPLETE_TYPE_P (inst))
     return NULL_TREE;
-  tree val = lookup_qualified_name (inst, get_identifier ("value"),
+  tree val = lookup_qualified_name (inst, value_identifier,
 				    /*type*/false, /*complain*/false);
   if (TREE_CODE (val) == VAR_DECL || TREE_CODE (val) == CONST_DECL)
     val = maybe_constant_value (val);
@@ -7359,12 +7371,12 @@ get_tuple_element_type (tree type, unsig
   tree args = make_tree_vec (2);
   TREE_VEC_ELT (args, 0) = build_int_cst (integer_type_node, i);
   TREE_VEC_ELT (args, 1) = type;
-  tree inst = lookup_template_class (get_identifier ("tuple_element"), args,
+  tree inst = lookup_template_class (tuple_element_identifier, args,
 				     /*in_decl*/NULL_TREE,
 				     /*context*/std_node,
 				     /*entering_scope*/false,
 				     tf_warning_or_error);
-  return make_typename_type (inst, get_identifier ("type"),
+  return make_typename_type (inst, type_identifier,
 			     none_type, tf_warning_or_error);
 }
 
@@ -7373,7 +7385,6 @@ get_tuple_element_type (tree type, unsig
 static tree
 get_tuple_decomp_init (tree decl, unsigned i)
 {
-  tree get_id = get_identifier ("get");
   tree targs = make_tree_vec (1);
   TREE_VEC_ELT (targs, 0) = build_int_cst (integer_type_node, i);
 
@@ -7386,7 +7397,7 @@ get_tuple_decomp_init (tree decl, unsign
       || TYPE_REF_IS_RVALUE (etype))
     e = move (e);
 
-  tree fns = lookup_qualified_name (TREE_TYPE (e), get_id,
+  tree fns = lookup_qualified_name (TREE_TYPE (e), get__identifier,
 				    /*type*/false, /*complain*/false);
   bool use_member_get = false;
 
@@ -7418,7 +7429,7 @@ get_tuple_decomp_init (tree decl, unsign
   else
     {
       vec<tree,va_gc> *args = make_tree_vector_single (e);
-      fns = lookup_template_function (get_id, targs);
+      fns = lookup_template_function (get__identifier, targs);
       fns = perform_koenig_lookup (fns, args, tf_warning_or_error);
       return finish_call_expr (fns, &args, /*novirt*/false,
 			       /*koenig*/true, tf_warning_or_error);
--- gcc/cp/lambda.c.jj	2018-06-16 08:49:51.377795726 +0200
+++ gcc/cp/lambda.c	2018-07-18 18:50:03.840040093 +0200
@@ -1214,8 +1214,7 @@ maybe_add_lambda_conv_op (tree type)
 
   /* Now build up the thunk to be returned.  */
 
-  name = get_identifier ("_FUN");
-  tree statfn = build_lang_decl (FUNCTION_DECL, name, stattype);
+  tree statfn = build_lang_decl (FUNCTION_DECL, fun_identifier, stattype);
   SET_DECL_LANGUAGE (statfn, lang_cplusplus);
   fn = statfn;
   DECL_SOURCE_LOCATION (fn) = DECL_SOURCE_LOCATION (callop);
--- gcc/cp/parser.c.jj	2018-07-18 12:00:22.907667232 +0200
+++ gcc/cp/parser.c	2018-07-18 18:50:46.361095022 +0200
@@ -10638,7 +10638,7 @@ cp_parser_lambda_declarator_opt (cp_pars
 	DECL_INITIALIZED_IN_CLASS_P (fco) = 1;
 	DECL_ARTIFICIAL (fco) = 1;
 	/* Give the object parameter a different name.  */
-	DECL_NAME (DECL_ARGUMENTS (fco)) = get_identifier ("__closure");
+	DECL_NAME (DECL_ARGUMENTS (fco)) = closure_identifier;
       }
     if (template_param_list)
       {
@@ -25341,13 +25341,13 @@ cp_parser_std_attribute (cp_parser *pars
 				   NULL_TREE);
       /* C++11 noreturn attribute is equivalent to GNU's.  */
       if (is_attribute_p ("noreturn", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* C++14 deprecated attribute is equivalent to GNU's.  */
       else if (is_attribute_p ("deprecated", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* C++17 fallthrough attribute is equivalent to GNU's.  */
       else if (is_attribute_p ("fallthrough", attr_id))
-	TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+	TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
       /* Transactional Memory TS optimize_for_synchronized attribute is
 	 equivalent to GNU transaction_callable.  */
       else if (is_attribute_p ("optimize_for_synchronized", attr_id))
@@ -25367,7 +25367,7 @@ cp_parser_std_attribute (cp_parser *pars
     vec<tree, va_gc> *vec;
     int attr_flag = normal_attr;
 
-    if (attr_ns == get_identifier ("gnu")
+    if (attr_ns == gnu_identifier
 	&& attribute_takes_identifier_p (attr_id))
       /* A GNU attribute that takes an identifier in parameter.  */
       attr_flag = id_attr;
@@ -25580,10 +25580,9 @@ cp_parser_std_attribute_spec (cp_parser
 
       /* Build the C++-11 representation of an 'aligned'
 	 attribute.  */
-      attributes =
-	build_tree_list (build_tree_list (get_identifier ("gnu"),
-					  get_identifier ("aligned")),
-			 alignas_expr);
+      attributes
+	= build_tree_list (build_tree_list (gnu_identifier,
+					    aligned_identifier), alignas_expr);
     }
 
   return attributes;
--- gcc/cp/class.c.jj	2018-07-16 23:24:23.326390997 +0200
+++ gcc/cp/class.c	2018-07-18 18:39:49.184244081 +0200
@@ -1517,8 +1517,7 @@ check_abi_tags (tree t, tree subob, bool
 	TREE_VALUE (attr) = chainon (data.tags, TREE_VALUE (attr));
       else
 	DECL_ATTRIBUTES (t)
-	  = tree_cons (get_identifier ("abi_tag"), data.tags,
-		       DECL_ATTRIBUTES (t));
+	  = tree_cons (abi_tag_identifier, data.tags, DECL_ATTRIBUTES (t));
     }
 
   mark_abi_tags (t, false);
@@ -1590,8 +1589,7 @@ inherit_targ_abi_tags (tree t)
 	TREE_VALUE (attr) = chainon (data.tags, TREE_VALUE (attr));
       else
 	TYPE_ATTRIBUTES (t)
-	  = tree_cons (get_identifier ("abi_tag"), data.tags,
-		       TYPE_ATTRIBUTES (t));
+	  = tree_cons (abi_tag_identifier, data.tags, TYPE_ATTRIBUTES (t));
     }
 
   mark_abi_tags (t, false);


	Jakub

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [C++ PATCH] Further get_identifier ("string literal") C++ FE caching
  2018-07-18 22:00         ` Nathan Sidwell
@ 2018-07-18 22:43           ` Jakub Jelinek
  2018-07-25 16:40             ` Nathan Sidwell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2018-07-18 22:43 UTC (permalink / raw)
  To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches

On Wed, Jul 18, 2018 at 06:00:20PM -0400, Nathan Sidwell wrote:
> So cool! Thanks.

Ok for both patches or just this one?

	Jakub

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [C++ PATCH] Further get_identifier ("string literal") C++ FE caching
  2018-07-18 22:43           ` Jakub Jelinek
@ 2018-07-25 16:40             ` Nathan Sidwell
  0 siblings, 0 replies; 54+ messages in thread
From: Nathan Sidwell @ 2018-07-25 16:40 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

On 07/18/2018 06:43 PM, Jakub Jelinek wrote:
> On Wed, Jul 18, 2018 at 06:00:20PM -0400, Nathan Sidwell wrote:
>> So cool! Thanks.
> 
> Ok for both patches or just this one?

both are ok, sorry for delay (vacation), thanks for doing that!

nathan

-- 
Nathan Sidwell

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
@ 2024-04-03  9:48 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2024-04-03  9:48 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
  2024-03-08  8:56 [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] Jakub Jelinek
@ 2024-03-25 18:27 ` Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2024-03-25 18:27 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

Hi!

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

Thanks.

	Jakub


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2024-03-06 14:12 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2024-03-06 14:12 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2023-09-19  7:19 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2023-09-19  7:19 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2022-03-02  9:46 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2022-03-02  9:46 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2021-09-01 20:11   ` Jakub Jelinek
@ 2021-09-01 21:46     ` Jason Merrill
  0 siblings, 0 replies; 54+ messages in thread
From: Jason Merrill @ 2021-09-01 21:46 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2021-09-01 19:25 ` Jason Merrill
@ 2021-09-01 20:11   ` Jakub Jelinek
  2021-09-01 21:46     ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2021-09-01 20:11 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2021-08-30  7:11 Jakub Jelinek
@ 2021-09-01 19:25 ` Jason Merrill
  2021-09-01 20:11   ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Jason Merrill @ 2021-09-01 19:25 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2021-08-30  7:11 Jakub Jelinek
  2021-09-01 19:25 ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2021-08-30  7:11 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
@ 2021-08-16 17:37 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2021-08-16 17:37 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
@ 2021-07-27 16:09 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2021-07-27 16:09 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ Patch ping
  2021-01-05 16:34 Jakub Jelinek
@ 2021-01-05 20:53 ` Jason Merrill
  0 siblings, 0 replies; 54+ messages in thread
From: Jason Merrill @ 2021-01-05 20:53 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

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.


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
@ 2021-01-05 16:34 Jakub Jelinek
  2021-01-05 20:53 ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2021-01-05 16:34 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

Hi!

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

Thanks

	Jakub


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2020-12-03 13:59 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2020-12-03 13:59 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2020-11-09 19:24 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2020-11-09 19:24 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

Hi!

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

Thanks
	Jakub


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2020-10-29 14:14 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2020-10-29 14:14 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch ping
@ 2020-03-16 15:45 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2020-03-16 15:45 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2019-11-18 15:32 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2019-11-18 15:32 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2018-12-04 14:47 Jakub Jelinek
@ 2018-12-06 21:43 ` Jason Merrill
  0 siblings, 0 replies; 54+ messages in thread
From: Jason Merrill @ 2018-12-06 21:43 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2018-12-04 14:47 Jakub Jelinek
  2018-12-06 21:43 ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2018-12-04 14:47 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2018-01-31 16:05 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2018-01-31 16:05 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2018-01-02 15:12 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2018-01-02 15:12 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2017-12-08 13:42 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2017-12-08 13:42 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2017-09-27 10:05 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2017-09-27 10:05 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2017-09-22 14:36 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2017-09-22 14:36 UTC (permalink / raw)
  To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2017-02-06 14:13 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2017-02-06 14:13 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2016-12-21 11:50 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2016-12-21 11:50 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ Patch Ping
  2016-12-15 12:38   ` Jakub Jelinek
@ 2016-12-15 12:48     ` Nathan Sidwell
  0 siblings, 0 replies; 54+ messages in thread
From: Nathan Sidwell @ 2016-12-15 12:48 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ Patch Ping
  2016-12-15 12:26 ` Nathan Sidwell
@ 2016-12-15 12:38   ` Jakub Jelinek
  2016-12-15 12:48     ` Nathan Sidwell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2016-12-15 12:38 UTC (permalink / raw)
  To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ Patch Ping
  2016-12-15  8:38 C++ Patch Ping Jakub Jelinek
@ 2016-12-15 12:26 ` Nathan Sidwell
  2016-12-15 12:38   ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Nathan Sidwell @ 2016-12-15 12:26 UTC (permalink / raw)
  To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ Patch Ping
@ 2016-12-15  8:38 Jakub Jelinek
  2016-12-15 12:26 ` Nathan Sidwell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2016-12-15  8:38 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2016-09-05 15:13 Jakub Jelinek
  0 siblings, 0 replies; 54+ messages in thread
From: Jakub Jelinek @ 2016-09-05 15:13 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-11 23:53         ` Jakub Jelinek
@ 2016-01-12  5:21           ` Jason Merrill
  0 siblings, 0 replies; 54+ messages in thread
From: Jason Merrill @ 2016-01-12  5:21 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Nathan Sidwell, gcc-patches

OK.

Jason

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-11 22:04       ` Jason Merrill
@ 2016-01-11 23:53         ` Jakub Jelinek
  2016-01-12  5:21           ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2016-01-11 23:53 UTC (permalink / raw)
  To: Jason Merrill; +Cc: Nathan Sidwell, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-11 21:52     ` Jakub Jelinek
@ 2016-01-11 22:04       ` Jason Merrill
  2016-01-11 23:53         ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Jason Merrill @ 2016-01-11 22:04 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Nathan Sidwell, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-11 21:45   ` Jason Merrill
@ 2016-01-11 21:52     ` Jakub Jelinek
  2016-01-11 22:04       ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2016-01-11 21:52 UTC (permalink / raw)
  To: Jason Merrill; +Cc: Nathan Sidwell, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-11 20:01 ` Nathan Sidwell
@ 2016-01-11 21:45   ` Jason Merrill
  2016-01-11 21:52     ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Jason Merrill @ 2016-01-11 21:45 UTC (permalink / raw)
  To: Nathan Sidwell, Jakub Jelinek; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2016-01-09  7:41 Jakub Jelinek
@ 2016-01-11 20:01 ` Nathan Sidwell
  2016-01-11 21:45   ` Jason Merrill
  0 siblings, 1 reply; 54+ messages in thread
From: Nathan Sidwell @ 2016-01-11 20:01 UTC (permalink / raw)
  To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2016-01-09  7:41 Jakub Jelinek
  2016-01-11 20:01 ` Nathan Sidwell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2016-01-09  7:41 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2008-04-28 20:43   ` Jakub Jelinek
@ 2008-04-28 20:59     ` Mark Mitchell
  0 siblings, 0 replies; 54+ messages in thread
From: Mark Mitchell @ 2008-04-28 20:59 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2008-04-28 20:43 ` Mark Mitchell
@ 2008-04-28 20:43   ` Jakub Jelinek
  2008-04-28 20:59     ` Mark Mitchell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2008-04-28 20:43 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2008-04-28 20:18 Jakub Jelinek
@ 2008-04-28 20:43 ` Mark Mitchell
  2008-04-28 20:43   ` Jakub Jelinek
  0 siblings, 1 reply; 54+ messages in thread
From: Mark Mitchell @ 2008-04-28 20:43 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2008-04-28 20:18 Jakub Jelinek
  2008-04-28 20:43 ` Mark Mitchell
  0 siblings, 1 reply; 54+ messages in thread
From: Jakub Jelinek @ 2008-04-28 20:18 UTC (permalink / raw)
  To: Jason Merrill, Mark Mitchell; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: C++ patch ping
  2005-02-11 14:44 Giovanni Bajo
@ 2005-02-18 12:21 ` Mark Mitchell
  0 siblings, 0 replies; 54+ messages in thread
From: Mark Mitchell @ 2005-02-18 12:21 UTC (permalink / raw)
  To: Giovanni Bajo; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

* C++ patch ping
@ 2005-02-11 14:44 Giovanni Bajo
  2005-02-18 12:21 ` Mark Mitchell
  0 siblings, 1 reply; 54+ messages in thread
From: Giovanni Bajo @ 2005-02-11 14:44 UTC (permalink / raw)
  To: gcc-patches; +Cc: Mark Mitchell

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

^ permalink raw reply	[flat|nested] 54+ messages in thread

end of thread, other threads:[~2024-04-03  9:48 UTC | newest]

Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-13 13:49 C++ patch ping Jakub Jelinek
2018-07-13 16:24 ` Nathan Sidwell
2018-07-13 16:53   ` Jakub Jelinek
2018-07-18 10:19     ` [C++ PATCH] Hide __for_{range,begin,end} symbols (PR c++/85515, take 2) Jakub Jelinek
2018-07-18 21:05       ` [C++ PATCH] Further get_identifier ("string literal") C++ FE caching Jakub Jelinek
2018-07-18 22:00         ` Nathan Sidwell
2018-07-18 22:43           ` Jakub Jelinek
2018-07-25 16:40             ` Nathan Sidwell
2018-07-13 16:42 ` C++ patch ping Nathan Sidwell
  -- strict thread matches above, loose matches on Subject: below --
2024-04-03  9:48 C++ Patch ping Jakub Jelinek
2024-03-08  8:56 [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] Jakub Jelinek
2024-03-25 18:27 ` C++ Patch ping Jakub Jelinek
2024-03-06 14:12 C++ patch ping Jakub Jelinek
2023-09-19  7:19 Jakub Jelinek
2022-03-02  9:46 Jakub Jelinek
2021-08-30  7:11 Jakub Jelinek
2021-09-01 19:25 ` Jason Merrill
2021-09-01 20:11   ` Jakub Jelinek
2021-09-01 21:46     ` Jason Merrill
2021-08-16 17:37 C++ Patch ping Jakub Jelinek
2021-07-27 16:09 Jakub Jelinek
2021-01-05 16:34 Jakub Jelinek
2021-01-05 20:53 ` Jason Merrill
2020-12-03 13:59 C++ patch ping Jakub Jelinek
2020-11-09 19:24 Jakub Jelinek
2020-10-29 14:14 Jakub Jelinek
2020-03-16 15:45 C++ Patch ping Jakub Jelinek
2019-11-18 15:32 C++ patch ping Jakub Jelinek
2018-12-04 14:47 Jakub Jelinek
2018-12-06 21:43 ` Jason Merrill
2018-01-31 16:05 Jakub Jelinek
2018-01-02 15:12 Jakub Jelinek
2017-12-08 13:42 Jakub Jelinek
2017-09-27 10:05 Jakub Jelinek
2017-09-22 14:36 Jakub Jelinek
2017-02-06 14:13 Jakub Jelinek
2016-12-21 11:50 Jakub Jelinek
2016-12-15  8:38 C++ Patch Ping Jakub Jelinek
2016-12-15 12:26 ` Nathan Sidwell
2016-12-15 12:38   ` Jakub Jelinek
2016-12-15 12:48     ` Nathan Sidwell
2016-09-05 15:13 C++ patch ping Jakub Jelinek
2016-01-09  7:41 Jakub Jelinek
2016-01-11 20:01 ` Nathan Sidwell
2016-01-11 21:45   ` Jason Merrill
2016-01-11 21:52     ` Jakub Jelinek
2016-01-11 22:04       ` Jason Merrill
2016-01-11 23:53         ` Jakub Jelinek
2016-01-12  5:21           ` Jason Merrill
2008-04-28 20:18 Jakub Jelinek
2008-04-28 20:43 ` Mark Mitchell
2008-04-28 20:43   ` Jakub Jelinek
2008-04-28 20:59     ` Mark Mitchell
2005-02-11 14:44 Giovanni Bajo
2005-02-18 12:21 ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).