Hi Damian, Damian Rouson wrote:
As shown below, using associate eliminates the first error, but I'm still confused by the remaining error message. Are locality specifiers actually supported yet?
The lion share of support is in, but not not yet the code-generation changes.
For local and local_init, a user can detect whether local/local_init works by setting the value before the do-concurrent loop and checking the value after it, i.e. this one needs code-gen changes.
shared/default(none) have no code-gen effect at all but together they provide a check that all variables are handled. 'reduce' can also be ignored unless there is concurrency which uses temporary variables to reduce cache coherency issues. But currently do-concurrent is not executed in parallel. (Ignoring potential SIMD/vectorization.)
Thus, there is for now a 'sorry' diagnostic when local/local_init is used — after resolving all constraints and issuing all diagnostic (e.g. for default(none) or when specifying a variable in a locality spec that is not actually used).
The plan is to add an actual implementation for local/local_init. — It's on my personal to-do list for GCC 15, but I am currently extremely busy with other urgent GCC tasks.
It is also planned to add actual concurrency, when and to what extend depends also on external funding. I guess that at least '!$omp loop' + do,concurrent (and !$omp target loop) have the chance to get implemented relatively soonish. (OpenMP since 6.0 permits '!$omp loop' on do concurrent. Before it was simply not permitted.)
I also had the plan to eventually add -fdo-concurrent=<no|some parallelization means> but let's see whether that will get implemented and with which options.
Tobias
