From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0C2FE3857718 for ; Fri, 13 Oct 2023 11:01:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C2FE3857718 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697194900; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=XUI4B2qNkRS9mnUquEKbWx0oDZwPVbrmxYpMAFcGBg0=; b=c4fX5VkmnKfuvNdEYc87h6Yyc1qoCWouvHbXd4PVTMPz9igPPhUmk/+PDazF+i7KWdNf75 oA5iolbrNyFajI6jN74QAk5i6SGrob71DlqcfSIfep7DnKYM3GxOTSmteM+cyq+PmHoTC3 lxVxDKAZo2DrjDkWH/1QYd8FPA0wZME= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-513-UNjVOsyIM4OrMgHzi-o9ug-1; Fri, 13 Oct 2023 07:01:22 -0400 X-MC-Unique: UNjVOsyIM4OrMgHzi-o9ug-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 495961029F43; Fri, 13 Oct 2023 11:01:22 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E8C4B202701E; Fri, 13 Oct 2023 11:01:21 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 39DB1JwJ988507 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 13 Oct 2023 13:01:19 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 39DB1IVP988506; Fri, 13 Oct 2023 13:01:18 +0200 Date: Fri, 13 Oct 2023 13:01:17 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches , fortran Subject: Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars Message-ID: Reply-To: Jakub Jelinek References: <457ea120-5cca-48e0-89d6-c3eab4234b61@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <457ea120-5cca-48e0-89d6-c3eab4234b61@codesourcery.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 % 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