On Thu, 05 Jul 2007 15:01:51 +0900, Yasuki Arasaki <[log in to unmask]>
wrote:
> Remapping array ranks with a helper procedure made me concerned
> about the CONTIGUOUS attribute in the Fortran 2008 draft.
There are matters of concern re CONTIGUOUS, but I don't believe
this is one of them.
> Malcolm Cohen wrote:
>>> This is better than using RESHAPE since it allows the called procedure
>>> to update the array (and maybe also avoids a copy). If you don't have
>>> rank remapping available you can achieve a similar effect via a set of
>>> helper procedures.)
I actually meant a set of helper procedures that called the intended
routine,
not ones that played non-portable tricks with pointers.
> I assume the helper procedure mentioned here is something like this:
>
> SUBROUTINE HELPER(SHAPE,T,P)
> INTEGER, INTENT(IN) :: SHAPE(:)
> REAL, INTENT(IN), TARGET :: T(SHAPE(1),SHAPE(2),SHAPE(3))
> REAL, POINTER :: P(:,:,:)
>
> P => T
> END SUBROUTINE HELPER
That is not quite what I had in mind, though it will probably work
on most systems provided the argument is contiguous.
> That allows the processor to retain the processor association of P even
> after returning from HELPER, so that the scheme works (it does work on
> several processors that I tried).
The standard says that the status of P is "processor dependent".
On some processors it might "work", on other processors P might become
undefined or disassociated, on still other processors it might work on
Thursdays only and not on any other day of the week.
> I was rather surprised when I learned of this (in a post mid-May in
> this list), because it works even when the actual argument is not
> contiguous.
>
> CALL HELPER((/ 2, 2, 2 /),A(::2),P)
No, that doesn't work. See next comment.
> Passing a non-contiguous array to an explicit shape dummy usually
> involves copy-in/copy-out
Right, depending on the machine and the compiler. In practice, all or
nearly all current compilers will make a copy for this particular code.
P will become undefined. (Viz, P will be left describing the array
temporary that was created for the call to HELPER, and since that temporary
will be deleted on return from HELPER, P will be "dangling".)
> I suppose this works
It might have appeared to work for you, but it is not guaranteed and
is in fact highly unlikely to work on any current compiler.
> Now there is a new CONTIGUOUS attribute in the Fortran 2008 draft.
> It asserts that a pointer is always associated with a contiguous target.
> Explicit shape dummy arrays cannot have the CONTIGUOUS attribute.
Right...
> As the draft is written, explicit shape dummy arrays are assumed to
> be contiguous.
Not "assumed to be", they *are* contiguous (by definition).
...
> Now P, with the CONTIGUOUS attribute, is associated with A(::2)
> which is not contiguous.
No, P is undefined, just like it was in the previous example.
> If I read correctly, there isn't anything
> in the draft to prevent this. Something is not consistent here.
> Is this intentional?
I don't there is anything inconsistent here.
Cheers,
--
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.
|