Hi,
John Campbell wrote:
Would it be easier to consider "DO CONCURRENT with LOCAL / LOCAL_INIT" as a
special case of !$OMP PARALLEL DO, so utilise this existing implementation ?
I think I want to handle by default a bare 'do concurrent' with a code
separate from OpenMP, but using the normal code.
I am also not completely sure whether the semantic is exactly the same –
and whether there are issues with the current OpenMP implementation; I
would assume there are some with 'private' as there are with LOCAL when
using default-values in derived types.
Note that I also did not see real obstacles yesterday but it requires
another couple of hours of work (it took so far 5h, ignoring the work
for what's in already). The future work would be either continuing with
the current approach or calling the existing OpenMP copy and
default-init functions (see PR for the function names), which still
would reuse parts of the current patch.
It also requires more *testcases* for do concurrent to check that
everything is handled correctly; as the existing testcases (see patch)
show, simple code works – but trying hard enough, one finds things that
don't.
[Converting the current/new testcases to OpenMP wouldn't harm, either.
I'd assume that some cases are mishandled there as well, esp. derived
types with default values.]
Regarding the semantic: I think OpenMP permits more – at least for
'firstprivate', like polymorphic variables and allocatable components. –
For 'private', a lot of details are unspecified. – Fortran is more
restrictive but/hence has fewer unspecified parts. However, my feeling
is that the difference is more on the constraint-checking side in the
compiler and less on the actual implementation.
(That polymorphic variables are supported in OpenMP's firstprivate was
rather underspecified until OpenMP 6.0; it is now permitted (except on
'target'). GCC should handle it already correctly since GCC 13 (?).)
* * *
Regarding moving to real parallelization (out of scope for the current
patch): For 'do concurrent', I don't think that it should
unconditionally linke the OpenMP runtime library and turn every
do-concurrent loop into something that consumes all available threads of
the system.
Thus, I was thinking in the past of providing -fdo-concurrent=… as flag
to decide how to handle it, i.e. use no thread parallization, use
OpenMP's, or … — The question is only the exact option, default, and
semantic.
BTW: OpenMP before 6.0 did not permit any OpenMP directive on 'do
concurrent'. However, with OpenMP 6.0, '!$omp loop' is permitted, which
makes it possible to say per loop whether thread parallization should be
done or not.
* * *
I think permitting '!$omp loop' on do-concurrent will likely be a GCC 16
item, while non thread-parallelizing do-concurrent should really still
become a GCC 15 feature! I think we also think about -fdo-concurrent=…
for GCC 16.
Tobias
