Re: [PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends

Hi Thomas, Tobias, On 2023/10/26 6:43 PM, Thomas Schwinge wrote: > +++ b/gcc/tree.h > @@ -1813,6 +1813,14 @@ class auto_suppress_location_wrappers > #define OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE(NODE) \ > (OMP_CLAUSE_SUBCODE_CHECK (NODE, > OMP_CLAUSE_MAP)->base.addressabl

[PATCH, OpenACC 2.7] struct/array reductions for Fortran

nt state is okay to submit. Tested without regressions on mainline (on top of first struct/array reduction patch[1]) Thanks, Chung-Lin [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641669.html 2024-02-08 Chung-Lin Tang gcc/fortran/ChangeLog: * openmp.cc (oacc_reduction_

Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

On 2022/8/15 7:15 PM, Chung-Lin Tang wrote: On 2022/8/15 7:06 PM, Chung-Lin Tang wrote: I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran  interacts, but it's finally working. Again tested without regressions. Preparing to commit to  devel/omp/gcc-12, and se

Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

On 2022/8/15 7:06 PM, Chung-Lin Tang wrote: I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran  interacts, but it's finally working. Again tested without regressions. Preparing to commit to  devel/omp/gcc-12, and seeking approval for mainline when the req

[PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

or mainline when the requires patches are in. Thanks, Chung-Lin 2022-08-15 Chung-Lin Tang libgcc/ * Makefile.in (crtoffloadend$(objext)): Add $(PICFLAG) to compile rule. * offloadstuff.c (GOMP_offload_register_ver): Add declaration of weak symbol. (__OFFLOA

[PATCH, OpenMP, Fortran] requires unified_shared_memory 1/2: adjust libgfortran memory allocators

_alloc/omp_free/etc. when 'requires unified_shared_memory' is detected. Tested on devel/omp/gcc-12. Plans is to commit there soon, but also seeking approval for mainline once the requires stuff goes in. Thanks, Chung-Lin 2022-08-15 Chung-Lin Tang libgfortran/ChangeLog: *

[PATCH, Fortran] Fix setting of array lower bound for named arrays

This patch by Tobias, fixes a case of setting array low-bounds, found for particular uses of SOURCE=/MOLD=. For example: program A_M implicit none real, dimension (:), allocatable :: A, B allocate (A(0:5)) call Init (A) contains subroutine Init ( A ) real, dimension ( 0 : ), intent

Re: [PATCH, PR90030] Fortran OpenMP/OpenACC array mapping alignment fix

Ping. On 2021/11/4 4:23 PM, Chung-Lin Tang wrote: Hi Jakub, As Thomas reported and submitted a patch a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519932.html https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522738.html There's an issue with the Fortran front-end

[PATCH, v2, OpenMP 5.0] Remove array section base-pointer mapping semantics, and other front-end adjustments (mainline trunk)

p of the recent also posted C++ PR92120 v5 patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584602.html Again, tested without regressions (together with the PR92120 patch), awaiting review. Thanks, Chung-Lin (ChangeLog updated below) On 2021/5/25 9:36 PM, Chung-Lin Tang wrot

[PATCH, PR90030] Fortran OpenMP/OpenACC array mapping alignment fix

ly passed to libgomp during runtime, marks the passed array with an alignment of 1, which can cause mapping alignment errors on the offload target. This patch removes the related fold_convert(build_pointer_type (char_type_node)) calls in fortran/trans-openmp.c, and adds gcc_asserts to ensure pointe

Re: [PATCH, v2, OpenMP 5.2, Fortran] Strictly-structured block support for OpenMP directives

bles there (all initialized) or say an array and access different elements in the different spots. Jakub Thanks, attached is what I finally committed. Chung-Lin From 2e4659199e814b7ee0f6bd925fd2c0a7610da856 Mon Sep 17 00:00:00 2001 From: Chung-Lin Tang Date: Thu, 21 Oct 2021 14:5

[PATCH, v2, OpenMP 5.2, Fortran] Strictly-structured block support for OpenMP directives

r strictly-structured blocks has also been changed to "Y" in this patch. Tested without regressions, is this now okay for trunk? Thanks, Chung-Lin 2021-10-20 Chung-Lin Tang gcc/fortran/ChangeLog: * decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case toge

[PATCH, v2, OpenMP, Fortran] Support in_reduction for Fortran

uot; case in Fortran, where the task/target-in_reduction is in another separate subroutine. Tested without regressions on trunk, is this okay to commit? Thanks, Chung-Lin 2021-10-19 Chung-Lin Tang gcc/fortran/ChangeLog: * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp

Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives

On 2021/10/14 7:19 PM, Jakub Jelinek wrote: On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote: Thinking more about the Fortran case for !$omp sections, there is an ambiguity. !$omp sections block !$omp section end block is clear and !$omp end sections is optional,

[PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives

o (the new) COMP_OMP_STRICTLY_STRUCTURED_BLOCK after the statement is known (I'm not sure if there's a way to 'peek' the next statement/token in the Fortran FE, open to suggestions on how to better write this) Tested with no regressions on trunk, is this okay to commit? Thanks, Ch

[PATCH, OpenMP, Fortran] Support in_reduction for Fortran

trunk, is this okay? (testing for devel/omp/gcc-11 is in progress) Thanks, Chung-Lin 2021-09-17 Chung-Lin Tang gcc/fortran/ChangeLog: * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default false parameter. Add 'always,tofrom' map

[PATCH, OpenMP 5.0] Remove array section base-pointer mapping semantics, and other front-end adjustments (mainline trunk)

so you might queued this one later than those for review. Thanks, Chung-Lin 2021-05-25 Chung-Lin Tang gcc/c/ChangeLog: * c-parser.c (struct omp_dim): New struct type for use inside c_parser_omp_variable_list. (c_parser_omp_variable_list): Allow multiple levels of

Re: [PATCH 7/7] [og10] WIP GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION changes

On 2021/5/17 10:26 PM, Julian Brown wrote: OK, understood. But, I'm a bit concerned that we're ignoring some "hidden rules" with regards to OMP pointer clause ordering/grouping that certain code (at least the bit that creates GOMP_MAP_STRUCT node groups, and parts of omp-low.c) relies on. I belie

Re: [PATCH 7/7] [og10] WIP GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION changes

On 2021/5/11 4:57 PM, Julian Brown wrote: This work-in-progress patch tries to get GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups to be processed by build_struct_group/build_struct_comp_map. I think that's import

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

Hi Julian, On 2021/5/15 5:27 AM, Julian Brown wrote: 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. gcc/cp/ * semantics.c (finish_omp_clauses): Handle components of refer