[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104131

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to anlauf from comment #7)
> (In reply to Tobias Burnus from comment #6)
> > !$omp task detach (x)
> >       !$omp end task
> > 
> > This seems to be valid. OpenMP mostly only rejects coindexed variables like:
> 
> Alright, I did not expect this, and no other compiler I have access to
> accepts it.

On the technical side, a coarray is just a normal variable that is also
remotely accessible; I think it is usually just 'malloc'ed but in principle the
coarray library could allocate it also in special memory.
There might be some issues when used inside target regions, i.e. on a device
with shared memory (page migrations etc.) but, otherwise, there is no real
reason to disallow it.

Of course, everything related to memory allocation or coindexed access will not
work (in general - at least some special cases will fail).

* * *

In terms of the OpenMP specification, there is a section "Normative
References";

* in OpenMP 5.0, it has: "Fortran 2008 ... their use may result in unspecified
behavior ... Coarrays"

* in OpenMP 5.1, there are no exceptions for 2008 and Fortran 2018 with a new
list of unspecified behavior was added.

Thus, coarrays were never explicitly rejected but in 5.0 their use might result
in unspecified behavior, i.e. an implementation could reject it.
Since 5.1, they can be used where deemed to be okay.

(Disclaimer: What might be okay for most implementation can be unimplementable
in another; additionally, some corner cases might have been overlooked which do
cause problems.)

* * *

My quotes in comment 6 were from OpenMP 5.2, the latest release. TR11 (pre-6.0)
is the latest spec, semi-solid but breaking changes are permitted until the
final 6.0 (to fix oversights).