J3/14-258 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #31 Date: 2014 October 14 Here are the results of J3 letter ballot #31 on Fortran interpretations that officially closed 6-Oct-2014. The ballot is in J3 paper 14-233r1 for meeting #205. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 / interp 108 109 112 113 114 result of LB #31 C N Y Y N Daniel Chen C N Y Y Y Malcolm Cohen Y C Y Y N Robert Corbett Y N Y Y C Bill Long Y N Y Y Y Toon Moene Y Y Y Y Y Dan Nagle Y N Y Y Y Van Snyder Y C Y Y Y Stan Whitlock Y N Y Y Y where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The comments for each interp are separated by a line of "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F08/0108 Ultimate components and coarrays Daniel Chen's yes vote with Comment on F08/0108: The answer of question 2 says X must be a "dummy argument or have the ALLOCATABLE or SAVE attribute." However, according to C525, such an entity whose type has a coarray ultimate component must not be allocatable. Should the word "ALLOCATABLE" be removed from the answer as it seems the answer is specific to X? Result for F08/0108: /INTERP agrees with Daniel's edit to remove "ALLOCATABLE or" from answer 2. F08/0108 as amended passed by J3 letter ballot. F08/0109 LOCK_TYPE and unlimited polymorphic Daniel Chen's No vote on F08/0109: I agree with Bill that Q3 violates C1302. I also agree with Bill's suggested modification for Q5. The test case in Q4 seems fine to me, but there is definitely a contradiction to C1302 that requires a fix. Malcolm Cohen's yes vote with comment on F08/0109: Bill Long writes: "The example Q3 has a variable, C, of type LOCK_TYPE that is not a coarray. This violates C1302. Answer A3 is wrong." No, it cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. C1302 ought to be fixed to say "declared type" explicitly, to avoid this confusion; [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". Bill continues: "For the same reason the example Q4 is defective and answer A4 is wrong. " For the same reason, there is nothing wrong with Q4. Bill continues: "The example code in Q5 is also defective, although could be repaired by changing the declaration of X to TYPE(LOCK_TYPE),SAVE :: X[*] That seems to be sufficient to make answer A5 acceptable." X should certainly be explicitly made a coarray, but giving it SAVE seems unnecessary (this might be a main program or module, or might be a subprogram with a global SAVE, or X might be a dummy argument). I guess it doesn't hurt though (other than looking a bit strange to have X saved but C not, so if we're going to SAVE one we should SAVE the other). Robert Corbett's No vote on F08/0109: I accept Bill's reasons for rejecting this interpretation. Bill Long's No vote on F08/0109: The example Q3 has a variable, C, of type LOCK_TYPE that is not a coarray. This violates C1302. Answer A3 is wrong. For the same reason the example Q4 is defective and answer A4 is wrong. The example code in Q5 is also defective, although could be repaired by changing the declaration of X to TYPE(LOCK_TYPE),SAVE :: X[*] That seems to be sufficient to make answer A5 acceptable. As Van noted, in the edit for [127:8-9] C643 should be C642. Dan Nagle's No vote on F08/0109: I agree with Bill's comments on 0109. Van Snyder's yes vote with Comment on F08/0109: "C643" in edit at [127:8-9] ought to be "C642" Stan Whitlock's No vote on F08/0109: I agree with Bill Long's reasons for voting NO on this interpretation. Result for F08/0109: /INTERP accepts Van's "C643 should be C642". In Q5 make X a coarray and add SAVE to both C and X. Make the edit to clarify C1302. /INTERP agrees with Malcolm that Q3 and Q4 are them ok. This is a difficult subject and /INTERP believes that the J3 meeting should vote again on F08/0109 with these changes. F08/0109 failed the J3 letter ballot. F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE All Yes votes, no Comments, and no No votes. Result for F08/0112: F08/0112 passed by J3 letter ballot. F08/0113 Specifiers in image control statements All Yes votes, no Comments, and no No votes. Result for F08/0113: F08/0113 passed by J3 letter ballot. F08/0114 Can LOCK_TYPE components have the POINTER attribute? Malcolm Cohen's No vote on F08/0114: This is just the wrong decision. People use pointers for all kinds of reasons, e.g. switching between two different structures, emulating optionality, etc. We allow pointers to be followed cross-image from a coarray, which means that pointers with a potential subobject of type LOCK_TYPE would indeed be useful in such scenarios. We should not add this new restriction; rather, we should remove the misguided "style preference" that is currently badly expressed by C1302. Robert Corbett's yes vote with Comment on F08/0114: I find the text of the proposed edit difficult to read. I prefer "C1302a A component that is of type LOCK_TYPE or that has a nonallocatable direct component of type LOCK_TYPE shall not have the POINTER attribute.". Result for F08/0114: /INTERP recommends that F08/0114 be returned to J3 for further consideration of Malcolm and Robert's comments along with checking other pending interps about LOCK_TYPE: F08/0045 constraints on entities of type LOCK_TYPE F08/0107 LOCK_TYPE, ultimate components, subcomponents, and coarrays F08/0109 LOCK_TYPE and unlimited polymorphic F08/0114 failed the J3 letter ballot. ------------------------------------------------------------------------ NUMBER: F08/0108 TITLE: ultimate components and coarrays KEYWORD: ultimate components, coarrays DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: 1. Is the declaration of V permitted: type :: one real, allocatable :: C[:] end type one type :: two type(one), allocatable :: A end type two type(two), pointer :: V(:) 2. Is the declaration of X permitted: type :: three real :: C end type three type :: four type(three), allocatable :: A[:] end type four type(four) :: X ANSWERS: 1. Type two is not conforming, because the entity A has a coarray ultimate component and C525 requires such an entity to be a nonpointer nonallocatable scalar. Therefore the declaration of V is not permitted. 2. X satisfies C525, so declaration of X is permitted. X has an ultimate (allocatable) coarray component (A[:]), and therefore acording to C526 must be a dummy argument or have the SAVE attribute. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 14-163 m204 F08/0108 submitted 14-163r1 m204 Fixed examples in questions, revised answer - passed by J3 meeting 14-xxx m205 Passed as amended by J3 letter ballot #31 14-233r1 ---------------------------------------------------------------------- NUMBER: F08/0109 TITLE: LOCK_TYPE and unlimited polymorphic KEYWORD: LOCK_TYPE, unlimited polymorphic DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is available. Q1. Is allocation of X%C permitted? TYPE t TYPE(LOCK_TYPE),ALLOCATABLE :: c END TYPE TYPE(t) :: x[*],y[*] ALLOCATE(y%c) ALLOCATE(x%c,SOURCE=y%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=L ) Q3. Is allocation of C permitted? class(*), pointer :: C allocate ( LOCK_TYPE :: C ) Q4. Is pointer assignment to C permitted? class(*), pointer :: C type(lock_type), intent(in), target :: L[*] c => L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE, SAVE :: C[:] TYPE(LOCK_TYPE), SAVE :: X[*] ALLOCATE(C,MOLD=X) ANSWER: A1. Allocation of X%C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A2. Allocation of C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A3. This allocation of C is permitted. It cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. Edits are given to fix C1302 to say "declared type" explicitly to avoid this confusion. A4. Pointer assignment to C is permitted. A5. This statement was intended to be permitted. An edit is supplied to correct the requirements. EDITS: [6:7+] After definition 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component (4.5.1)". [127:8-9] 6.7.1.1 Syntax, C642, Change "C_PTR," to "C_PTR or" Delete ", LOCK_TYPE ... LOCK_TYPE". [127:9+] Insert new constraint "C643a (R627) If SOURCE= appears, the declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." [127:18-19] 6.7.1.1, p4, "If" -> "If an ALLOCATE statement has a SOURCE= specifier and an", {There is no problem with MOLD=. "subcomponent" works ok here because we have an object not a type.} [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". SUBMITTED BY: Van Snyder HISTORY: 14-164 m204 F08/0109 submitted 14-164r3 m204 As amended, passed by J3 meeting 14-xxx m205 Failed the J3 letter ballot #31 14-233r1 Malcolm Cohen's yes vote with comment on F08/0109: Bill Long writes: "The example Q3 has a variable, C, of type LOCK_TYPE that is not a coarray. This violates C1302. Answer A3 is wrong." No, it cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. C1302 ought to be fixed to say "declared type" explicitly, to avoid this confusion; [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". Bill continues: "For the same reason the example Q4 is defective and answer A4 is wrong. " For the same reason, there is nothing wrong with Q4. Bill continues: "The example code in Q5 is also defective, although could be repaired by changing the declaration of X to TYPE(LOCK_TYPE),SAVE :: X[*] That seems to be sufficient to make answer A5 acceptable." X should certainly be explicitly made a coarray, but giving it SAVE seems unnecessary (this might be a main program or module, or might be a subprogram with a global SAVE, or X might be a dummy argument). I guess it doesn't hurt though (other than looking a bit strange to have X saved but C not, so if we're going to SAVE one we should SAVE the other). Van Snyder's yes vote with Comment on F08/0109: "C643" in edit at [127:8-9] ought to be "C642" Result for F08/0109: /INTERP accepts Van's "C643 should be C642". In Q5 make X a coarray and add SAVE to both C and X. Make the edit to clarify C1302. /INTERP agrees with Malcolm that Q3 and Q4 are them ok. This is a difficult subject and /INTERP believes that the J3 meeting should vote again on F08/0109 with these changes. F08/0109 failed the J3 letter ballot. ---------------------------------------------------------------------- NUMBER: F08/0112 TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER(80) text(0:100), msg INTEGER stat,istat(0:80) REAL,ALLOCATABLE :: x(:),y(:,:) ... ALLOCATE(x(10),STAT=stat,ERRMSG=text(stat)) ! A DEALLOCATE(x,STAT=stat,ERRMSG=text(stat)) ! B msg = '' ALLOCATE(y(999999,999999),STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! C msg = '' DEALLOCATE(x,STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! D In each of the statements labelled A-D, there is a dependency between the STAT= specifier and the ERRMSG= specifier (from STAT= to ERRMSG= in A and B, and from ERRMSG= to STAT in C and D). There appears to be no prohibition against this (though there are many prohibitions against other dependencies in ALLOCATE and DEALLOCATE). Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: These are not standard-conforming, as no interpretation is established for them. An edit is supplied to clarify this prohibition. EDITS: [132:4] 6.7.4 STAT= specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG= specifier, p1, append "The shall not depend on the value of the .". SUBMITTED BY: Malcolm Cohen HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting 14-xxx m205 Passed by J3 letter ballot #31 14-233r1 ---------------------------------------------------------------------- NUMBER: F08/0113 TITLE: Specifiers in image control statements KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER(80) text(0:100),msg INTEGER stat,istat(2) REAL,ALLOCATABLE :: x(:) TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*] LOGICAL acq, aacq(0:80) ... SYNC ALL(STAT=stat,ERRMSG=text(stat)) ! A SYNC IMAGES (*,STAT=stat,ERRMSG=text(stat)) ! B SYNC MEMORY(STAT=stat,ERRMSG=text(stat)) ! C LOCK(lock,ACQUIRED_LOCK=acq, & STAT=istat(MERGE(1,2,acq)), & ERRMSG=text(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=stat,ERRMSG=text(stat)) ! E LOCK(alock(stat),STAT=stat) ! F msg = '' UNLOCK(alock(LEN_TRIM(msg)),STAT=stat, & ERRMSG=msg) ! G stat = 13 SYNC IMAGES(stat,STAT=stat) ! H msg = 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=stat, & ERRMSG=msg) ! I In each of the statements labelled A-F, there is a dependency between the STAT= specifier and the ERRMSG= specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK= specifier and the STAT= specifier (there is no dependency between ACQUIRED_LOCK= and ERRMSG= because the former is only set on successful execution and the latter is only set on an error condition). There appears to be no restrictions at all on any dependencies from ACQUIRED_LOCK=. In the LOCK statement (F), there is a dependency between the STAT= specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG= specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT= variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG= variable and the image set. Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: No interpretation is established and therefore these are not conforming. An edit is provided to clarify this. EDITS: [190:16-] 8.5.4 SYNC IMAGES statement, insert new p1, "The value of shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the , , or .". [195:2-] 8.5.7 STAT= and ERRMSG= specifiers..., insert new p1, "The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 14-209 m204 F08/0113 submitted - passed by J3 meeting 14-xxx m205 Passed by J3 letter ballot #31 14-233r1 ---------------------------------------------------------------------- NUMBER: F08/0114 TITLE: Can LOCK_TYPE components have the POINTER attribute? KEYWORD: LOCK_TYPE component, POINTER DEFECT TYPE: Erratum STATUS: J3 consideration in progress Assume LOCK_TYPE is accessible from ISO_Fortran_Env. QUESTION: The following type definition and variable declaration are permitted by C1302: type :: One type(lock_type), pointer :: L end type One type(one), allocatable :: L1[*] C1302 requires a named variable of LOCK_TYPE to be a coarray. C526 requires a coarray to be allocatable or to have the SAVE attribute. The following declaration is apparently prohibited because L4 is not a coarray: type(lock_type), pointer :: L4 Was it intended that pointer components of type LOCK_TYPE be permitted, but that named variables of type LOCK_TYPE with the POINTER attribute be prohibited? ANSWER: It was intended that components of type LOCK_TYPE not be permitted to have the POINTER attribute. Edits are provided to correct this mistake. EDITS: [399:18+] 13.8.2.16 LOCK_TYPE, after C1302, insert new constraint "C1302a A component of type LOCK_TYPE, or that has a nonallocatable direct component of type LOCK_TYPE, shall not have the POINTER attribute.". SUBMITTED BY: Van Snyder HISTORY: 14-140 m204 F08/0114 submitted 14-140r1 m204 Revised to reverse decision 14-140r2 m204 Passed by J3 meeting 14-xxx m205 Failed J3 letter ballot #31 14-233r1 Malcolm Cohen's No vote on F08/0114: This is just the wrong decision. People use pointers for all kinds of reasons, e.g. switching between two different structures, emulating optionality, etc. We allow pointers to be followed cross-image from a coarray, which means that pointers with a potential subobject of type LOCK_TYPE would indeed be useful in such scenarios. We should not add this new restriction; rather, we should remove the misguided "style preference" that is currently badly expressed by C1302. Robert Corbett's yes vote with Comment on F08/0114: I find the text of the proposed edit difficult to read. I prefer "C1302a A component that is of type LOCK_TYPE or that has a nonallocatable direct component of type LOCK_TYPE shall not have the POINTER attribute.". Result for F08/0114: /INTERP recommends that F08/0114 be returned to J3 for further consideration of Malcolm and Robert's comments along with checking other pending interps about LOCK_TYPE: F08/0045 constraints on entities of type LOCK_TYPE F08/0107 LOCK_TYPE, ultimate components, subcomponents, and coarrays F08/0109 LOCK_TYPE and unlimited polymorphic ----------------------------------------------------------------------