Hi,
I'd like to ping the patch for the OpenMP 'has_device_addr' clause on
the target construct:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585361.html
Thanks
Marcel
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellscha
Hi Jakub,
+case OMP_CLAUSE_HAS_DEVICE_ADDR:
+ t = OMP_CLAUSE_DECL (c);
+ if (TREE_CODE (t) == TREE_LIST)
+{
+ if (handle_omp_array_sections (c, ort))
+remove = true;
+ else
+{
+ t = OMP_CLAUSE_DECL (c);
+ w
Hi,
This patch adds two new OpenMP runtime routines: omp_target_memcpy_async and
omp_target_memcpy_rect_async. Both functions are introduced in OpenMP 5.1 as
asynchronous variants of omp_target_memcpy and omp_target_memcpy_rect.
In contrast to the synchronous variants, the asynchronous functions
Hi,
This patch adds the OpenMP runtime routine "omp_get_mapped_ptr" which was
introduced in OpenMP 5.1 (specification section 3.8.11):
"The omp_get_mapped_ptr routine returns the device pointer that is associated
with a host pointer for a given device."
"The device_num argument must be greater
Hi Jakub,
This is an update to the patch from Tue Mar 8:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591343.html
I just added "get_mapped_ptr" to the "omp_runtime_apis" array in omp-low.cc and
replaced "omp_get_num_devices" by "gomp_get_num_devices" in target.c.
Marcel
---
Hi,
This patch adds the OpenMP runtime routine "omp_target_is_accessible" which was
introduced in OpenMP 5.1 (specification section 3.8.4):
"The omp_target_is_accessible routine tests whether host memory is accessible
from a given device."
"This routine returns true if the storage of size bytes
Hi Tobias,
Minor remark to the test:
On 11.03.22 13:30, Marcel Vollweiler wrote:
+ int d = omp_get_default_device ();
...
+ int shared_mem = 0;
+ #pragma omp target map (alloc: shared_mem) device (d)
+shared_mem = 1;
+ if (omp_target_is_accessible (p, sizeof (int), d) != shared_mem
Hi,
This patch fixes a small bug for omp_set_num_teams in fortran.c.
Marcel
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: Mün
Hi Jakub,
! { dg-do run }
! { dg-additional-options "-fdefault-integer-8" }
program set_num_teams_8
use omp_lib
omp_set_num_teams (42)
if (omp_get_num_teams () .ne. 42) stop 1
end program
I modified your suggested test case a bit:
program set_num_teams_8
use omp_lib
use, intrins
Hi Jakub,
Am 05.05.2022 um 11:33 schrieb Jakub Jelinek:
On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -226,6 +226,11 @@ OMP_5.1 {
omp_get_teams_thread_limit_;
} OMP_5.0.2;
+OMP_5.1.1 {
+ global
Hi,
This is a follow up patch of the patch that adds the OpenMP runtime routine
omp_target_is_accessible:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591601.html
It considers now also unified shared memory (usm) that was submitted recently
(but not yet approved/committed):
https:
Hi Jakub,
Am 17.05.2022 um 20:08 schrieb Jakub Jelinek:
On Tue, May 17, 2022 at 11:57:02AM +0200, Marcel Vollweiler wrote:
More importantly, I have no idea how this can work when you pass arg_size 0
and arg_align 0. The s variable is in the current function frame, with
arg_size 0 nothing is
Hi,
This patch adds handling for the map-type-modifier 'close' in the map
clause in the Fortran parser (for C and C++ parsers the changes were
already committed).
'close' was introduced with OpenMP 5.0: "The close map-type-modifier is
a hint to the runtime to allocate memory close to the target
Hi Jakub,
Am 20.05.2021 um 10:57 schrieb Jakub Jelinek:
On Thu, May 20, 2021 at 10:47:52AM +0200, Marcel Vollweiler wrote:
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1710,10 +1710,21 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
omp_mask mask,
&& g
This patch adds device-modifiers to the device clause:
#pragma omp target device ([ device-modifier :] integer-expression)
where device-modifier is either 'ancestor' or 'device_num'.
The 'device_num' case
#pragma omp target device (device_num : integer-expression)
is treated in the same
09:18:32PM +0200, Marcel Vollweiler wrote:
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -15864,37 +15864,81 @@ c_parser_omp_clause_map (c_parser *parser, tree list)
}
/* OpenMP 4.0:
- device ( expre
Am 01.09.2021 um 11:02 schrieb Jakub Jelinek:
On Wed, Sep 01, 2021 at 09:06:31AM +0200, Christophe Lyon wrote:
* gfortran.dg/gomp/target-device-ancestor-4.f90: New test.
The last new test fails on aarch64:
/gcc/testsuite/gfortran.dg/gomp/target-device-ancestor-4.f90:7:15: Error:
S
Hi,
this patch adds support for the 'seq_cst' memory order clause on the
'flush' directive which was introduced in OpenMP 5.1 (p.275ff of the
OpenMP 5.1 Specification):
"If neither memory-order-clause nor a list appears on the flush
construct then the behavior is as if memory-order-clause is seq
Hi,
The variable omp_atv_sequential was replaced by omp_atv_serialized in
OpenMP 5.1. This was already implemented by Jakub (C/C++, commit
ea82325afec) and Tobias (Fortran, commit fff15bad1ab).
This patch adds two tests to check if omp_atv_serialized is available
(one test for C/C++ and one for
Hi Jakub,
Am 11.10.2021 um 11:49 schrieb Jakub Jelinek:
On Mon, Oct 11, 2021 at 11:40:54AM +0200, Marcel Vollweiler wrote:
libgomp: Add tests for omp_atv_serialized and deprecate omp_atv_sequential.
The variable omp_atv_sequential was replaced by omp_atv_serialized in OpenMP
5.1. This was
Hi Jakub,
this is again a new version of the 'has_device_addr' patch. It includes
further minor changes in the C/C++ part and in addition the Fortran
implementation.
Tested on x86_64-linux with nvptx offloading with no regressions.
Marcel
-
Siemens Electronic Design Automation G
21 matches
Mail list logo
