Tobias Burnus wrote:
gfortran currently rejects:
subroutine foo(n)
integer, SAVE :: foo(500)[n, *]
claiming that as SAVE does not work with automatic arrays.
The patch for this has been committed (Rev. 174503) after approval by
Daniel Kraft on IRC (#gfortran).
Thomas Koenig wrote:
To me, that sounds a lot like a mistake in the standard. Maybe ask on
c.l.f?
It is not completely clear to me what you mean by mistake. Coarrays are
kind of special in several respects. Except of deferred-shape coarrays
(i.e. allocatable coarrays), the codimension is always assumed site,
independently whether the dimension makes the coarray a scalar,
explict-size, assumed-size, or assumed-shape array:
integer :: A[*]
integer :: B(:,:,:)[4,5:*]
integer :: C(*)[1:*]
integer :: D(5)[1:*]
but
integer, allocatable :: E(:)[:]
This works as the codimension (coshape) does not influence the storage
but just the index calculation between coindex and image index, when
accessing remote images. Thus, there is no reason why one should pose
restrictions on the coshape for static arrays. (By definition, all
coarrays are either static ("SAVE") or allocatable.)
I think in some cases, it can be really useful. As the size of the
codimension is only known at run time (it's num_images()), it can make
sense to define the coshape only at run time - even if the shape itself
is a compile-time constant.
Another peculiarity is that for a coarray "integer :: A(10,10)[*]" the
actual argument remains a coarray in: call proc(A), call proc(A(1,1)),
call proc(A(:,1)), call proc(2:3,4) etc. (I think the actual argument
needs to be simply contiguous to make this work by preventing
copy-in/copy-out.) Note: call proc(A[5]) is coindexed, but not a coarray.
Tobias
