OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support

  This WIP patch adds preliminary and very lightly-tested support for
the "begin declare variant" and "end declare variant" directives of
OpenMP 5.1.  I am posting it now for logistical reasons, rather than
because I believe it is immediately ready for review.

Some notes follow on the implementation as-is and on my understanding
of what is still to be done.

I have tried to build on top of the existing support for "declare variant"
as far as possible. I also borrowed ideas and some of the implementation
from function versioning support (but see below regarding template
handling).

There are mostly four aspects to the implementation:

1) Inside begin/end "declare variant" blocks, you may define specialised
   versions of functions with the same name as some base function in the
   main part of the program.  The specialised functions must have some way
   of coexisting with other functions with the same name and prototype.

2) Begin/end "declare variant" blocks may be nested, and the OpenMP
   context is formed from a combination of the outer and inner levels
   (in some way that depends on the trait sets, etc. in use).

3) The same-named "declare variant" functions must be resolved to the
   right implementation in some given OpenMP context (including in parts
   of the program not enclosed by OpenMP directives).

4) The same-named, specialized versions of functions must have their
   names mangled by adding a context-specific suffix string.

Taking these in turn:

1. "declare variant" overloading
--------------------------------

In C++, this looks somewhat like function overloading, and that is also
how the existing support for function multiversioning is implemented
(https://gcc.gnu.org/wiki/FunctionMultiVersioning).  Unfortunately this
doesn't work with templates at present, so the attached patch has to
do a little more in that regard.  This works in simple cases, but I am
not entirely convinced it is a complete solution yet -- in particular
pt.cc:spec_hasher::equal always considers two functions with the "omp
declare variant overload" attribute to be unequal. Should it be comparing
the context?

Similarly, I am not entirely convinced the logic in call.cc:joust is
correct, though it seems to work for what I've tried it with so far.

In C, which is so-far unimplemented, this scheme will not work so
smoothly.  An alternative might be to mangle function names earlier,
or perhaps mangle with some temporary name ("foo$1", "foo$2", ...) early
in compilation then re-mangle properly later (such functions would need
to be considered "the same" in some places, but not in others. Details
TBD of course).

2. Context merging
------------------

Contexts are merged eagerly as "begin/end declare variant" directives
are being parsed: hence, a top-level directive will be merged with its
immediate child, and the grandchild will be merged with the combined
"child+parent" context.  So, a function defined at some given point in
the nesting hierarchy will decorated with a copy of the innermost context.

Function decls encountered within the block (or nested block, ...) are
annotated with a new attribute, "omp declare variant overload".  This is
similar to the existing "omp declare variant variant" attribute, but:

  - It records the entire context (as specified on the enclosing "begin
    declare variant" block(s)), not just the "contruct" set.

  - It is set immediately for each function within a "declare variant"
    block (see below).

Some aspects of context merging need verification against the standard
-- it's not always completely obvious how trait properties should be
combined.

3. Function resolution
----------------------

The current patch tries to adjust function attributes so they are
similar to those used by the existing non-delimited "declare variant"
support. For that, if we have a fragment like this:

  T foo_x86 (T v)
  { ... }

  [...]

  #pragma omp declare variant (foo_x86) match(device={arch(x86)})
  #pragma omp declare variant (foo_powerpc) match(device={arch(powerpc)})
  #pragma omp declare variant (foo_aarch64) match(device={arch(aarch64)})
  T foo (T v)
  {
    return v + 1;
  }

The function "foo" is annotated with one "omp declare variant base"
attribute for each named/specialized function version.  The VALUE
field of the attribute is a tuple specifying the *name* of the specialized
function, the context, and a location.  This name is then looked up
in decl.cc:omp_declare_variant_finalize_one, a function call to the
specialized function is synthesized (to mark that function as requiring
template instantiation, amongst other things?), and a "omp declare variant
variant" attribute with *just the construct part* of the context selector
is added to the specialized function.

For the new "overload"-type delimited "declare variant" functions, this
works backwards.  We know the full context for the variant function and
we already have the FUNCTION_DECL for it (so we don't need to look up
the name).

So, we create a "omp declare variant base" attribute on the version of the
function that *doesn't* have a "omp declare variant overload" attribute
already, for each *other* variant that does have such an attribute.
This makes the end result more-or-less the same as with the non-delimited
"declare variant" function support, except the "omp declare variant base"
attributes point to specialised functions with "omp declare variant
overload" instead of "omp declare variant variant" attributes.

This should work no matter what order the base function or specialized
versions of it are defined in, but those bits aren't really heavily
tested.

Class members and template class members are supported also, but again,
testing has only been done very lightly so far.

4. Function mangling
--------------------

The last part is function mangling, which makes use of the tables that
Sandra added as part of her context-selector abstraction rework patch
series.  This works for the set of new (very incomplete!) tests, but
probably needs a little more work -- mostly to make sure that e.g. some
unfortunately-named new architecture or ISA extension (and so forth)
can't create name collisions.  Some of the logic regarding "separator"
string insertion is also a bit rough/buggy, I think.

5. AOB
------

There are too many "lookup_attribute" calls in places that are probably
critical paths -- it might be better to change these to use another tree
flag instead.

Due to light testing and the variety of things one can specify with
context selectors, some behaviour might well be completely bogus.
E.g. memory-order traits probably do nothing.  There are almost certainly
circumstances where context matching is done in the wrong place or gets
the wrong results.

There is no support yet for "elision" -- removing code from the source
program altogether between begin/end "declare variant" directives,
following e.g. OpenMP 5.2 "7.5.5 begin declare variant Directive"):

  "If the context selector of a begin declare variant directive contains
   traits in the device or implementation set that are known never to be
   compatible with an OpenMP context during the current compilation, the
   preprocessed code that follows the begin declare variant directive
   up to its paired end directive is elided."

...as discussed at the GNU Tools Cauldron (2023).  This has somewhat
far-reaching consequences, depending perhaps on how one interprets "the
current compilation", but the plan is/was to only perform elision for
cases we know for sure can't be supported, like within FPGA-requiring
contexts.

There are various questions to be answered/FIXMEs to be addressed
throughout the code, apart from things mentioned above already.

Data structures could probably use some work (it's a bit wasteful in
places at the moment, e.g. omp_combine_trait_sets).

The patch inherits various problems with context selectors noted
elsewhere (constants instead of expressions in some places, no dynamic
dispatch, ...).  Hopefully none of the choices made so far make those
problems worse!

Restrictions listed in e.g. OpenMP 5.2, "7.5.5 begin declare variant
Directive", are not yet checked against.

It would be nice if the "overload"-type declare variant functions worked
smoothly alongside the existing function multiversion support, but since
that's an extension, I don't suppose it's a requirement (maybe a "sorry"
here and there might be needed).

