[PATCH] Add a restriction on allocate clause (OpenMP 5.0)

An allocate clause in target region must specify an allocator unless the compilation unit has requires construct with dynamic_allocators clause. Current implementation of the allocate clause did not check for this restriction. This patch fills that gap. gcc/ChangeLog: * omp-low.cc (omp_m

[PATCH 8/8] OpenMP 5.0 "declare mapper" support for C++

This patch implements OpenMP 5.0 "declare mapper" support for C++ -- except for arrays of structs with mappers, which are TBD. I've taken cues from the existing "declare reduction" support where appropriate, though obviously the details of implementation differ somewhat (in particular, "declare map

[PATCH 6/8] OpenMP: lvalue parsing for map clauses (C)

This patch adds support for parsing general lvalues for OpenMP "map" clauses to the C front-end, similar to the previous patch for C++. This version of the patch fixes several omissions regarding non-DECL_P root terms in map clauses (i.e. "*foo" in "(*foo)->ptr->arr[:N]") -- similar to the cp/sema

[PATCH 7/8] Use OMP_ARRAY_SECTION instead of TREE_LIST in C++ FE

This patch changes the representation of OMP array sections in the C++ front end to use the new OMP_ARRAY_SECTION tree code instead of a TREE_LIST. This is important for "declare mapper" support, because the array section representation may stick around longer (in "declare mapper" definitions), an

[PATCH 5/8] OpenMP: lvalue parsing for map clauses (C++)

This patch changes parsing for OpenMP map clauses in C++ to use the generic expression parser, hence adds support for parsing general lvalues (as required by OpenMP 5.0+). So far only a few new types of expression are actually supported throughout compilation (including everything in the testsuite

[PATCH 4/8] OpenMP: Add inspector class to unify mapped address analysis

Several places in the C and C++ front-ends dig through OpenMP addresses from "map" clauses (etc.) in order to determine whether they are component accesses that need "attach" operations, check duplicate mapping clauses, and so on. When we're extending support for more kinds of lvalues in map claus

[PATCH 3/8] OpenMP/OpenACC struct sibling list gimplification extension and rework

This patch is a combination of several previously-posted patches, rebased and squashed together, and with a couple of additional bugfixes: "Rewrite GOMP_MAP_ATTACH_DETACH mappings unconditionally" https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585440.html "OpenMP/OpenACC: Move array_ref/

[PATCH 2/8] Remove omp_target_reorder_clauses

This patch has been split out from the previous one to avoid a confusingly-interleaved diff. The two patches should probably be committed squashed together. 2021-10-01 Julian Brown gcc/ * gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete. --- gcc/gimplify.cc | 207 ---

[PATCH 1/8] OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by base pointer)

This patch reimplements the omp_target_reorder_clauses function in anticipation of supporting "deeper" struct mappings (that is, with several structure dereference operators, or similar). The idea is that in place of the (possibly quadratic) algorithm in omp_target_reorder_clauses that greedily mo

[PATCH 0/8] OpenMP 5.0: C++ "declare mapper" support (plus struct rework, etc.)

Hi, This patch contains rebased/slightly bug-fixed versions of the patches previously posted in the series: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585439.html plus a new implementation of "declare mapper" support for C++. This can't be committed now, but posting now so others (m

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Harald and Thomas, Thank you for your contributions to understanding the interpretation by different vendors of the F2018 requirements for finalization. While it does appear to be rather chaotic, the differences are down to a small number of "features" of each compiler. Before describing my in