[Patch] Fortran/OpenMP: Improve associate-name diagnostic [PR103039]

This patch addresses a side issue found when looking at PR103039. Namely instead of printing: 55 | !$omp parallel firstprivate(tt) | 1 Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FIRSTPRIVATE clause at (1) With the patch, the error is: Error: Associate na

Re: [Patch] Fortran/OpenMP: Improve associate-name diagnostic [PR103039]

On Fri, Mar 18, 2022 at 02:15:11PM +0100, Tobias Burnus wrote: > This patch addresses a side issue found when looking at PR103039. > > Namely instead of printing: > >55 | !$omp parallel firstprivate(tt) > | 1 > Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FI

[PATCH v2 00/11] OpenMP 5.0: C & C++ "declare mapper" support (plus struct rework, etc.)

Hi Jakub, This is a new version of the series posted here: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590582.html Again, this isn't for committing now (it's definitely stage 1 material) but I'm posting now for comments on the general approach (to any of the contained parts) and to

[PATCH v2 02/11] 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 (omp_target_reorder_clauses): Delete. --- gcc/gimplify.cc | 207 -

[PATCH v2 01/11] 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 v2 03/11] 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 v2 04/11] OpenMP/OpenACC: Add inspector class to unify mapped address analysis

Several places in the C and C++ front-ends dig through OpenMP and OpenACC 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

[PATCH v2 05/11] OpenMP: Handle reference-typed struct members

This patch relates to OpenMP mapping clauses containing struct members of reference type, e.g. "mystruct.myref.myptr[:N]". To be able to access the array slice through the reference in the middle, we need to perform an attach action for that reference, since it is represented internally as a point

[PATCH v2 06/11] 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 v2 07/11] 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 has been adjusted for changes to the address inspector patch, but is otherwise the same as the last posted version. 2022-03-17 Julian

[PATCH v2 08/11] 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] Fortran/OpenMP: Improve associate-name diagnostic [PR103039]

SELECT TYPE, SELECT RANK and ASSOCIATE have associate-name => selector and create a pointer to the selector. GCC was fixed to handle CLASS properly in class(t) :: var !$omp ... firstprivate(var) As a side effect, firstprivate(assoc_name) now also gets handled that way, effectively trying to

[PATCH v2 09/11] 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 v2 10/11] OpenMP: Use OMP_ARRAY_SECTION instead of TREE_LIST for array sections in C FE

This patch uses the new OMP_ARRAY_SECTION tree code to represent OpenMP array sections, rather than TREE_LIST. As for the C++ FE, using TREE_LIST becomes unwieldy when the array-section representation sticks around for longer due to adding "declare mapper" support. We must be a little careful her

[PATCH v2 11/11] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

This patch adds support for "declare mapper" directives (and the "mapper" modifier on "map" clauses) for C. As for C++, arrays of custom-mapped objects are not supported yet. I've taken hints from the existing C support for "declare reduction" directives: this works a little differently from C++

Re: [Patch] Fortran/OpenMP: Improve associate-name diagnostic [PR103039]

On Fri, Mar 18, 2022 at 05:27:02PM +0100, Tobias Burnus wrote: > SELECT TYPE, SELECT RANK and ASSOCIATE have > associate-name => selector > and create a pointer to the selector. > > GCC was fixed to handle CLASS properly in > class(t) :: var > !$omp ... firstprivate(var) > As a side effect,