[PATCH 5/5] openmp: -foffload-memory=pinned

From: Andrew Stubbs Implement the -foffload-memory=pinned option such that libgomp is instructed to enable fully-pinned memory at start-up. The option is intended to provide a performance boost to certain offload programs without modifying the code. This feature only works on Linux, at present,

[PATCH 4/5] openmp: Use libgomp memory allocation functions with unified shared memory.

This patches changes calls to malloc/free/calloc/realloc and operator new to memory allocation functions in libgomp with allocator=ompx_unified_shared_mem_alloc. This helps existing code to benefit from the unified shared memory. The libgomp does the correct thing with all the mapping constructs

[PATCH 3/5] openmp, nvptx: ompx_unified_shared_mem_alloc

From: Andrew Stubbs This adds support for using Cuda Managed Memory with omp_alloc. It will be used as the underpinnings for "requires unified_shared_memory" in a later patch. There are two new predefined allocators, ompx_unified_shared_mem_alloc and ompx_host_mem_alloc, plus corresponding memo

[PATCH 2/5] openmp: allow requires unified_shared_memory

From: Andrew Stubbs This is the front-end portion of the Unified Shared Memory implementation. It removes the "sorry, unimplemented message" in C, C++, and Fortran, and sets flag_offload_memory, but is otherwise inactive, for now. It also checks that -foffload-memory isn't set to an incompatible

[PATCH 1/5] openmp: Add -foffload-memory

From: Andrew Stubbs Add a new option. It will be used in follow-up patches. gcc/ChangeLog: * common.opt: Add -foffload-memory and its enum values. * coretypes.h (enum offload_memory): New. * doc/invoke.texi: Document -foffload-memory. --- gcc/common.opt | 16 +

[PATCH 0/5] openmp: Handle pinned and unified shared memory.

requires unified_shared_memory openmp, nvptx: ompx_unified_shared_mem_alloc openmp: -foffload-memory=pinned Hafiz Abid Qadeer (1): openmp: Use libgomp memory allocation functions with unified shared memory. gcc/c/c-parser.cc | 13 +- gcc/common.opt

[PATCH] [gfortran] Set omp_requires_mask for dynamic_allocators.

This patch fixes an issue that although gfortran accepts 'requires dynamic_allocators', it does not set the omp_requires_mask accordingly. gcc/fortran/ChangeLog: * parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS bit in omp_requires_mask. --- gcc/fortran/parse.cc |

[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

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 05/02/2022 19:09, Hafiz Abid Qadeer wrote: > On 04/02/2022 11:25, Hafiz Abid Qadeer wrote: >> On 04/02/2022 09:46, Thomas Schwinge wrote: >> >>> >>> Abid, are you going to address these? I think it does make sense if the >>> C/C++ and Fortran test ca

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 04/02/2022 11:25, Hafiz Abid Qadeer wrote: > On 04/02/2022 09:46, Thomas Schwinge wrote: > >> >> Abid, are you going to address these? I think it does make sense if the >> C/C++ and Fortran test cases match as much as feasible. >> > Sure. I will do that.

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

ait. So it makes sense to me to not have it in fortran testcase too. It also seems more cleaner than putting some limits on number of threads or increasing the size which will be a bit fragile. Thanks, -- Hafiz Abid Qadeer

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

read. > >   Location is global '' at 0x ([stack]+0x1ddc0) > >   Thread T10 (tid=4135398, running) created by main thread at: >     #0 pthread_create > ../../../../repos/gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 > (libtsan.so.2+0x62c76) >

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

an/allocate-1.f90:116 in > __m_MOD_foo._omp_fn.2 > > Tobias @Tobias: Thanks for your comments and the patch. @Thomas: Thanks for reporting the problem. Did you notice similar behavior with libgomp/testsuite/libgomp.c-c++-common/allocate-1.c? It was used as base for fortran testcase and it shows similar warnings with -fthread=sanitize. I am trying to figure out if the problem you observed is a general one or just specific to fortran testcase. -- Hafiz Abid Qadeer Mentor, a Siemens Business

[Committed] Change kind of integer literal to fix a testcase.

As Thomas reported in https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588448.html a test added in my recent allocate clause patch fails on m32. It was due to default kind for integer matching c_intptr_t for m32. I have now changed it to 0_1 so that always integer with kind=1 is used. gcc/te

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

lue, using c_intptr_t seems to make more sense than > restricting it to (l)l64. Problem was with the literal 0 having same kind as c_intptr_t for m32. So there was no diagnostic in that case. I am going to change it 0_1 to make the test more robust. Thanks, -- Hafiz Abid Qadeer Mentor, a Siemens Business

[PATCH 5/5] [gfortran] Lower allocate directive (OpenMP 5.0).

This patch looks for malloc/free calls that were generated by allocate statement that is associated with allocate directive and replaces them with GOMP_alloc and GOMP_free. gcc/ChangeLog: * omp-low.c (scan_sharing_clauses): Handle OMP_CLAUSE_ALLOCATOR. (scan_omp_allocate): New.

[PATCH 4/5] [gfortran] Gimplify allocate directive (OpenMP 5.0).

gcc/ChangeLog: * doc/gimple.texi: Describe GIMPLE_OMP_ALLOCATE. * gimple-pretty-print.c (dump_gimple_omp_allocate): New function. (pp_gimple_stmt_1): Call it. * gimple.c (gimple_build_omp_allocate): New function. * gimple.def (GIMPLE_OMP_ALLOCATE): New node.

[PATCH 3/5] [gfortran] Handle cleanup of omp allocated variables (OpenMP 5.0).

Currently we are only handling omp allocate directive that is associated with an allocate statement. This statement results in malloc and free calls. The malloc calls are easy to get to as they are in the same block as allocate directive. But the free calls come in a separate cleanup block. To h

[PATCH 2/5] [gfortran] Translate allocate directive (OpenMP 5.0).

gcc/fortran/ChangeLog: * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR. (gfc_trans_omp_allocate): New function. (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE. gcc/ChangeLog: * tree-pretty-print.c (dump_omp_clause): Handle OMP_CLAUSE_ALLOC

[PATCH 1/5] [gfortran] Add parsing support for allocate directive (OpenMP 5.0).

Currently we only make use of this directive when it is associated with an allocate statement. gcc/fortran/ChangeLog: * dump-parse-tree.c (show_omp_node): Handle EXEC_OMP_ALLOCATE. (show_code_node): Likewise. * gfortran.h (enum gfc_statement): Add ST_OMP_ALLOCATE.

[PATCH 0/5] [gfortran] Support for allocate directive (OpenMP 5.0)

statement to GOMP_alloc and GOMP_free calls. Hafiz Abid Qadeer (5): [gfortran] Add parsing support for allocate directive (OpenMP 5.0). [gfortran] Translate allocate directive (OpenMP 5.0). [gfortran] Handle cleanup of omp allocated variables (OpenMP 5.0). Gimplify allocate directive (OpenMP 5.0