ISO/IEC JTC1/SC22/WG5 N2042 Fortran Interpretations awaiting WG5 ballot Stan Whitlock Note N: d == done {if S = C* | T*, then done is assumed} * == active Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot X Excluded for the reasons given C1 In F2008 Corrigendum 1 C2 In F2008 Corrigendum 2 C3 In F2008 Corrigendum 3 N S T number title - - - ------ ----- * B I F08/0099 VOLATILE in specification expressions * B E F08/0100 IMPORT statement and prior explicit declaration * B E F08/0101 NAMELIST and multiple occurrences of a variable * B E F08/0102 MERGE and polymorphism * B E F08/0103 Pointers to internal procedures with different host instances * B E F08/0104 IEEE Inquiry Functions * B E F08/0106 MOVE_ALLOC for a remote array * B I F08/0108 ultimate components and coarrays * B E F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE * B E F08/0113 Specifiers in image control statements ---------------------------------------------------------------------- NUMBER: F08/0099 TITLE: VOLATILE in specification expressions KEYWORD: VOLATILE, specification expression DEFECT TYPE: Interpretation. STATUS: Passed by J3 letter ballot QUESTION: Is the following subprogram required always to print "T T"? subroutine Wobbly ( N ) integer, volatile :: N integer :: A ( n, n ) integer :: B ( n * n ) print *, size(a) == size(b), size(a,1) == size(a,2) end subroutine Wobbly ANSWER: No. There are three specification expressions in the subroutine, and the volatile variable N appears in each of them. Since, being volatile, the variable N might have a different value each time it is referenced, these three specification expressions might receive different values for their references to N. If that happens, the array sizes might well be different. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 13-298r1 m202 F08/0099 submitted 13-298r2 m202 Revised answer - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Does the following program fragment conform to the 2008 standard? subroutine S ( P ) interface subroutine Q ( X ) real, intent(inout) :: X end subroutine Q end interface interface subroutine P ( A ) import procedure (R) :: A end subroutine P end interface procedure (Q) :: R end subroutine S 12.4.3.3p2 says "If an entity that is made accessible by this means is accessed by host association and is defined in the host scoping unit, it shall be explicitly declared prior to the interface body." However, although the procedure R is declared in the host scoping unit it is not defined in the host scoping unit, so this is ineffective. Q2. If the IMPORT statement were changed to "IMPORT R", would that be conforming? 12.4.3.3p1 says "An entity that is imported in this manner and is defined in the host scoping unit shall be explicitly declared prior to the interface body." Again, procedure R is declared but not defined in the host scoping unit, so this requirement is ineffective. ANSWER: These examples were not intended to conform to the Fortran standard. An edit is provided. EDITS: [282:7] 12.4.3.3p1, after "imported in this manner and is" change "defined" to "declared". [282:14] p2, after "is accessed by host association and is" change "defined" to "declared". SUBMITTED BY: Van Snyder HISTORY: 13-305 m202 F08/0100 submitted 13-305r1 m202 Revised answer & edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program p1 Real :: x = 3, y = 4 Namelist /n/ x, y Write (*,n) End Program According to 5.6, "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, this stops short of saying that the order is the same, merely that it determines it. Perhaps it might be standard-conforming for a processor to always produce the values in reverse order, for example. 10.11.4 does not seem to address the issue of what the order is. Q1: Is the order meant to be the same? Consider Program p2 Real :: x = 3, y = 4 Namelist /n/ x, y, x Write (*,n) End Program This program did not conform to Fortran 90, but does conform to Fortran 2003 and later. The Fortran 2008 standard says (5.6p2): "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, there are only two variables in the NAMELIST statement, X and Y. Therefore it seems to be ambiguous whether the output should be something like &N X=3 Y=4 / or &N Y=4 X=3 / Some compilers produce &N X=3 Y=4 X=3 / but this is not an ordering of the variables X and Y. Q2. Is this program intended to conform to the standard, and if so, what is the intended output? ANSWER: A1. Yes, the order is meant to be the same. An edit is supplied to clarify this. A2. The program was intended to conform to the standard, and the output was intended to be the third option. An edit is supplied to correct the text in 5.6. EDIT: [111:13-14] 5.6p2, replace entire paragraph with "The order in which the values appear on output is the same as the order of the s in the namelist group object list; if a variable appears more than once as a for the same namelist group, its value appears once for each occurrence". SUBMITTED BY: Malcolm Cohen HISTORY: 13-314 m202 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program test Type t End Type Type,Extends(t) :: t2 End Type Class(t),Allocatable :: x,y Type(t),Allocatable :: a x = t() y = t2() a = t() Do i=1,2 Select Type (z=>Merge(a,x,i==1)) ! A Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(x,a,i==1)) ! B Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(a,y,i==1)) ! C Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(y,a,i==1)) ! D Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(x,y,i==1)) ! E Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do End Program According to the standard, the type of the result of MERGE is the same as the type of TSOURCE. One might imagine that this means that the result is polymorphic if and only if TSOURCE is polymorphic. This would be a slightly unusual and unexpected asymmetry. Also, the types of FSOURCE and TSOURCE have to be the same. If this means both the declared and dynamic types, one might imagine that this means that the result is polymorphic if and only if both FSOURCE and TSOURCE are polymorphic, since otherwise the non-polymorphic argument decides the type. On the other hand, if the type requirements are talking about the declared type only, one might imagine that the result is polymorphic if either TSOURCE or FSOURCE is polymorphic. However, in any case there would seem to be an error in the standard, since the result is specified to be the same as TSOURCE, rather than the same as whichever argument is chosen to be the result value; if this refers to the dynamic type, it is contradictory when FSOURCE is chosen as the result value. And if it does not refer to the dynamic type, there appears to be no statement which says what the dynamic type of the result is. Q1. Is the apparent asymmetry between the treatment of TSOURCE and FSOURCE intended? Q2. Which of the MERGE invocations A-E are polymorphic? Q3. When the result of MERGE is polymorphic, are the dynamic types of TSOURCE and FSOURCE permitted to be different? And if they are, is the dynamic type of the result the same as the chosen argument and not necessarily the same as TSOURCE? ANSWER: A1. There is no asymmetry between TSOURCE and FSOURCE, because they are required to have the same type and type parameters. This means that both the declared and dynamic types and type parameters must be the same. A2. Only MERGE invocation E is polymorphic. An edit is provided to clarify this. A3. No, the dynamic types and type parameters are required to be the same. Note that because MERGE is elemental, it needs the type and type parameters to be the same for both the declared and dynamic types, otherwise the principle that all elements of an array have the same (declared and dynamic) type and type parameters would be broken. EDITS: [368:26] 13.7.110p4 (Result Characteristics), "Same as TSOURCE." -> "Same type and type parameters as TSOURCE. Because TSOURCE and FSOURCE are required to have the same type and type parameters (for both the declared and dynamic types), the result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." SUBMITTED BY: Malcolm Cohen HISTORY: 13-321 m202 F08/0102 submitted 13-321r1 m202 Revised example - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0103 TITLE: Pointers to internal procedures with different host instances KEYWORD: internal procedure, procedure pointer, host instance DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider: MODULE TYPES ABSTRACT INTERFACE SUBROUTINE SUBROUTINE() END SUBROUTINE SUBROUTINE END INTERFACE TYPE PPS PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR END TYPE PPS END MODULE TYPES SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTEGER I, J, N N = SIZE(PPA) DO I = 1, N CALL PPA(I)%SU_PTR() END DO PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N) END SUBROUTINE CPPS RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTERFACE SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE CPPS END INTERFACE IF (SIZE(PPA) .EQ. 3) THEN CALL CPPS(PPA) ELSE CALL OUTER( (/ PPA, PPS(INNER) /) ) END IF CONTAINS SUBROUTINE INNER() WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA) END SUBROUTINE INNER END SUBROUTINE OUTER PROGRAM MAIN USE TYPES INTERFACE RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE OUTER END INTERFACE TYPE(PPS),DIMENSION(0) :: PPA CALL OUTER(PPA) END PROGRAM MAIN Does this program print all true values? The procedure pointers are all associated with the internal procedure INNER, which might lead one to believe that the answer is yes (that is, they are all associated with the same target), but each procedure pointer at each nesting level has a different host instance, which might lead one to believe that the answer is no (and that therefore only one of each of the 3-element sequences printed will be T). ANSWER: No, the program does not print all true values; two procedure pointers to the "same" internal procedure are only associated if the host instances are also the same. An edit is supplied to the standard to clarify this. EDITS: [330:20] 13.7.16p5 Case (ii), after "with TARGET" insert "and, if TARGET is an internal procedure, they have the same host instance". [330:22] Case (iii), after "same procedure" insert "and, if the procedure is an internal procedure, they have the same host instance". SUBMITTED BY: Robert Corbett HISTORY: 13-357 m202 F08/0103 submitted with four answers 13-357r1 m202 Selected answer, added edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot All references are to Fortran 2008 10-007r1. On comp.lang.fortran Francis Coudert asked The Fortran 2008 standard defines an inquiry function as an "intrinsic function, or function in an intrinsic module, whose result depends on the properties of one or more of its arguments instead of their values". 10-007r1 section 1.3.89 [11:27-30] I wonder: by that definition, how can the IEEE_SUPPORT_HALTING(FLAG) function from the IEEE_EXCEPTIONS intrinsic module be an inquiry function? Its result depends on the value of FLAG, not its properties. QUESTIONS: Question 1. Are the functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc intended to be inquiry functions? Question 2. Are they consistent with the definition of inquiry functions? Question 3. Are they allowed in Specification expressions? Question 4. Are they allowed in Constant expressions? ANSWERS: Answer 1. No. These intrinsic module functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc are not inquiry functions because their results depend on other than the properties of their arguments. Edits are provided to correctly identify these functions as transformational: [18:35-37] section 1.3.146 transformational function intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function Answer 2. No. Their current classification is inconsistent with the definition of inquiry functions. Answer 3. They should be allowed in specification expressions. Edits are provided to correct this. Answer 4. No. Only the 3 IEEE_* functions should be allowed in constant expressions, not the 3 C_* functions. Edits are provided to correct this. EDITS to 10-007r1: [150:28+] section 7.1.11 Specification expression, paragraph 2, after bullet (10), insert a new bullet: "(nn) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14) or the intrinsic module ISO_C_BINDING (15.2), where each argument is a restricted expression," [152:7-8] section 7.1.12 Constant expression, paragraph 1, replace bullet (8): "(8) a reference to the transformational function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE ARITHMETIC (14), where each argument is a constant expression," with: "(8) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant expression," [407-408:24+] section 14.10 Summary of the procedures, paragraph 3, in Table 14.1, for procedure IEEE_SUPPORT_ROUNDING: change the "Class" column entry from "I" to "T". [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.2, for procedures IEEE_SUPPORT_FLAG and IEEE_SUPPORT_HALTING: change the "Class" column entries from "I" to "T". [418:16] section 14.11.27 IEEE_SUPPORT_FLAG (FLAG) or IEEE_SUPPORT_FLAG (FLAG, X), paragraph 2: "Inquiry function." -> "Transformational function." [418:32] section 14.11.28 IEEE SUPPORT HALTING (FLAG), paragraph 2: "Inquiry function." -> "Transformational function." [420:4] section 14.11.32 IEEE_SUPPORT_ROUNDING (ROUND_ VALUE) or IEEE_SUPPORT_ROUNDING (ROUND_VALUE, X), paragraph 2: "Inquiry function." -> "Transformational function." [426:19] section 15.2.3.2 C_ASSOCIATED (C_PTR_1 [, C_PTR_2]), paragraph 2: "Inquiry function." -> "Transformational function." [428:9] section 15.2.3.5 C_FUNLOC (X), paragraph 2: "Inquiry function." -> "Transformational function." [428:21] section 15.2.3.6 C_LOC (X), paragraph 2: "Inquiry function." -> "Transformational function." SUBMITTED BY: Dick Hendrickson HISTORY: 14-100 m203 F08/0104 submitted 14-100r1 m203 Answer proposed 14-100r2 m203 Passed by J3 meeting 14-192 m204 Passed as amended by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that MOVE_ALLOC can affect the allocation status of an array on an image other than the executing image? An example is CALL MOVE_ALLOC(A,B[I]%A) ANSWER: No, it was not intended that the executing image can affect the allocation status of an array on an image other than the executing image. Edits are provided to correct this. EDITS to 10-007r1: 13.7.118 MOVE_ALLOC(FROM,TO), para 3: [372:18] In the description of FROM, after "It shall be allocatable", add "and shall not be a coindexed object". [372:19] In the description of TO, after "It shall be allocatable", add "and shall not be a coindexed object". SUBMITTED BY: John Reid HISTORY: 14-119 m203 F08/0106 submitted - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- 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-258 m205 Passed as amended by J3 letter ballot #31 14-233r1 ---------------------------------------------------------------------- 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-258 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-258 m205 Passed by J3 letter ballot #31 14-233r1 ----------------------------------------------------------------------