https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067
Bug ID: 113067
Summary: [OpenMP][5.1] Context selector - handle
'implementation={requires(...)}'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
OpenMP 5.1 added:
'implementation={requires(...)}'
where ... = unified_shared_memory or unified_address etc.
OpenMP 5.0 only had, e.g.
'implementation={unified_shared_memory}'
the former is not yet handled
* * *
With the about to be committed patch,
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640817.html
which is actually at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639797.html
the Fortran parser in principle handles (when removing the 'sorry') and adds
'unified_shared_memory' and 'requires' according to -fdump-tree-*.
For C/C++, it does ICE - which means that more work is required.
And, in either case, depends how we want to handle it in internal
representation.
=> Attached parse-only testcase.
* * *
Independent of this, I am not sure whether we do handle this requirement
correctly.
Namely, for:
(A) implementation={unified_shared_memory}'
i.e. those which change depending on 'omp requires unified_shared_memory'
being set or not.
(B) implementation={dynamic_allocators}'
which is currently ignored rather early as it is always true for GCC.
(C) implementation={atomic_default_mem_order(acq_rel)}'
The later is quite interesting as - at least in Fortran - multiple values are
permitted per file (to be checked) and I am not quite sure whether the value is
really handled in the ME.
