[Bug middle-end/113067] New: [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}'

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.