[PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

[Tobias Burnus]

Hi Paul,

Am 23.09.24 um 10:26 schrieb Paul Richard Thomas:
> In addition to Andre's remarks, could you please tell us, when you
> resubmit, if this is a complete F2023 implementation of do concurrent.
> If not, what is missing?

Regarding missing parts: still to do is actually privatizing (with or
without initialization) for variables that are listed with 'local' and
'local_init'. Hence, code doing that currently fails after doing all
required diagnostic with a 'sorry not yet implemented error'. [My
feeling is that doing it in trans*.cc might make most sense, but it
could be also done by adding at Fortran AST level (inserting a BLOCK +
adding the variable there).]

Otherwise, all parsing + diagnostic should work; 'default(none)' is
diagnostics only and 'shared' doesn't do anything, except affecting
'default(none)' diagnostic. — 'reduce' will have a code gen effect, but
only when going to real concurrency/parallel execution.

* * *

If you talk about unimplemented 'do concurrent' features in general,
gfortran does not handle the forall/do-concurrent header with typespec
(i.e. 'do concurrent (integer :: i = 1, 4)', cf.
https://gcc.gnu.org/PR96255 [F2018 feature].

* * *

In terms of true parallelization:

* I was (since a while) thinking of having a
-fdo-concurrent=<serial|omp-parallel|omp-target-parallel|openacc>
compile-time flag to handle this.

* OpenMP 6.0 (added I think in Technical Report (TR) 13, which was
released Aug 1, 2024) now supports '!$omp loop' on 'do concurrent'

Either variant would then use the new locality spec (F2018/F2023 and new
in gfortran) and hook into the existing OpenMP/OpenACC handling. –
'!$omp loop' and -fdo-concurrent=omp-parallel are in any case easier
than 'omp-target-parallel' as the latter will run into issues related to
data mapping or (potentially) atomic updates now having to be in sync
with host atomic access.

> BTW Thanks for doing this. It was on my long term TODO list and is now
> struck off :-)

Yes – and I have heard from others that do-concurrent actually being
concurrent – or at least having having the new locality specs even if
not run concurrently is a much missed feature. — That might be from a
small bubble, but still those users wand to have it. And also Damian
mentioned that he has a project what will use it.

Also thanks from my side!

Tobias