[Patch] Fortran/OpenMP: Handle implicit SAVE for variables in main

Found when working on another patch. Variables in the specification part of a module – but also in a main program are implicitly SAVE. Likewise for variables with initialization - but that was already handled. OK for mainline and GCC 11? Tobias - Mentor Graphics (Deutschland) G

[Patch] Fortran/OpenMP: Support 'omp parallel master'

(Testcase requires just posted "Fortran/OpenMP: Handle implicit SAVE for variables in main" patch.) (Found when looking the testcases generated for PR 99928 but otherwise not related to that PR.) "omp parallel master" was unsupported; while the it becomes more useful once taskloop is also supp

Re: [Patch] Fortran/OpenMP: Support 'omp parallel master'

On Fri, May 14, 2021 at 06:15:15PM +0200, Tobias Burnus wrote: > (Testcase requires just posted "Fortran/OpenMP: Handle > implicit SAVE for variables in main" patch.) > (Found when looking the testcases generated for PR 99928 > but otherwise not related to that PR.) > > > "omp parallel master"

Re: [Patch] Fortran/OpenMP: Handle implicit SAVE for variables in main

On Fri, May 14, 2021 at 06:13:55PM +0200, Tobias Burnus wrote: > Found when working on another patch. Variables in the specification > part of a module – but also in a main program are implicitly SAVE. > > Likewise for variables with initialization - but that was already > handled. > > OK for mai

[PATCH 0/5] OpenACC/OpenMP: Rework struct component handling

Hi, This patch series reworks how indirect struct (or class or derived-type) component mappings are lowered for OpenMP and OpenACC. I previously posted this against the og10 branch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570058.html This version of the series, rebased to trunk, in

[PATCH 1/5] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset

For historical reasons, it seems that extract_base_bit_offset unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF nodes from component accesses. I verified that the two ways of performing the operation gave the same results across the whole testsuite (and several additional benchm

[PATCH 2/5] Refactor struct lowering for OpenMP/OpenACC in gimplify.c

This patch is a second attempt at refactoring struct component mapping handling for OpenACC/OpenMP during gimplification, after the patch I posted here: https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html And improved here, post-review: https://gcc.gnu.org/pipermail/gcc-patch

[PATCH 3/5] Rewrite GOMP_MAP_ATTACH_DETACH mappings for OpenMP also

It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive beyond gimplify.c, and with OpenMP making use of that mapping type too now alongside OpenACC, there are cases where it was making it through to omp-low.c. This patch rewrites such mappings to GOMP_MAP_ATTACH or GOMP_MAP_DETACH un

[PATCH 4/5] Rework indirect struct handling for OpenACC/OpenMP in gimplify.c

This patch reworks indirect struct handling in gimplify.c (i.e. for struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.), for both OpenACC and OpenMP. The key observation leading to these changes was that component mappings of references-to-structures is already implemented and w

[PATCH 5/5] Mapping of components of references to pointers to structs for OpenMP/OpenACC

GCC currently raises a parse error for indirect accesses to struct members, where the base of the access is a reference to a pointer. This patch fixes that case. OK for trunk? Thanks, Julian 2021-05-14 Julian Brown gcc/cp/ * semantics.c (finish_omp_clauses): Handle components of ref