Hi Thomas,
I have started with this email – and then stopped and replied to the
other email in this thread:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02678.html – which covers
parts which otherwise would belong into this email.
On 11/28/19 6:02 PM, Thomas Schwinge wrote:
[Test case which uses common blocks in device_resident.]
If you'd like to, please commit that, to document the status quo. (I
have not reviewed.)
Did so as r278845 with a slightly updated comment.
Observations:
* !$acc declare has to come after the declaration of the common block.
That's now tracked in PR fortran/92728 for OpenMP/OpenACC – together
with blank commons.
Good find -- purely a Fortran front end issue […] is a reason
(implementation complexity?)
Having any order makes it feel more Fortran like; the complexity comes
from splitting matching and checking the clauses, but it shouldn't be
rocket science.
* If I just use '!$acc parallel', the used variables are copied in
according to OpenMP 4.0 semantics, i.e. without a defaultmap clause (of
OpenMP 4.5+; not yet in gfortran), scalars are firstprivate and arrays
are map(fromto:). – Does this behaviour match the spec or should this
automatically mapped to, e.g., no_create as the 'device_resident' is
known? [Side remark: the module file does contain
"OACC_DECLARE_DEVICE_RESIDENT".]
Not sure at this point.
s/OpenMP 4.0/OpenMP 4.5/
Regarding the mapping: Both OpenACC and OpenMP agree and it is fine (cf.
OpenACC 2.7 last 'Description' paragraph in parallel/kernels, 2.5.1 +
2.5.2). And OpenMP 4.5, Sect. 2.15.5 (esp. last three bullet points) or
OpenMP 5, Sect. 2.19.7. (Missing omp bits see PR fortran/92568.).
Regarding device_resident: It is not fully clear to me what the intent
is – and "The host may not be able to access variables in a
device_resident clause." does not make it clearer.
In terms of the spec, the mapping with firstprivate/[copy alias tofrom]
is fine – as is the explict use of present. However, if commons exists
on both device + host, 'copy(/block/)' should work and also copy
common-block variables, which are not referrenced in the
parallel/kernels block – which currently does not work.
* If I explicitly use '!$acc parallel present(/block/)' that fails
because present() does not permit common blocks.
(OpenACC 2.7, p36, l.1054: "For all clauses except deviceptr and
present, the list argument may include a Fortran common block name
enclosed within slashes").
Do you understand the rationale behind that restriction, by the way? I'm
not sure I do.
Regarding 'present', I don't: If copy/no_create is fine, why should
present be a problem? (And vice versa.)
For 'deviceptr', it kind of does make sense – unless one wants to store
the pointer as 'intptr_t' in an integer variable or want to have a
pointer (i.e. Fortran attribute) in 'common' which will cause mapping
problems for the common block. — In any case, the 'dummy argument'
constraint prevents common blocks. – BTW: Those constraints do not make
sense but seem to be same as for OpenMP's is_device_ptr. (They are both
too loose and to strict; I miss type(c_ptr) [as local var + as dummy w/
value attribute].)
Cheers,
Tobias
