(j3.2006) Question about pointer components of coindexed objects

[Bill Long]

> On Jul 24, 2017, at 1:25 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 
> Hi folks,
>  
> Consider:
>  
> Program n9a
>   Type t
>     Integer,Pointer :: p
>   End Type
>   Type(t) x[*]
>   Nullify(x[1]%p)
>   Print *,'ok if F?',Associated(x[1]%p)
> End Program
>  
> There are two questions:
>  
> (1)  Is the NULLIFY conforming?  It certainly looks conforming to me.  However another compiler claims that it is not permitted.

In this context, no. The program runs wildly afoul of the segment ordering rules, particularly 11.6.2p3 bullet 2.  However, I think this alternative, which is pedantically synchronized, illustrates the point you are trying to make:

> cat test.f90
 
Program n9a
  Type t
    Integer,Pointer :: p
  End Type
  Type(t) x[*]
  integer,target :: tg = 1

  if (this_image() == 1) then
     x%p => tg
  end if
  sync all
  if (this_image() == 2) then
     Nullify(x[1]%p)
  end if
  sync all
  if (this_image() == 3) then
     Print *,'ok if F?',Associated(x[1]%p)
  end if
End Program

This version does compile and execute with the Cray compiler (not in itself any proof of standard conformance):

> ftn test.f90
> srun -n4 ./a.out
 ok if F? F
> 

I added in the operation on image 1 to avoid possible ambiguity in the output.  Pointers start out as having undefined association status, but the internal representation for that might be the same as disassociated.  To guard against the possibility that the nullify( ) had no effect, starting with the state being associated seemed safer. 

Is the whole program conforming?

The statement executing on image 1

    x%p => tg

is the poster child for what we intend to allow.  Association of a pointer component of a coarray with a local target. 

The statement executing on image 2

   Nullify(x[1]%p)

is the real question here.  I don?t see where this is specifically prohibited.  While we don?t allow a pointer component of a coindexed object to be pointer assigned to a target on a different image, we do allow such a component to have its pointer association status changed to undefined, for example, in an assignment like

    x[1] = x

So we explicitly allow a statement execution on one image to ?mess with? the pointer association status of a pointer on a different image. We specifically allow it to change to undefined. We specifically prohibit from becoming associated (with a nonlocal target).  The nullify case, the third alternative - disassociated, is less clearly spelled out.  I appreciate John?s observation that => NULL() is not allowed.  However, I think that was a special case of a disallowed pointer assignment.   The text in 9.7.2 (NULLIFY statement) does not prohibit this case.  By that omission, the case is technically allowed.  So a change to make it disallowed would be a technical change. 


>  
> (2) If the ASSOCIATED conforming?  Since we?re allowed to follow pointers on other images, e.g. ?x[1]%p = 3?, I don?t see why it should be a problem.  However, one compiler thinks it falls foul of 
>                 C1542 The actual argument corresponding to a dummy pointer shall not be a coindexed object.
> It is not at all obvious that C1542 should apply to intrinsic procedures?

Agreed. We normally don?t talk about the dummy arguments of intrinsics.  Particularly ones like ASSOCIATED that are likely implemented with inline code, so there is no actual function definition anywhere. 


>  A second compiler claimed that x[1]%p was not a pointer, throwing further confusion onto the fire.

I suspect this is an older version of said compiler (I saw this as well) that did not have the code for pointer component of a coarray structure completed yet.  Obviously P is a pointer. 


>  Anyway, I think that either ASSOCIATED should say that you can?t use it on coindexed objects, or C1542 should be followed by a Note saying it does not apply to the ASSOCIATED intrinsic, to clarify the situation.
>  

A lot of the text in 15.5 does not apply to many of the intrinsics.   If we do something, I?d prefer a Note that allows ASSOCIATED in this case.   C1542 is aimed at preventing pointer association with a nonlocal target.   Note that there is no such imitation for allocatable components appearing in an ALLOCATE statement.   The programmer certainly wants to be able to perform such inquiries on remote objects before attempting references or definitions of the remote data. 

Cheers,
Bill



> Any comments about these cases would be welcome (especially from Bill!).
>  
> Cheers,
> -- 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>  
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425