J3/14-146 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #30 - due 13-Jun-2014 Date: 2014 May 07 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 8 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #203. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F08/0099 VOLATILE in specification expressions --- --- F08/0100 IMPORT statement and prior explicit declaration --- --- F08/0101 NAMELIST and multiple occurrences of a variable --- --- F08/0102 MERGE and polymorphism --- --- F08/0103 Pointers to internal procedures with different host instances --- --- F08/0104 IEEE Inquiry Functions --- --- F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? --- --- F08/0106 MOVE_ALLOC for a remote array The text of these interpretations is attached. Each interpretation starts with a row of "-"s. 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 only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Friday, 13-Jun-2014, in order to be counted. Thanks /Stan ------------------------------------------------------------------------ NUMBER: F08/0099 TITLE: VOLATILE in specification expressions KEYWORD: VOLATILE, specification expression DEFECT TYPE: Interpretation. STATUS: Passed by J3 meeting 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: m202 13-298r1 F08/0099 submitted m202 13-298r2 Revised answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: m202 13-305 F08/0100 submitted m202 13-305r1 Revised answer & edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: m202 13-314 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: m202 13-321 F08/0102 submitted m202 13-321r1 Revised example - passed by J3 meeting ---------------------------------------------------------------------- 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 meeting 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: m202 13-357 F08/0103 submitted with four answers m202 13-357r1 Selected answer, added edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 (10), 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: m203 14-100 F08/0104 submitted m203 14-100r1 Answer proposed m203 14-100r2 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute can successfully take part in asynchronous operations. ASYNCHRONOUS is different from VOLATILE so there is no compelling reason to treat the two with respect to VALUE the same. Disallowing ASYNCHRONOUS with VALUE would introduce an incompatibility between F2003 and F2008. Users would be surprised to have currently working programs suddenly give errors. EDITS to 10-007r1: none SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ----------------------------------------------------------------------