[PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

[PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

[Jakub Jelinek]

Hi!

If there are _Atomic side-effects in the parameter declarations
of non-nested function, when they are parsed, current_function_decl is
NULL, the create_artificial_label created labels during build_atomic* are
then adjusted by store_parm_decls through set_labels_context_r callback.
Unfortunately, if such thing happens in nested function parameter
declarations, while those decls are parsed current_function_decl is the
parent function (and am not sure it is a good idea to temporarily clear it,
some code perhaps should be aware it is in a nested function, or it can
refer to variables from the parent function etc.) and that means
store_param_decls through set_labels_context_r doesn't adjust anything.
As those labels are emitted in the nested function body rather than in the
parent, I think it is ok to override the context in those cases.

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

2020-04-30  Jakub Jelinek  <jakub@redhat.com>

	PR c/94842
	* c-decl.c (set_labels_context_r): In addition to context-less
	LABEL_DECLs adjust also LABEL_DECLs with context equal to
	parent function if any.
	(store_parm_decls): Adjust comment.

	* gcc.dg/pr94842.c: New test.

--- gcc/c/c-decl.c.jj	2020-04-08 11:59:23.726461457 +0200
+++ gcc/c/c-decl.c	2020-04-30 12:19:35.918946543 +0200
@@ -9722,15 +9722,18 @@ store_parm_decls_from (struct c_arg_info
   store_parm_decls ();
 }
 
-/* Called by walk_tree to look for and update context-less labels.  */
+/* Called by walk_tree to look for and update context-less labels
+   or labels with context in the parent function.  */
 
 static tree
 set_labels_context_r (tree *tp, int *walk_subtrees, void *data)
 {
+  tree ctx = static_cast<tree>(data);
   if (TREE_CODE (*tp) == LABEL_EXPR
-      && DECL_CONTEXT (LABEL_EXPR_LABEL (*tp)) == NULL_TREE)
+      && (DECL_CONTEXT (LABEL_EXPR_LABEL (*tp)) == NULL_TREE
+	  || DECL_CONTEXT (LABEL_EXPR_LABEL (*tp)) == DECL_CONTEXT (ctx)))
     {
-      DECL_CONTEXT (LABEL_EXPR_LABEL (*tp)) = static_cast<tree>(data);
+      DECL_CONTEXT (LABEL_EXPR_LABEL (*tp)) = ctx;
       *walk_subtrees = 0;
     }
 
@@ -9800,7 +9803,11 @@ store_parm_decls (void)
 	 gotos, labels, etc.  Because at that time the function decl
 	 for F has not been created yet, those labels do not have any
 	 function context.  But we have the fndecl now, so update the
-	 labels accordingly.  gimplify_expr would crash otherwise.  */
+	 labels accordingly.  gimplify_expr would crash otherwise.
+	 Or with nested functions the labels could be created with parent
+	 function's context, while when the statement is emitted at the
+	 start of the nested function, it needs the nested function's
+	 context.  */
       walk_tree_without_duplicates (&arg_info->pending_sizes,
 				    set_labels_context_r, fndecl);
       add_stmt (arg_info->pending_sizes);
--- gcc/testsuite/gcc.dg/pr94842.c.jj	2020-04-30 12:25:52.431360645 +0200
+++ gcc/testsuite/gcc.dg/pr94842.c	2020-04-30 12:24:47.522323298 +0200
@@ -0,0 +1,11 @@
+/* PR c/94842 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+_Atomic float x = 5;
+
+void
+foo (void)
+{
+  void bar (float y[(int) (x += 2)]) {}
+}

	Jakub

Re: [PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

[Joseph Myers]

On Thu, 30 Apr 2020, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> If there are _Atomic side-effects in the parameter declarations
> of non-nested function, when they are parsed, current_function_decl is
> NULL, the create_artificial_label created labels during build_atomic* are
> then adjusted by store_parm_decls through set_labels_context_r callback.
> Unfortunately, if such thing happens in nested function parameter
> declarations, while those decls are parsed current_function_decl is the
> parent function (and am not sure it is a good idea to temporarily clear it,
> some code perhaps should be aware it is in a nested function, or it can
> refer to variables from the parent function etc.) and that means
> store_param_decls through set_labels_context_r doesn't adjust anything.
> As those labels are emitted in the nested function body rather than in the
> parent, I think it is ok to override the context in those cases.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com