This patch implements "omp declare mapper" functionality for Fortran,
following the equivalent support for C and C++. This version of the
patch has been merged to og13 and contains various fixes for e.g.:
* Mappers with deferred-length strings
* Array descriptors not being appropriately tran
This patch adds support for parsing general lvalues ("locator list item
types") for OpenMP "map", "to" and "from" clauses to the C front-end,
similar to the previously-posted patch for C++.
2023-06-30 Julian Brown
gcc/c/
* c-pretty-print.cc (c_pretty_printer::postfix_expression,
This patch adds support for "declare mapper" directives (and the "mapper"
modifier on "map" clauses) for C.
2023-06-30 Julian Brown
gcc/c/
* c-decl.cc (c_omp_mapper_id, c_omp_mapper_decl, c_omp_mapper_lookup,
c_omp_extract_mapper_directive, c_omp_map_array_section,
c_om
This patch adds support for OpenMP 5.0 "declare mapper" functionality
for C++. I've merged it to og13 based on the last version
posted upstream, with some minor changes due to the newly-added
'present' map modifier support. There's also a fix to splay-tree
traversal in gimplify.cc:omp_instantiate
This patch fixes two more cases where an unmapped target pointer results
in a null pointer on the target instead of a copy of the host pointer.
The latter behaviour is required by OpenMP 5.2, which is a change from
earlier versions of the standard. This change has already been made in
one place by
This patch series provides generalised lvalue ("locator list item")
parsing for OpenMP "map", "to" and "from" clauses for C and C++, and
"declare mapper" support for C, C++ and Fortran. It is based on the
latter part of the patch series sent upstream previously:
https://gcc.gnu.org/pipermail/gc
This patch fixes a couple of minor merge/formatting errors.
2023-06-30 Julian Brown
gcc/fortran/
* parse.cc (decode_omp_directive): Add missing break.
gcc/
* gimplify.cc (gimplify_adjust_omp_clauses): Fix indentation.
---
gcc/fortran/parse.cc | 1 +
gcc/gimplify.cc | 4 +
Hi All,
I have gone through the PDT problem reports and made sure that they
block PR82173.
To my utter astonishment (i) There might be only one duplicate; and
(ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of
50 PRs) depend on the representation.
Regards
Paul
