To: J3 J3/16-280r2 From: R. Bader & Bill Long Subject: coarray dummy arguments and aliasing rules Date: 2016 October 13 References: 16-007r2, TS18508, 16-174 Introduction: ~~~~~~~~~~~~~ This paper is a rewrite of 16-174 that attempts to resolve a problem with coindexed write accesses to dummy arguments. Paper 16-174 was submitted to meeting 210 and had "no action". Discussion: ~~~~~~~~~~~ Consider the following example program, to be executed with at least 2 images: PROGRAM example_1 INTEGER :: a[*], il il = this_image() CALL sub(a, il) CONTAINS SUBROUTINE sub(b, il) INTEGER :: b[*], il SELECT CASE (this_image()) CASE (1) b[2] = il ! (X) SYNC ALL CASE (2) SYNC ALL il = b ! (Y) WRITE(*,*) il CASE DEFAULT SYNC ALL END SELECT END SUBROUTINE END PROGRAM Question 1A: Was it intended that the program example_1 is conforming? Answer 1A: Yes, it is intended that this example is conforming. It compiles with no errors and executes: > ftn test.f90 > srun -n2 ./a.out 1 {It appears to me that this example currently is not conforming based on the F2008 as well as 16-007r2 specifications, because the statement marked (X) constitutes a violation of the anti-aliasing rule 16-007r2/15.5.2.13 para 1 item (3) on image 2: The object a on image 2 is modified through something else than image's 2 dummy argument. If this reasoning is correct and the intent is for the program to be conforming, edits are needed to fix the problem.} Question 1B: Was it intended that the program example_1 is conforming if statement (Y) is replaced by "il = a"? Answer 1B: No, with this change the code would violate the anti-aliasing rules. {If the answer to 1A is "no", this question is of course trivial.} Next, consider a second example program, again for at least 2 images: PROGRAM example_2 USE, INTRINSIC :: iso_fortran_env INTEGER(atomic_int_kind) :: a[*]=0, il il = this_image() SELECT CASE (this_image()) CASE (1) CALL sub_1(a, il) CASE (2) CALL sub_2(a, il) WRITE(*,*) il END SELECT CONTAINS SUBROUTINE sub_1(b, il) INTEGER(atomic_int_kind) :: b[*], il CALL ATOMIC_DEFINE(b[2],il) ! (Z) END SUBROUTINE SUBROUTINE sub_2(b, il) INTEGER(atomic_int_kind) :: b[*], il il = 0 DO WHILE (il == 0) CALL ATOMIC_REF(il, b) END DO END SUBROUTINE END PROGRAM Question 2: Was it intended that the program example_2 is conforming? Answer 2: Yes, it is intended that this example is conforming. It compiles with no errors and executes: > ftn test2.f90 > srun -n2 ./a.out 1 {To my knowledge, the intent was that it should be possible to coordinate actions between two procedures in the manner illustrated by the code above. See also MR&C, Modern Fortran Explained, Section 19.6, last two paras. However, again the rule 16-007r2/15.5.2.13 para 1 item (3) appears to be violated, namely by statement (Z).} Edits to 16-007r2: ------------------ [xix] Introduction, para 2, at the end of the bullet section Program units and Procedures, append "A coarray dummy argument can be referenced or defined by another image." [324:14] In 15.5.2.13 Restrictions on entities associated with dummy arguments, delete "or". [324:16] In 15.5.2.13 Restrictions on entities associated with dummy arguments, change the final "." to ", or". [324:16+] In 15.5.2.13 Restrictions on entities associated with dummy arguments, Add another item to (3): "(d) the dummy argument is a coarray and the action is a coindexed definition of the corresponding ultimate argument coarray from a different image." [324:24] In 15.5.2.13 Restrictions on entities associated with dummy arguments, delete "or". [324:26] In 15.5.2.13 Restrictions on entities associated with dummy arguments, change the final "." to ", or". [324:26+] In 15.5.2.13 Restrictions on entities associated with dummy arguments, Add another item to (4): "(d) the dummy argument is a coarray and the reference is a coindexed reference of its corresponding ultimate argument coarray from a different image." [326:1-] At the end of 15.5.2.13 Restrictions on entities associated with dummy arguments, After NOTE 15.40 add "NOTE 15.40+1 The exception to the aliasing restrictions for dummy coarrays enables cross-image access while the procedure is executing. Because nonatomic accesses from different images typically must be separated by an image control statement, code optimization within segments is not unduly inhibited."