From: Jakub Jelinek <jakub@redhat.com>
To: Julian Brown <julian@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org,
tobias@codesourcery.com, cltang@codesourcery.com
Subject: Re: [PATCH v3 08/11] OpenMP/OpenACC: Rework clause expansion and nested struct handling
Date: Wed, 14 Sep 2022 15:24:12 +0200 [thread overview]
Message-ID: <YyHV0/LuuYIRADLE@tucnak> (raw)
In-Reply-To: <e1d4786dbfd1f5cd31f809dfc713478e44c5232b.1663101299.git.julian@codesourcery.com>
On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> This patch is an extension and rewrite/rethink of the following two patches:
>
> "OpenMP/OpenACC: Add inspector class to unify mapped address analysis"
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591977.html
>
> "OpenMP: Handle reference-typed struct members"
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591978.html
>
> The latter was reviewed here by Jakub:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595510.html with the
>
> with the comment,
>
> > Why isn't a reference to pointer handled that way too?
>
> and that opened a whole can of worms... generally, C++ references were
> not handled very consistently after the clause-processing code had been
> extended several times already for both OpenACC and OpenMP, and many
> cases of using C++ (and Fortran) references were broken. Even some
> cases not involving references were being mapped incorrectly.
>
> At present a single clause may be turned into several mapping nodes,
> or have its mapping type changed, in several places scattered through
> the front- and middle-end. The analysis relating to which particular
> transformations are needed for some given expression has become quite hard
> to follow. Briefly, we manipulate clause types in the following places:
>
> 1. During parsing, in c_omp_adjust_map_clauses. Depending on a set of
> rules, we may change a FIRSTPRIVATE_POINTER (etc.) mapping into
> ATTACH_DETACH, or mark the decl addressable.
>
> 2. In semantics.cc or c-typeck.cc, clauses are expanded in
> handle_omp_array_sections (called via {c_}finish_omp_clauses, or in
> finish_omp_clauses itself. The two cases are for processing array
> sections (the former), or non-array sections (the latter).
>
> 3. In gimplify.cc, we build sibling lists for struct accesses, which
> groups and sorts accesses along with their struct base, creating
> new ALLOC/RELEASE nodes for pointers.
>
> 4. In gimplify.cc:gimplify_adjust_omp_clauses, mapping nodes may be
> adjusted or created.
>
> This patch doesn't completely disrupt this scheme, though clause
> types are no longer adjusted in c_omp_adjust_map_clauses (step 1).
> Clause expansion in step 2 (for C and C++) now uses a single, unified
> mechanism, parts of which are also reused for analysis in step 3.
>
> Rather than the kind-of "ad-hoc" pattern matching on addresses used to
> expand clauses used at present, a new method for analysing addresses is
> introduced. This does a recursive-descent tree walk on expression nodes,
> and emits a vector of tokens describing each "part" of the address.
> This tokenized address can then be translated directly into mapping nodes,
> with the assurance that no part of the expression has been inadvertently
> skipped or misinterpreted. In this way, all the variations of ways
> pointers, arrays, references and component accesses can be teased apart
> into easily-understood cases - and we know we've "parsed" the whole
> address before we start analysis, so the right code paths can easily
> be selected.
>
> For example, a simple access "arr[idx]" might parse as:
>
> base-decl access-indexed-array
>
> or "mystruct->foo[x]" with a pointer "foo" component might parse as:
>
> base-decl access-pointer component-selector access-pointer
>
> A key observation is that support for "array" bases, e.g. accesses
> whose root nodes are not structures, but describe scalars or arrays,
> and also *one-level deep* structure accesses, have first-class support
> in gimplify and beyond. Expressions that use deeper struct accesses
> or e.g. multiple indirections were more problematic: some cases worked,
> but lots of cases didn't. This patch reimplements the support for those
> in gimplify.cc, again using the new "address tokenization" support.
>
> An expression like "mystruct->foo->bar[0:10]" used in a mapping node will
> translate the right-hand access directly in the front-end. The base for
> the access will be "mystruct->foo". This is handled recursively -- there
> may be several accesses of "mystruct"'s members on the same directive,
> so the sibling-list building machinery can be used again. (This was
> already being done for OpenACC, but the new implementation differs
> somewhat in details, and is more robust.)
>
> For OpenMP, in the case where the base pointer itself,
> i.e. "mystruct->foo" here, is NOT mapped on the same directive, we
> create a "fragile" mapping. This turns the "foo" component access
> into a zero-length allocation (which is a new feature for the runtime,
> so support has been added there too).
>
> A couple of changes have been made to how mapping clauses are turned
> into mapping nodes:
>
> The first change is based on the observation that it is probably never
> correct to use GOMP_MAP_ALWAYS_POINTER for component accesses (e.g. for
> references), because if the containing struct is already mapped on the
> target then the host version of the pointer in question will be corrupted
> if the struct is copied back from the target. This patch removes all
> such uses, across each of C, C++ and Fortran.
>
> The second change is to the way that GOMP_MAP_ATTACH_DETACH nodes
> are processed during sibling-list creation. For OpenMP, for pointer
> components, we must map the base pointer separately from an array section
> that uses the base pointer, so e.g. we must have both "map(mystruct.base)"
> and "map(mystruct.base[0:10])" mappings. These create nodes such as:
>
> GOMP_MAP_TOFROM mystruct.base
> G_M_TOFROM *mystruct.base [len: 10*elemsize] G_M_ATTACH_DETACH mystruct.base
>
> Instead of using the first of these directly when building the struct
> sibling list then skipping the group using GOMP_MAP_ATTACH_DETACH,
> leading to:
>
> GOMP_MAP_STRUCT mystruct [len: 1] GOMP_MAP_TOFROM mystruct.base
>
> we now introduce a new "mini-pass", omp_resolve_clause_dependencies, that
> drops the GOMP_MAP_TOFROM for the base pointer, marks the second group
> as having had a base-pointer mapping, then omp_build_struct_sibling_lists
> can create:
>
> GOMP_MAP_STRUCT mystruct [len: 1] GOMP_MAP_ALLOC mystruct.base [len: ptrsize]
>
> This ends up working better in many cases, particularly those involving
> references. (The "alloc" space is immediately overwritten by a pointer
> attachment, so this is mildly more efficient than a redundant TO mapping
> at runtime also.)
>
> There is support in the address tokenizer for "arbitrary" base expressions
> which aren't rooted at a decl, but that is not used as present because
> such addresses are disallowed at parse time.
>
> In the front-ends, the address tokenization machinery is mostly only
> used for clause expansion and not for diagnostics at present. It could
> be used for those too, which would allow more of my previous "address
> inspector" implementation to be removed.
>
> The new bits in gimplify.cc work with OpenACC also.
>
> 2022-09-13 Julian Brown <julian@codesourcery.com>
>
> gcc/c-family/
> * c-common.h (omp_addr_token): Add forward declaration.
> (c_omp_address_inspector): New class.
> * c-omp.c (c_omp_adjust_map_clauses): Mark decls addressable here, but
> do not change any mapping node types.
> (c_omp_address_inspector::unconverted_ref_origin,
> c_omp_address_inspector::component_access_p,
> c_omp_address_inspector::check_clause,
> c_omp_address_inspector::get_root_term,
> c_omp_address_inspector::map_supported_p,
> c_omp_address_inspector::get_origin,
> c_omp_address_inspector::maybe_unconvert_ref,
> c_omp_address_inspector::maybe_zero_length_array_section,
> c_omp_address_inspector::expand_array_base,
> c_omp_address_inspector::expand_component_selector,
> c_omp_address_inspector::expand_map_clause): New methods.
> (omp_expand_access_chain): New function.
>
> gcc/c/
> * c-typeck.c (handle_omp_array_sections_1,
> handle_omp_array_sections, c_finish_omp_clauses): Use
> c_omp_address_inspector class and OMP address tokenizer to analyze and
> expand map clause expressions. Fix some diagnostics.
>
> gcc/cp/
> * semantics.c (cp_omp_address_inspector): New class, derived from
> c_omp_address_inspector.
> (handle_omp_array_sections_1, handle_omp_array_sections,
> finish_omp_clauses): Use cp_omp_address_inspector class and OMP address
> tokenizer to analyze and expand OpenMP map clause expressions. Fix
> some diagnostics.
>
> gcc/fortran/
> * trans-openmp.cc (gfc_trans_omp_array_section): Add OPENMP parameter.
> Use GOMP_MAP_ATTACH_DETACH instead of GOMP_MAP_ALWAYS_POINTER for
> derived type components.
> (gfc_trans_omp_clauses): Update calls to gfc_trans_omp_array_section.
>
> gcc/
> * gimplify.cc (build_struct_comp_nodes): Don't process
> GOMP_MAP_ATTACH_DETACH "middle" nodes here.
> (omp_mapping_group): Add REPROCESS_STRUCT and FRAGILE booleans for
> nested struct handling.
> (omp_strip_components_and_deref, omp_strip_indirections): Remove
> functions.
> (omp_gather_mapping_groups_1): Initialise reprocess_struct and fragile
> fields.
> (omp_group_base): Handle GOMP_MAP_ATTACH_DETACH after GOMP_MAP_STRUCT.
> (omp_index_mapping_groups_1): Skip reprocess_struct groups.
> (omp_get_nonfirstprivate_group, omp_directive_maps_explicitly,
> omp_resolve_clause_dependencies, omp_expand_access_chain): New
> functions.
> (omp_accumulate_sibling_list): Add GROUP_MAP, ADDR_TOKENS, FRAGILE_P,
> REPROCESSING_STRUCT, ADDED_TAIL parameters. Use OMP address tokenizer
> to analyze addresses. Reimplement nested struct handling, and
> implement "fragile groups".
> (omp_build_struct_sibling_lists): Adjust for changes to
> omp_accumulate_sibling_list. Recalculate bias for ATTACH_DETACH nodes
> after GOMP_MAP_STRUCT nodes.
> (gimplify_scan_omp_clauses): Call omp_resolve_clause_dependencies. Use
> OMP address tokenizer.
> (gimplify_adjust_omp_clauses_1): Use build_fold_indirect_ref_loc
> instead of build_simple_mem_ref_loc.
> * omp-general.cc (omp-general.h, tree-pretty-print.h): Include.
> (omp_addr_tokenizer): New namespace.
> (omp_addr_tokenizer::omp_addr_token): New.
> (omp_addr_tokenizer::omp_parse_component_selector,
> omp_addr_tokenizer::omp_parse_ref,
> omp_addr_tokenizer::omp_parse_pointer,
> omp_addr_tokenizer::omp_parse_access_method,
> omp_addr_tokenizer::omp_parse_access_methods,
> omp_addr_tokenizer::omp_parse_structure_base,
> omp_addr_tokenizer::omp_parse_structured_expr,
> omp_addr_tokenizer::omp_parse_array_expr,
> omp_addr_tokenizer::omp_access_chain_p,
> omp_addr_tokenizer::omp_accessed_addr: New functions.
> (omp_parse_expr, debug_omp_tokenized_addr): New functions.
> * omp-general.h (omp_addr_tokenizer::access_method_kinds,
> omp_addr_tokenizer::structure_base_kinds,
> omp_addr_tokenizer::token_type,
> omp_addr_tokenizer::omp_addr_token,
> omp_addr_tokenizer::omp_access_chain_p,
> omp_addr_tokenizer::omp_accessed_addr): New.
> (omp_addr_token, omp_parse_expr): New.
> * omp-low.cc (scan_sharing_clauses): Skip error check for references
> to pointers.
> * tree.h (OMP_CLAUSE_ATTACHMENT_MAPPING_ERASED): New macro.
>
> gcc/testsuite/
> * c-c++-common/goacc/mdc-2.c: Update expected errors.
> * c-c++-common/gomp/clauses-2.c: Fix error output.
> * c-c++-common/gomp/target-implicit-map-2.c: Adjust scan output.
> * g++.dg/gomp/unmappable-component-1.C: New test.
> * g++.dg/goacc/mdc.C: Update expected errors.
> * g++.dg/gomp/static-component-1.C: New test.
> * gcc.dg/gomp/target-3.c: Adjust scan output.
>
> libgomp/
> * target.c (gomp_map_fields_existing: Use gomp_map_0len_lookup.
> (gomp_attach_pointer): Allow attaching null pointers (or Fortran
> "unassociated" pointers).
> (gomp_map_vars_internal): Handle zero-sized struct members. Add
> diagnostic for unmapped struct pointer members.
> * testsuite/libgomp.c++/class-array-1.C: New test.
> * testsuite/libgomp.c-c++-common/baseptrs-1.c: New test.
> * testsuite/libgomp.c-c++-common/baseptrs-2.c: New test.
> * testsuite/libgomp.c++/baseptrs-3.C: New test.
> * testsuite/libgomp.c++/baseptrs-4.C: New test.
> * testsuite/libgomp.c++/baseptrs-5.C: New test.
> * testsuite/libgomp.c++/target-48.C: New test.
> * testsuite/libgomp.c++/target-49.C: New test.
> * testsuite/libgomp.c/target-22.c: Add necessary explicit base pointer
> mappings.
> ---
> gcc/c-family/c-common.h | 68 +
> gcc/c-family/c-omp.cc | 765 +++-
> gcc/c/c-typeck.cc | 363 +-
> gcc/cp/semantics.cc | 568 ++-
> gcc/fortran/trans-openmp.cc | 36 +-
> gcc/gimplify.cc | 1030 +++++-
> gcc/omp-general.cc | 426 +++
> gcc/omp-general.h | 57 +
> gcc/omp-low.cc | 7 +-
> gcc/testsuite/c-c++-common/goacc/mdc-2.c | 2 +
> gcc/testsuite/c-c++-common/gomp/clauses-2.c | 2 +-
> .../c-c++-common/gomp/target-implicit-map-2.c | 2 +-
> gcc/testsuite/g++.dg/goacc/mdc.C | 2 +
> .../g++.dg/gomp/static-component-1.C | 23 +
> gcc/testsuite/gcc.dg/gomp/target-3.c | 2 +-
> gcc/tree.h | 4 +
> libgomp/target.c | 31 +-
> libgomp/testsuite/libgomp.c++/baseptrs-3.C | 275 ++
> libgomp/testsuite/libgomp.c++/baseptrs-4.C | 3154 +++++++++++++++++
> libgomp/testsuite/libgomp.c++/baseptrs-5.C | 62 +
> libgomp/testsuite/libgomp.c++/class-array-1.C | 59 +
> libgomp/testsuite/libgomp.c++/target-48.C | 32 +
> libgomp/testsuite/libgomp.c++/target-49.C | 37 +
> .../libgomp.c-c++-common/baseptrs-1.c | 50 +
> .../libgomp.c-c++-common/baseptrs-2.c | 70 +
> libgomp/testsuite/libgomp.c/target-22.c | 3 +-
> 26 files changed, 6394 insertions(+), 736 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/gomp/static-component-1.C
> create mode 100644 libgomp/testsuite/libgomp.c++/baseptrs-3.C
> create mode 100644 libgomp/testsuite/libgomp.c++/baseptrs-4.C
> create mode 100644 libgomp/testsuite/libgomp.c++/baseptrs-5.C
> create mode 100644 libgomp/testsuite/libgomp.c++/class-array-1.C
> create mode 100644 libgomp/testsuite/libgomp.c++/target-48.C
> create mode 100644 libgomp/testsuite/libgomp.c++/target-49.C
> create mode 100644 libgomp/testsuite/libgomp.c-c++-common/baseptrs-1.c
> create mode 100644 libgomp/testsuite/libgomp.c-c++-common/baseptrs-2.c
>
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index e7b0fd1309d..4ea244b3ce9 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -1270,6 +1270,74 @@ extern tree c_omp_check_context_selector (location_t, tree);
> extern void c_omp_mark_declare_variant (location_t, tree, tree);
> extern void c_omp_adjust_map_clauses (tree, bool);
>
> +namespace omp_addr_tokenizer { struct omp_addr_token; }
> +typedef omp_addr_tokenizer::omp_addr_token omp_addr_token;
> +
> +class c_omp_address_inspector
> +{
> + location_t loc;
> + tree root_term;
> + bool indirections;
> + int map_supported;
> +
> +protected:
> + tree orig;
> +
> +public:
> + c_omp_address_inspector (location_t loc, tree t)
> + : loc (loc), root_term (NULL_TREE), indirections (false),
> + map_supported (-1), orig (t)
> + {}
> +
> + ~c_omp_address_inspector ()
> + {}
> +
> + virtual bool processing_template_decl_p ()
> + {
> + return false;
> + }
> +
> + virtual void emit_unmappable_type_notes (tree)
> + {
> + }
> +
> + virtual tree convert_from_reference (tree)
> + {
> + gcc_unreachable ();
> + }
> +
> + virtual tree build_array_ref (location_t loc, tree arr, tree idx)
> + {
> + tree eltype = TREE_TYPE (TREE_TYPE (arr));
> + return build4_loc (loc, ARRAY_REF, eltype, arr, idx, NULL_TREE,
> + NULL_TREE);
> + }
> +
> + bool check_clause (tree);
> + tree get_root_term (bool);
> +
> + tree get_address ()
> + {
> + return orig;
> + }
This has the method formatting style inconsistency I've walked about
earlier.
Either the {s are indented 2 further columns, or they aren't, but definitely
not both in the same class.
Missing function comment before following:
> +static bool
> +omp_directive_maps_explicitly (hash_map<tree_operand_hash,
> + omp_mapping_group *> *grpmap,
> + tree decl, omp_mapping_group **base_group,
> + bool to_specifically, bool allow_deleted,
> + bool contained_in_struct)
> +{
> + omp_mapping_group *decl_group
> + = omp_get_nonfirstprivate_group (grpmap, decl, allow_deleted);
> +
> + *base_group = NULL;
> +
> + if (decl_group)
> + {
> + tree grp_first = *decl_group->grp_start;
> + /* We might be called during omp_build_struct_sibling_lists, when
> + GOMP_MAP_STRUCT might have been inserted at the start of the group.
> + Skip over that, and also possibly the node after it. */
> + if (OMP_CLAUSE_MAP_KIND (grp_first) == GOMP_MAP_STRUCT)
> + {
> + grp_first = OMP_CLAUSE_CHAIN (grp_first);
> + if (OMP_CLAUSE_MAP_KIND (grp_first) == GOMP_MAP_FIRSTPRIVATE_POINTER
> + || (OMP_CLAUSE_MAP_KIND (grp_first)
> + == GOMP_MAP_FIRSTPRIVATE_REFERENCE)
> + || OMP_CLAUSE_MAP_KIND (grp_first) == GOMP_MAP_ATTACH_DETACH)
> + grp_first = OMP_CLAUSE_CHAIN (grp_first);
> + }
> + enum gomp_map_kind first_kind = OMP_CLAUSE_MAP_KIND (grp_first);
> + if (!to_specifically
> + || GOMP_MAP_COPY_TO_P (first_kind)
> + || first_kind == GOMP_MAP_ALLOC)
> + {
> + *base_group = decl_group;
> + return true;
> + }
> + }
> +
> + if (contained_in_struct
> + && omp_mapped_by_containing_struct (grpmap, decl, base_group))
> + return true;
> +
> + return false;
> +}
Why?
gimplify_scan_omp_clauses certainly should have a function comment.
>
> -/* Scan the OMP clauses in *LIST_P, installing mappings into a new
> - and previous omp contexts. */
> -
> static void
> gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
> enum omp_region_type region_type,
> enum tree_code code)
> +
> +enum structure_base_kinds
> +{
> + BASE_DECL,
> + BASE_COMPONENT_EXPR,
> + BASE_ARBITRARY_EXPR
> +};
> +
> +enum token_type
> +{
> + ARRAY_BASE,
> + STRUCTURE_BASE,
> + COMPONENT_SELECTOR,
> + ACCESS_METHOD
> +};
Wouldn't hurt to add comment about omp_addr_token and the above two enums.
> +
> +struct omp_addr_token
> +{
> + enum token_type type;
> + tree expr;
> +
> + union
> + {
> + access_method_kinds access_kind;
> + structure_base_kinds structure_base_kind;
> + } u;
> +
> + omp_addr_token (token_type, tree);
> + omp_addr_token (access_method_kinds, tree);
> + omp_addr_token (token_type, structure_base_kinds, tree);
> +};
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -718,7 +718,7 @@ gomp_map_fields_existing (struct target_mem_desc *tgt,
>
> cur_node.host_start = (uintptr_t) hostaddrs[i];
> cur_node.host_end = cur_node.host_start + sizes[i];
> - splay_tree_key n2 = splay_tree_lookup (mem_map, &cur_node);
> + splay_tree_key n2 = gomp_map_0len_lookup (mem_map, &cur_node);
> kind = get_kind (short_mapkind, kinds, i);
> implicit = get_implicit (short_mapkind, kinds, i);
> if (n2
I'm a little bit worried if the above isn't a backwards incompatible change.
We need programs compiled by GCC 12 and earlier to be handled correctly.
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c++/baseptrs-4.C
> @@ -0,0 +1,3154 @@
> +// { dg-do run }
> +
> +#include <cstring>
> +#include <cassert>
> +
> +#define MAP_DECLS
> +
> +#define NONREF_DECL_BASE
> +#define REF_DECL_BASE
> +#define PTR_DECL_BASE
> +#define REF2PTR_DECL_BASE
> +
> +#define ARRAY_DECL_BASE
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2ARRAY_DECL_BASE
> +#define PTR_OFFSET_DECL_BASE
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2PTR_OFFSET_DECL_BASE
> +
> +#define MAP_SECTIONS
> +
> +#define NONREF_DECL_MEMBER_SLICE
> +#define NONREF_DECL_MEMBER_SLICE_BASEPTR
> +#define REF_DECL_MEMBER_SLICE
> +#define REF_DECL_MEMBER_SLICE_BASEPTR
> +#define PTR_DECL_MEMBER_SLICE
> +#define PTR_DECL_MEMBER_SLICE_BASEPTR
> +#define REF2PTR_DECL_MEMBER_SLICE
> +#define REF2PTR_DECL_MEMBER_SLICE_BASEPTR
> +
> +#define ARRAY_DECL_MEMBER_SLICE
> +#define ARRAY_DECL_MEMBER_SLICE_BASEPTR
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2ARRAY_DECL_MEMBER_SLICE
> +//#define REF2ARRAY_DECL_MEMBER_SLICE_BASEPTR
> +#define PTR_OFFSET_DECL_MEMBER_SLICE
> +#define PTR_OFFSET_DECL_MEMBER_SLICE_BASEPTR
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2PTR_OFFSET_DECL_MEMBER_SLICE
> +//#define REF2PTR_OFFSET_DECL_MEMBER_SLICE_BASEPTR
> +
> +#define PTRARRAY_DECL_MEMBER_SLICE
> +#define PTRARRAY_DECL_MEMBER_SLICE_BASEPTR
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2PTRARRAY_DECL_MEMBER_SLICE
> +//#define REF2PTRARRAY_DECL_MEMBER_SLICE_BASEPTR
> +#define PTRPTR_OFFSET_DECL_MEMBER_SLICE
> +#define PTRPTR_OFFSET_DECL_MEMBER_SLICE_BASEPTR
> +// Needs map clause "lvalue"-parsing support.
> +//#define REF2PTRPTR_OFFSET_DECL_MEMBER_SLICE
> +//#define REF2PTRPTR_OFFSET_DECL_MEMBER_SLICE_BASEPTR
> +
> +#define NONREF_COMPONENT_BASE
> +#define NONREF_COMPONENT_MEMBER_SLICE
> +#define NONREF_COMPONENT_MEMBER_SLICE_BASEPTR
> +
> +#define REF_COMPONENT_BASE
> +#define REF_COMPONENT_MEMBER_SLICE
> +#define REF_COMPONENT_MEMBER_SLICE_BASEPTR
> +
> +#define PTR_COMPONENT_BASE
> +#define PTR_COMPONENT_MEMBER_SLICE
> +#define PTR_COMPONENT_MEMBER_SLICE_BASEPTR
> +
> +#define REF2PTR_COMPONENT_BASE
> +#define REF2PTR_COMPONENT_MEMBER_SLICE
> +#define REF2PTR_COMPONENT_MEMBER_SLICE_BASEPTR
Are all these defines only a temporary hacks until the patchset
is complete?
Jakub
next prev parent reply other threads:[~2022-09-14 13:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 21:01 [PATCH v3 00/11] OpenMP 5.0: Struct & mapping clause expansion rework Julian Brown
2022-09-13 21:01 ` [PATCH v3 01/11] OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by base pointer) Julian Brown
2022-09-14 10:34 ` Jakub Jelinek
2022-09-13 21:01 ` [PATCH v3 02/11] Remove omp_target_reorder_clauses Julian Brown
2022-09-14 10:35 ` Jakub Jelinek
2022-09-13 21:01 ` [PATCH v3 03/11] OpenMP/OpenACC struct sibling list gimplification extension and rework Julian Brown
2022-09-14 11:21 ` Jakub Jelinek
2022-09-13 21:01 ` [PATCH v3 04/11] OpenMP/OpenACC: mapping group list-handling improvements Julian Brown
2022-09-14 11:30 ` Jakub Jelinek
2022-09-13 21:03 ` [PATCH v3 05/11] OpenMP: push attaches to end of clause list in "target" regions Julian Brown
2022-09-14 12:44 ` Jakub Jelinek
2022-09-18 19:10 ` Julian Brown
2022-09-18 19:18 ` Jakub Jelinek
2022-09-13 21:03 ` [PATCH v3 06/11] OpenMP: Pointers and member mappings Julian Brown
2022-09-14 12:53 ` Jakub Jelinek
2022-09-18 19:19 ` Julian Brown
2022-09-22 13:17 ` Jakub Jelinek
2022-09-23 7:29 ` Julian Brown
2022-09-23 9:38 ` Jakub Jelinek
2022-09-23 12:10 ` Tobias Burnus
2022-09-30 13:30 ` Julian Brown
2022-09-30 14:42 ` Tobias Burnus
2022-09-30 15:01 ` Tobias Burnus
2022-09-13 21:03 ` [PATCH v3 07/11] OpenMP/OpenACC: Reindent TO/FROM/_CACHE_ stanza in {c_}finish_omp_clause Julian Brown
2022-09-14 13:06 ` Jakub Jelinek
2022-09-13 21:03 ` [PATCH v3 08/11] OpenMP/OpenACC: Rework clause expansion and nested struct handling Julian Brown
2022-09-14 13:24 ` Jakub Jelinek [this message]
2022-09-14 13:59 ` Julian Brown
2022-09-19 19:40 ` Julian Brown
2022-09-22 13:20 ` Jakub Jelinek
2022-09-13 21:03 ` [PATCH v3 09/11] FYI/unfinished: OpenMP: lvalue parsing for map clauses (C++) Julian Brown
2022-09-13 21:04 ` [PATCH v3 10/11] Use OMP_ARRAY_SECTION instead of TREE_LIST in C++ FE Julian Brown
2022-09-13 21:04 ` [PATCH v3 11/11] FYI/unfinished: OpenMP 5.0 "declare mapper" support for C++ Julian Brown
2022-09-14 6:30 ` FYI: "declare mapper" patch set for Fortran (June 2022) (was: [PATCH v3 11/11] FYI/unfinished: OpenMP 5.0 "declare mapper" support for C++) Tobias Burnus
2022-09-14 14:58 ` [PATCH v3 11/11] FYI/unfinished: OpenMP 5.0 "declare mapper" support for C++ Jakub Jelinek
2022-09-14 16:32 ` Julian Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YyHV0/LuuYIRADLE@tucnak \
--to=jakub@redhat.com \
--cc=cltang@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=julian@codesourcery.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).