On Mon, Feb 21, 2022 at 02:24:40PM +0000, Hafiz Abid Qadeer wrote:
> This patch fixes an issue that although gfortran accepts
> 'requires dynamic_allocators', it does not set the omp_requires_mask
> accordingly.
>
> gcc/fortran/ChangeLog:
>
> * parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS
> bit in omp_requires_mask.
> ---
> gcc/fortran/parse.cc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
> index db918291b10..821555bd85f 100644
> --- a/gcc/fortran/parse.cc
> +++ b/gcc/fortran/parse.cc
> @@ -6890,6 +6890,9 @@ done:
> break;
> }
>
> + if (omp_requires & OMP_REQ_DYNAMIC_ALLOCATORS)
> + omp_requires_mask
> + = (enum omp_requires) (omp_requires_mask |
> OMP_REQUIRES_DYNAMIC_ALLOCATORS);
> /* Do the parse tree dump. */
> gfc_current_ns = flag_dump_fortran_original ? gfc_global_ns_list : NULL;
I see we do that for !$omp requires atomic_default_mem_order(...)
but it doesn't look correct to me.
The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion of
translation units (and a question is how does that cope with C++20 modules),
with the assumption that once certain #pragma omp requires is seen, it
applies for the rest of the translation unit and there are some restrictions
that require it to appear before certain constructs in the source.
But, Fortran I think doesn't really have a concept of the translation unit,
the OpenMP term compilation unit is in Fortran program unit, so each
function/subroutine should have its own. So, instead of what gfc_parse_file
does currently where it computes omp_requires as or of requires from each
function/subroutine (I think especially for atomic_default_mem_order that
can do really weird things, nothing requires that e.g. in different
functions those can't be different in Fortran, while in C/C++ it needs to be
the same), we need to make sure that omp_requires_mask omp-generic.cc sees
or uses is for Fortran the value from the current function/subroutine.
For the yet unimplemented requires unified_address etc., the plan was that
we'd emit the requirement e.g. into the offloading data such that we could
tell the runtime library all the requirements together from whole program or
shared library. In that case using an or from the various
functions/subroutines is desirable, if at least one function requires
unified_address, the runtime should filter out any devices that don't
satisfy it, etc.
Jakub
