Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
> 	* parse.cc (check_omp_allocate_stmt): Permit procedure pointers
> 	here (rejected later) for less mislreading diagnostic.

s/misl/mis/

> libgomp/ChangeLog:
> 
> 	* libgomp.texi:

Fill in something here.

> @@ -7220,8 +7227,7 @@ gfc_resolve_omp_allocate (gfc_namespace *ns, gfc_omp_namelist *list)
>  		     &n->where);
>  	  continue;
>  	}
> -      if (ns != n->sym->ns || n->sym->attr.use_assoc
> -	  || n->sym->attr.host_assoc || n->sym->attr.imported)
> +      if (ns != n->sym->ns || n->sym->attr.use_assoc ||  n->sym->attr.imported)

s/  n/ n/

> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -1400,23 +1400,53 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
>  			  "region must specify an %<allocator%> clause", t);
>  	      /* Skip for omp_default_mem_alloc (= 1),
>  		 unless align is present. */
> -	      else if (!errorcount
> -		       && (align != NULL_TREE
> -			   || alloc == NULL_TREE
> -			   || !integer_onep (alloc)))
> +	      else if (errorcount
> +		       || (align == NULL_TREE
> +			   && alloc != NULL_TREE
> +			   && integer_onep (alloc)))
> +		DECL_ATTRIBUTES (t) = remove_attribute ("omp allocate",
> +							DECL_ATTRIBUTES (t));

Probably already preexisting, by I wonder how safe remove_attribute is.
Aren't attributes shared in some cases
(like __attribute__((attr1, attr2, attr3)) int a, b, c, d;)?
Not really sure if something unshares them afterwards.
If they are shared, adding new attributes is fine, that will make the new
additions not shared and the tail shared, but remove_attribute could remove
it from all of them at once.  Perhaps I'm wrong, haven't verified.

Otherwise LGTM (though, I didn't spot anything about allocatables in the
patch, am I just looking wrong or are they still unsupported)?

	Jakub