Hi Tobias,
just a question:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 8231bd255d6..2586c6d7a79 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -821,6 +821,23 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
set_decl_tls_model (decl, decl_default_tls_model (decl));
+ if (sym->attr.omp_allocate && TREE_STATIC (decl))
+ {
+ struct gfc_omp_namelist *n;
+ for (n = sym->ns->omp_allocate; n; n = n->next)
+ if (n->sym == sym)
+ break;
Theoretically n can be NULL here. This would then ICE. Or is there a guarantee,
that n is never NULL
+ tree alloc = gfc_conv_constant_to_tree (n->u2.allocator);
<snipp>
I just looked at the fortran part.
Thanks for the patch and regards,
Andre
On Mon, 7 Oct 2024 10:47:56 +0200
Tobias Burnus <tbur...@baylibre.com> wrote:
> Now committed as r15-4104-ga8caeaacf499d5.
>
> With a wording improvement in the commit log and avoiding an XPASS for
> C++ by excluding c++98 from the xfail in dg-bogus... xfail.
>
> Tobias
>
> Tobias Burnus wrote:
> > 'omp allocate' permits to use a different (specified) allocator and
> > alignment for both stack/automatic and static/saved variables; the latter
> > takes only predefined allocators. Currently, only C and Fortran are
> > support for stack/automatic variables; static variables are rejected
> > before the attached patch. (For them, only predefined allocators are
> > permitted.)
> >
> > * * *
> >
> > I happened to look at the 'allocate' directive recently and, doing so,
> > I stumbled over a couple of issues, which the attached patch addresses
> > (missing diagnostics for corner cases, not updated checks, unhelpful
> > documentation ['allocate' *clause*], ...). Doing so, I wondered whether:
> >
> > Shouldn't we just accept 'omp allocate' for static
> > variables by just honoring the aligning and ignoring the actually
> > requested
> > allocator? - First, we do already the same for actual allocations as
> > not all
> > traits are supported. And for the host this seems to be the most
> > sensible to
> > do in any case.
> > [For some use cases, pointers + allocation in the constructor would be
> > better, but in general, not adding an indirection seems to be better and
> > has fewer corner-case usability issue.]
> >
> > I guess we later want to honor the requested memory for nvptx and/or
> > gcn; at
> > least Nvidia GPUs could make use for constant memory (having
> > advantages for
> > reading the same memory by many threads/broadcasting it). I guess
> > OpenACC 2.7's
> > 'readonly' modifier serves a similar purpose.
> > For now we don't, but the attribute is passed on to the backends,
> > which could
> > make use of them, if desired. ('groupprivate' directive vs. cgroup/thread
> > allocators are similar device-only features.)
> >
> > As mentioned, this patch also fixes a few other issues here and there,
> > see
> > commit log and source code for details.
> >
> > Code comments? Suggestions or remarks? - Before I apply this patch?
> >
> > Tobias
> >
> > PS: I am aware that C++ support is lacking. There is a pending patch
> > that needs
> > to be updated for this patch, probably some bitrotting, and in
> > particular for the
> > review comments, cf.
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633782.html
> > and https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639929.html
--
Andre Vehreschild * Email: vehre ad gmx dot de
