https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
Bug ID: 118694
Summary: OpenMP: target/metadirective/teams directive nesting
gives error
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Target Milestone: ---
As noted by Tobias here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674546.html
<snip>
* Unless it is quickly fixable, we agreed on deferring the bogus message
"Error: ‘target’ construct with nested ‘teams’ construct contains directives
outside of the ‘teams’ construct"
to a new PR. That's for:
OpenMP_VV's tests/5.0/metadirective/test_metadirective_arch_is_nvidia.F90
tests/5.0/metadirective/test_metadirective_arch_is_nvidia.F90:42:84:
42 | !$omp target map(to:v1,v2) map(from:v3,target_device_num)
device(default_device)
|
^
Error: ‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct
Likewise with the OpenMP examples document:
program_control/sources/metadirective.1.f90:12:53:
12 | !$omp target map(to:v1,v2) map(from:v3) device(0)
| ^
Error: ‘target’ construct with nested ‘teams’ construct contains directives
outside of the ‘teams’ construct
</snip>
The issue here is that the OpenMP spec says (version 6.0, bottom of page 395)
"A teams region must be a strictly nested region of the implicit parallel
region that surrounds the whole OpenMP program or a target region. If a teams
region is nested inside a target region, the corresponding target construct
must not contain any statements, declarations or directives outside of the
corresponding teams construct."
It's not clear to me that this language permits "metadirective" between
"target" and "teams", but the existence of examples seems to indicate that's
the intent. When the metadirective contains only static selectors and can be
resolved in the front end or during gimplification, this is accepted, but if it
requires late resolution and/or includes dynamic selectors, then the gimplifier
inserts some additional code around the directive variants, which triggers the
error. I'm doubtful that anything can be done about the dynamic selector case
except maybe a better error message, though.
