ISO/IEC JTC1/SC22/WG5 N2119 WG5 straw ballot on technical changes John Reid, 28 October 2016 This is a WG5 straw ballot on four technical changes to Fortran 2015 that were passed by J3 at its recent meeting. They are all very minor, rather like interpretation changes, but they are technical changes and are therefore outwith the authority of J3. This ballot is modeled on what we do for for interpretations. They have been passed by J3 and need to be approved by WG5. The following changes are being balloted: Yes No Paper Subject --- --- 16-277r1 Allow C_SIZEOF for an assumed-rank array --- --- 16-280r2 Allow cross-image access to violate aliasing rules for coarray dummies --- --- 16-285r2 Clarify ordering of finalisation w.r.t. deallocation in assignment --- --- 16-289 Additional prohibitions on pure procedures The four J3 papers that contain the edits and discussions are appended. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send to sc22wg5@open-std.org by 0900 UK time on Friday, 25 November 2016, in order to be counted. Thanks, John. ............................. J3/16-277r1 To: J3 From: Bill Long Subject: Date: 2016 October 11 Discussion: In 8.5.8.7 Assumed-rank entity, C838 has limitations on what can be done with assumed-rank objects. The list was expanded from the initial version to allow assumed-rank arguments to intrinsic inquiry functions. But now that we allow both BIT_SIZE() and SIZE(), it seems reasonable to also allow C_SIZEOF from ISO_C_BINDING? The information available from BIT_SIZE() and SIZE() are enough to compute C_SIZEOF(). I think this was probably an unintentional omission. Edit to 16-007r2: [107:16-17] In 8.5.8.7 Assumed-rank entity, in the second constraint (C838), change "function C_LOC" to "functions C_LOC or C_SIZEOF". ............................. 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." ............................. To: J3 Members J3/16-285r2 From: Van Snyder & Malcolm Cohen Subject: Amendment to Interp F08/0013 References: 16-007r2, 16-257 Date: 2016 October 13 1. Introduction =============== Interp F08/0013 introduced text that is in 7.5.6.3p1 "When finalization occurs": "If the variable is an allocated allocatable variable that would be deallocated by intrinsic assignment, the finalization occurs before the deallocation." This overlooked allocated allocatable ultimate components. Finalization of an allocatable subobject during intrinsic assignment needs to be clarified. 2. Edits to 16-007r2 ==================== [xviii Introduction, under "Data usage and computation"] insert an item "Finalization of an allocatable subobject during intrinsic assignment has been clarified." [84:29 7.5.6.3p1 "When finalization occurs"] After "allocated allocatable variable" insert ", or has an allocated allocatable subobject,", making the whole paragraph read: "When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable. If the variable is an allocated allocatable variable, or has an allocated allocatable subobject, that would be deallocated by intrinsic assignment, the finalization occurs before the deallocation." [84:32 7.5.6.3p2 "When finalization occurs"] Replace "component" with "subobject", making the whole paragraph read: "When a pointer is deallocated its target is finalized. When an allocatable entity is deallocated, it is finalized unless it is the variable in an intrinsic assignment statement or a subobject thereof. If an error condition occurs during deallocation, it is processor dependent whether finalization occurs." ............................. J3/16-289 To: J3 From: Malcolm Cohen Subject: Pure statement functions are too volatile Date: 2016 October 12 1. Problems Consider the following module: Module m Use Iso_C_Binding Integer(C_int),Volatile :: vcount Contains Subroutine s(x) Integer i,pure_stmtfn,x(:) pure_stmtfn() = vcount Forall (i=1:Size(x)) x(i) = pure_stmtfn() End Subroutine End Module Statement function pure_stmtfn is pure because it references no impure function. However, vcount may change at any time so this is not actually pure. This was fixed for normal pure procedures by Interp F03/0126, which prohibited the designator of a VOLATILE variable from appearing within a pure subprogram. However, it did not address statement functions. Also, it appears that the following is valid, as long as the variable Z is not used. Pure Subroutine strange(y) Integer,Intent(Out) :: y Integer,Volatile :: z y = 0 End Subroutine Permitting Z to be declared, but not used, within STRANGE is strange. 2. Solution Therefore we should do the same as F03/0126 for statement functions. This will be a new incompatibility with Fortran 2003/8. We should also fix this gratuitous strangeness with local volatiles. It will also be a new incompatibility with Fortran 2003/8. Note that we could address this via the interpretation process, but given the timing, and especially since statement functions are obsolescent, it seems simpler just to make the change to F2015. 3. Edits to 16-007r2 [30:30+] 4.3.3 Fortran 2008 compatibility, after p3, insert new paragraph "Fortran 2008 permitted a pure statement function to reference a volatile variable, and permitted a local variable of a pure subprogram or of a BLOCK construct within a pure subprogram to be volatile (provided it was not used); this document does not permit that." {Incompatibility with Fortran 2008.} [31:21+] 4.3.4 Fortran 2003 compatibility, after p9, insert new paragraph "Fortran 2003 permitted a pure statement function to reference a volatile variable, and permitted a local variable of a pure subprogram to be volatile (provided it was not used); this document does not permit that. {Incompatibility with Fortran 2003.} [336:14] 15.7 Pure procedures, p1, After "only pure functions" insert "and does not contain the of a variable with the VOLATILE attribute" (all in obsolescent font). {Prohibit pure statement function from referencing a volatile variable.} [336:29] same subclause, C1593, between "not have the SAVE" and "attribute" insert "or VOLATILE". {Prohibit a local volatile variable in a pure subprogram.}