Re: [Patch][Fortran] OpenACC – permit common blocks in some clauses

[Tobias Burnus]

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