Hi Tobias! On 2019-10-15T11:42:12+0200, Tobias Burnus <tob...@codesourcery.com> wrote: > Permit more valid code by removing a too tight constraint – simple > patch, very long background & history (feel free to skip).
Thanks for writing that down, that's helpful to have in the archives.
(Certainly helps me, learning Fortran piece by piece.) ;-)
> openmp.c's "check_array_not_assumed" shows an error for:
> * assumed-size arrays (makes totally sense)
> * assumed-rank arrays (makes sense as long as TS29113/F2018 is not
> supported)
> * pointers which do not have the "contiguous" attribute
>
> Not only function name wise, the latter is the odd one out. While in
> many cases a contiguous memory is required, one can either make it a
> compile-time testable constraint ('simply contiguous') – or one puts the
> onus is on the programmer; the latter seems to be done in the
> OpenACC/OpenMP specs.
>
> (Of cause, it is also run-time checkable
OK, I was about to ask for that, if that makes sense to do.
> and gfortran uses a run-time
> test when passing a potentially noncontiguous array to a dummy argument
> with "contiguous" attribute; if the actual argument is contiguous, it is
> passed as is - otherwise, a copy-in and copy-out is performed [for
> intent(inout)].)
I read this such that what we've got is sufficient, no further run-time
checking is needed.
> HENCE: Remove a compile-time check when both specs (OpenMP/OpenACC) put
> the onus on the programmer. As compile-time checks are only a subset, we
> reject valid contiguous memory which is just not simply contiguous.
Is there any point in adding a test case for such constructs, in
particular, which the current code would've (erroneously) flagged as
"Noncontiguous deferred shape array", to codify/document that this is
supported?
> Additionally, the check only works if only an identifier is permitted as
> argument (it checks the symbol). For derived-type components, the check
> is not effective. (Assumed rank and assumed size are properties of dummy
> arguments, hence, those work fine.)
> OK for the trunk?
I'll gladly defer ;-) to your Fortran expertise as well as OpenACC
specification interpretation. (Test case, if feasible, pre-approved
anyway.)
> PS: This patch comes from the OG9 branch as
> ac6c90812344f4f4cfe4d2f5901c1a9d038a4000 but was actually already in the
> OG8 branch with commit d50862a7522446cf101eac9dc2e32967dc8318b7 from
> 2015 (!)
(Just for the record, before that on gomp-4_0-branch, and before that in
an internal development branch.) ;-)
> – I have used the ChangeLog entry from the latter.
ACK. Given that you've now re-researched all the rationale, it's
certainly fine to add your name, too. The ChangeLog date needs to be the
actual commit date.
Grüße
Thomas
signature.asc
Description: PGP signature