None of the tests are finished, they're just the bits and pieces I've
been using whilst developing the patch.  They mostly aren't even actually
testing anything (except that the compiler doesn't crash, I suppose).

2024-01-11  Julian Brown  <julian@codesourcery.com>

gcc/c-family/
	* c-attribs.cc (c_common_gnu_attributes): Add "omp declare variant
	overload".
	(handle_omp_declare_variant_attribute): Update comment.

gcc/
	* coverage.cc (coverage_begin_function): Support
	DECL_FUNCTION_OMP_VARIANT flag.
	* omp-expand.cc (expand_omp_target): Handle DECL_FUNCTION_OMP_VARIANT
	flag.
	* omp-general.cc (tree-hash-traits.h): Include.
	(kind_abbrevs, atomic_default_mem_order_abbrevs): New.
	(omp_ts_map): Populate attrib fields.
	(omp_context_name_list_prop_1): New helper function.
	(omp_context_name_list_prop): Adjust to use above.
	(omp_copy_trait_set): New function.
	(omp_trait_prop): New type.
	(omp_trait_prop_hash, omp_trait_prop_hash::hash,
	omp_trait_prop_hash::is_empty, omp_trait_prop_hash::is_deleted,
	omp_trait_prop_hash::equal, omp_trait_prop_hash::mark_empty,
	omp_trait_prop_set): New.
	(omp_gather_trait_sets, omp_combine_trait_properties,
	omp_combine_trait_sets): New functions.
	(omp_get_context_selector_list): Add prototype (FIXME!).
	(omp_merge_context_selectors): New function.
	(omp_mangle_obstack, omp_name_obstack, omp_name_base, write_char,
	write_string, omp_start_mangling, omp_finish_mangling, omp_init_mangle,
	omp_string_compare, omp_stringify_sorted_property_set,
	omp_mangle_context_selector): New.
	* omp-general.h (omp_merge_context_selectors, omp_init_mangle,
	omp_mangle_context_selector): Add prototypes.
	* omp-low.cc (create_omp_child_function): Copy
	DECL_FUNCTION_OMP_VARIANT flag.
	* omp-selectors.h (omp_ts_info): Add abbrev_name, prop_abbrevs fields.
	* tree-cfg.cc (dump_function_to_file): Support "omp declare variant
	overload".
	* tree-core.h (tree_function_decl): Add omp_variant flag.
	* tree.h (DECL_FUNCTION_OMP_VARIANT): New.

gcc/cp/
	* call.cc (joust): Support OpenMP variant overload functions.
	* class.cc (add_method): Allow class members to be OpenMP variant
	functions.
	(resolve_address_of_overloaded_function): Add assertion/TBD comment.
	* cp-tree.h (cp_omp_declare_variant_attr): New struct.
	(saved_scope): Add omp_declare_variant_attribute member.
	(maybe_omp_variant_functions): Add prototype.
	* decl.cc (decls_match): Support OpenMP variant overload functions.
	(maybe_mark_omp_variant_functions, maybe_omp_variant_functions): New
	functions.
	(duplicate_function_template_decls, duplicate_decls): Support OpenMP
	variant overload [template] functions.
	(omp_declare_variant_finalize_one): Support OpenMP variant overload
	functions.
	* decl2.cc (cplus_decl_attributes): Record contexts for OpenMP variant
	overload functions.
	* lex.cc (omp-general.h): Include.
	(cxx_init): Initialise OpenMP variant function mangling.
	* mangle.cc (omp-general.h): Include.
	(write_mangled_name): Support OpenMP variant function mangling.
	* parser.cc (cp_parser_omp_begin): Support parsing of "begin
	declare variant" directives.
	(cp_parser_omp_end): Similar, for "end declare variant".
	* pt.cc (spec_hasher::equal): Support OpenMP variant overload
	functions.
	(tsubst_function_decl): Add forward declaration.
	(tsubst_attribute): Support instantiating "omp declare variant base"
	attribute when info tuple represents a FUNCTION_DECL rather than an
	identifier (for "overload" variants), and the "omp declare variant
	overload" attribute.
	(tsubst_function_decl): Remove default argument from here (in forward
	declaration above now -- FIXME).  Call tsubst_attributes for "omp
	declare variant base".
	* semantics.cc (finish_translation_unit): Check for mismatched
	begin/end declare variant directives.

gcc/testsuite/
	* g++.dg/gomp/delim-declare-variant-1.C: New (WIP) test.
	* g++.dg/gomp/delim-declare-variant-2.C: Likewise.
	* g++.dg/gomp/delim-declare-variant-3.C: Likewise.
	* g++.dg/gomp/delim-declare-variant-4.C: Likewise.
	* g++.dg/gomp/delim-declare-variant-5.C: Likewise.
	* g++.dg/gomp/delim-declare-variant-11.C: Likewise.
	* g++.dg/gomp/delim-declare-variant-12.C: Likewise.

libgomp/
	* testsuite/libgomp.c++/delim-declare-variant-6.C: New (WIP) test.
	* testsuite/libgomp.c++/delim-declare-variant-7.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-8.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-9.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-10.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-13.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-14.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-15.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-16.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-17.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-18.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-19.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-20.C: Likewise.
	* testsuite/libgomp.c++/delim-declare-variant-21.C: Likewise.
---
 gcc/c-family/c-attribs.cc                     |   6 +-
 gcc/coverage.cc                               |   1 +
 gcc/cp/call.cc                                |  23 +
 gcc/cp/class.cc                               |  15 +
 gcc/cp/cp-tree.h                              |   7 +
 gcc/cp/decl.cc                                | 176 ++++-
 gcc/cp/decl2.cc                               |  11 +
 gcc/cp/lex.cc                                 |   3 +
 gcc/cp/mangle.cc                              |  16 +
 gcc/cp/parser.cc                              | 143 +++-
 gcc/cp/pt.cc                                  |  41 +-
 gcc/cp/semantics.cc                           |   7 +
 gcc/omp-expand.cc                             |   2 +
 gcc/omp-general.cc                            | 705 ++++++++++++++++--
 gcc/omp-general.h                             |   3 +
 gcc/omp-low.cc                                |   2 +
 gcc/omp-selectors.h                           |   2 +
 .../g++.dg/gomp/delim-declare-variant-1.C     |  82 ++
 .../g++.dg/gomp/delim-declare-variant-11.C    |  20 +
 .../g++.dg/gomp/delim-declare-variant-12.C    |  32 +
 .../g++.dg/gomp/delim-declare-variant-2.C     |  26 +
 .../g++.dg/gomp/delim-declare-variant-3.C     |   6 +
 .../g++.dg/gomp/delim-declare-variant-4.C     |  10 +
 .../g++.dg/gomp/delim-declare-variant-5.C     |   4 +
 gcc/tree-cfg.cc                               |   4 +
 gcc/tree-core.h                               |   3 +-
 gcc/tree.h                                    |   7 +
 .../libgomp.c++/delim-declare-variant-10.C    |  19 +
 .../libgomp.c++/delim-declare-variant-13.C    |  51 ++
 .../libgomp.c++/delim-declare-variant-14.C    |  57 ++
 .../libgomp.c++/delim-declare-variant-15.C    |  55 ++
 .../libgomp.c++/delim-declare-variant-16.C    |  30 +
 .../libgomp.c++/delim-declare-variant-17.C    |  29 +
 .../libgomp.c++/delim-declare-variant-18.C    |  46 ++
 .../libgomp.c++/delim-declare-variant-19.C    |  41 +
 .../libgomp.c++/delim-declare-variant-20.C    |  39 +
 .../libgomp.c++/delim-declare-variant-21.C    |  56 ++
 .../libgomp.c++/delim-declare-variant-6.C     |  37 +
 .../libgomp.c++/delim-declare-variant-7.C     |  38 +
 .../libgomp.c++/delim-declare-variant-8.C     |  61 ++
 .../libgomp.c++/delim-declare-variant-9.C     |  54 ++
 41 files changed, 1886 insertions(+), 84 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-1.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-11.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-12.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-2.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-3.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-4.C
 create mode 100644 gcc/testsuite/g++.dg/gomp/delim-declare-variant-5.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-10.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-13.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-14.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-15.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-16.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-17.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-18.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-19.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-20.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-21.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-6.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-7.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-8.C
 create mode 100644 libgomp/testsuite/libgomp.c++/delim-declare-variant-9.C

Message ID	20240111201346.566341-1-julian@codesourcery.com
State	Unresolved
Headers	Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1698180dyi; Thu, 11 Jan 2024 12:15:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IFV2aaB/t/J90R6czb53kvCn9L5AZp5XoYzHvtHfwRfjIZcPk6c74Zst0ee7YL0B+Z+sPhA X-Received: by 2002:a05:6830:1007:b0:6dd:ec84:fa09 with SMTP id a7-20020a056830100700b006ddec84fa09mr309467otp.73.1705004106124; Thu, 11 Jan 2024 12:15:06 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705004106; cv=pass; d=google.com; s=arc-20160816; b=K5NvuCzXXCvnlbzbm8opMoC4RXExgAJTM650QKhIHL1qjBr9y0mm23/VhaFrK0XK14 lwF6WSnKPbluaLwU/R4nmI5FwLeJ9/Ayl4WdgKpek5yrCoaJkIlEWn3rMLOFx2W/24IL wClsCQeq3d7DBqM+E6FMPaYK3pafXustft7tM/44Na5OxSgijKDqNvLq8QK7vO8wXRNq n9x7Xz0svjrmusRL+B3o+aBSSxKBcTanXi5djbGSIFBrxk8MZixmdVDt/WuHK8lOmyZS m2JbrGRrFHfoFkbPkeR5eSxhlKqqTb0aPxF93LzC2Jj1J4zZgON40zfFQvCwR9AVY8rt GpPg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:ironport-sdr :arc-filter:dmarc-filter:delivered-to; bh=rdDQyP8P/7tQ0xyXFp7mrLH5NiaUlC9HPORcXTuFp/I=; fh=0oxoBFh7cBkNO243yGRJG5uRzJF8QS4TtwYQLI791sY=; b=NEGS/6HNALbVhCqZam71ySufsOKmfRqPXR/cquXT3sdrgVZyXTRykYO/8aBwFZP2Nm V8MrfpoPYqWHqGXsdzcVMtug6WFYV+nnmsMSzmYAHWTl3H/icmgOLtMq4+AaP5lk4HVF ez9gqVov9/YGoj553hCFPzcskT2M75ybYhsjVRAd6rDjSFOTlItn6DByWKVMk8dmvMQd 8jHvAErL/c21EUWq4hGw7gJFVPBtwIfaJZ1Wn3R9i1QYC/LFxk9xMyYFrQZlQxirp8Tm qKoacFv+PlEHghhHQKWIMwKWkdLZbh/PK7kyhYPQY/mKweGc3XNHbD181sQRoEVSZltV xTCg== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id e18-20020ac85dd2000000b00427b7c81e5csi1639325qtx.711.2024.01.11.12.15.05 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 12:15:06 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BA6F63857BAB for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 20:15:05 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 06A383858D1E for <gcc-patches@gcc.gnu.org>; Thu, 11 Jan 2024 20:14:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06A383858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 06A383858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.129.153 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705004050; cv=none; b=POmxYA2/pnnfO3ljXPG/CjiVHPjsFqcMkq8yXQu0b7ahC4CITJ0s2jmnxlB4TNKdtLXRY+kt6HYc+wv8mMHPsCgw7HKntp3IbpiwoSejye0BlmjaiqjGZXfDfia5PvIRcxEUc27NK8bLJSIgBNy41YqpBSANONkdkF/Te2+yd2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705004050; c=relaxed/simple; bh=rYjfslZsSi1oDA62H3qaRUR0iFc4lJt6PgbtxIIXCC4=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=F5NMPs8XC3e+3OMMiTYiqOgiNc0af4ItXWNwiOrVeNCJH85NstbIn9M3fPLXWCff7nL+a0TqWe3wvxIVzH5rHrdMUOY+XOHnejU8A3v2Q5rctqPdcZjlD6rryAsgfBSI4AFPVs5N79rAV2oGYc72t1y3CL/qL3/1H0So33NBcrM= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: 0S7KGw2tQfWYnALBzGQEyg== X-CSE-MsgGUID: R3uvZnryTLm1sq4F0sXY1w== X-IronPort-AV: E=Sophos;i="6.04,187,1695715200"; d="scan'208";a="31343713" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 11 Jan 2024 12:14:02 -0800 IronPort-SDR: nL/Taz1EW+MXOdfA0mDfejmt06+vJdyjMu4/yt5au4fIJZU+MLEz7N0p4d9aaN2q5YEFHG7hvz Ab4u9cJXIpbjqE8nPxq/zXghgF9MCnAzTH9mll0QEYuzXjxlndNTiiTa9hp0BaxVHfQlgZKMj0 1UfO5fVceI0Kq9SNqi4e+ZBjiAxHpq/dbidWblLbe84tkgmql9eZnYO/hSqxWaHkiWYUIw9YdH toTfIA2IN46HUC1iajwa3LrNxhEoxWJNU2NWMFI/INVU3yCYdGYDjnp0tn4uSDFMvC4SrGQ3u4 OYs= From: Julian Brown <julian@codesourcery.com> To: <gcc-patches@gcc.gnu.org> CC: <sandra.loosemore@siemens.com>, <burnus@net-b.de>, <thomas@schwinge.name> Subject: [PATCH] OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support Date: Thu, 11 Jan 2024 20:13:46 +0000 Message-ID: <20240111201346.566341-1-julian@codesourcery.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787826385524824796 X-GMAIL-MSGID: 1787826385524824796
Series	OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support \| OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support

OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support

Checks

Commit Message

Patch