https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121812
Bug ID: 121812
Summary: [OpenMP] 'Contruct' context selector handling with
'declare variant'
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
When using the delimited form of declare variant, such as
#pragma omp begin declare variant match(construct={teams})
void foo() {
#metadirective when(construct={teams}: team) otherwise(nothing)
// ...
}
#pragma omp end declare variant
the metadirective can be resolved based on the match clause, similar to
#pragma teams
{
#metadirective when(construct={teams}: team) otherwise(nothing)
// ...
}
(This is also what happens with the delimited declare variant support in GCC as
posted as patches and implemented in OG15.)
However, in principle, the following is supposed to work as well:
void foo() {
#metadirective when(construct={teams}: team) otherwise(nothing)
// ...
}
#pragma omp declare variant(foo) match(construct={teams})
void bar();
However, currently GCC resolves this to 'otherwise'.
Note: The following wording in the spec ensures that this resolution does not
cause issues:
• Calling procedures that a declare variant directive determined to be a
function variant directly in an OpenMP context that is different from the
one that the construct selector set of the context selector specifies is
non-conforming.
• If a procedure is determined to be a function variant through more than
one declare variant directive then the construct selector set of their
context selectors must be the same.
EXPECTED:
* If the 'declare variant' is in the same compilation unit, the context is
propagated to the function definition such that when the metadirective is
resolved, it is applied.
* RFC: Likewise when in the same translation unit but not same compilation
unit? (Only applicable to Fortran.)
NOTE:
In terms of the OpenMP specification, it was seemingly intended that it works
as described above, but the current wording does not enforce it, making it
implementation defined (or unspecified?) whether it actually happens.
(This has come up as side remark/to-be-discussed topic at last OpenMP lang spec
call, when discussing an example issue. Expected more explicit wording in the
future.)
