J3/17-006 To: J3 From: Stan Whitlock Subject: Outstanding Fortran Interpretations for m212 Date: 2016 Dec 11 Outstanding Fortran Interpretations, December 11, 2016 Stan Whitlock for /interp > 05-015 == closed F95 interps > 016 = 10-006T1-5r1 == F03 Corrigenda 1-5 interps > 017 = N1823 == F03 combined corrigenda 1-5 > 019 = N2005 == F08 combined corrigenda 1-3 > 020 = 17-020 == F08 Corrigenda 1-4 interps > N2103 == F08 Corrigendum 4 > m209: 2 of 2 interps passed by J3 meeting > m210: no interp activity > m211: no interp activity = 0 passed WG5, 0 passed J3 LB, 2 passed J3 meeting, 15 in progress [keep this text document to 75 characters per line] ...................74 Table of Contents Part 0 contains the summary status of all of the Fortran interpretations Part 1 contains the interpretation processing rules from 00-142 Part 2 contains active F90/F95 interpretations: - only F90/0145 - the F95 interps numbered F95/1-32 and 66-104 are all closed Part 3 contains active F03 interpretations: F03/0001-0141 Part 4 contains active F08 interpretations: F08/0001... ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done * == 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 C4 In F2008 Corrigendum 4 N S T number title - - - ------ ----- * P E F90/0145 Expressions in of a FUNCTION statement ------ d C2 I F03/0017 Dummy procedure pointers and PRESENT d C2 C F03/0018 Multiple identical specific procedures in type-bound generic interfaces d C2 E F03/0019 Multiple identical specific procedures in generic interface blocks d C2 E F03/0021 What kind of token is a stop code? d C3 E F03/0030 IEEE divide by zero d C4 I F03/0042 IEEE funny values and Standard real generic intrinsic procedures d C2 C F03/0046 Unlimited polymorphic pointers in common blocks d C3 I F03/0047 Polymorphic arguments to intrinsic procedures d C1 E F03/0048 Control edit descriptors in UDDTIO * P I F03/0051 Repeat specifiers and UDDTIO d C3 E F03/0053 The BIND attribute for C_PTR and C_FUNPTR * P E F03/0059 Structure components in namelist input d C3 E F03/0064 Recursive declaration of procedure interfaces d C2 I F03/0065 Relational equivalence * P I F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine d C1 E F03/0085 Finalizing targets of pointer or allocatable d C1 I F03/0091 Array components cannot depend on length type parameters d C2 E F03/0096 Can a read statement change the unit value? d C3 E F03/0100 Error in field width for special cases of signed INFINITY output d C2 E F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type d C1 I F03/0105 SIZE= specifier and UDDTIO d C1 I F03/0110 Restoring dropped restriction on ENTRY d C2 I F03/0116 indistinguishable specifics for a generic interface with use association d C2 E F03/0118 Are lower bounds of assumed-shape arrays assumed? d C2 E F03/0120 When are parameterized sequence types the same type? * M C F03/0121 Precise FP semantics of the REAL intrinsic d C1 I F03/0123 Implicit typing in derived types d C1 E F03/0124 definition is poorly defined d C1 I F03/0128 Subobjects in namelist output d C3 E F03/0139 Functions returning procedure pointers ------ d C1 E F08/0001 Generic resolution with pointer dummy arguments d C1 E F08/0002 Are assumed- or deferred-shape objects allowed in namelist? d C1 E F08/0003 Is a disassociated pointer allowed as an actual DIM argument? d C2 E F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? d C1 E F08/0005* optional arguments and ASSOCIATED - subsumed by F08/0004 d C1 I F08/0006 generic resolution with banned argument combinations d C1 I F08/0007 Can zero have more than one bit sequence representation? d C2 I F08/0008 IEEE exceptions for intrinsic functions d C1 I F08/0009 Is ABS ever required to be the optional IEC 60559 abs? d C1 E F08/0010 deallocating objects that are associated with other objects d C1 E F08/0011 How many times are constructed values finalized? d C1 E F08/0012* Are constants finalized? - subsumed by F08/0011 d C1 E F08/0013 How does finalization interact with allocatable assignment? d C1 E F08/0014 Finalizing assignment to vector-subscripted object d C1 E F08/0015 IMPLICIT d C1 E F08/0016 Can a vector-subscripted argument become undefined? d C1 E F08/0017 Elemental subroutine restrictions d C1 E F08/0018 Impure elemental restrictions d C1 E F08/0019 Transformational Bessel functions d C1 E F08/0020 FINDLOC and logical arguments d C1 E F08/0021 STORAGE_SIZE and unlimited polymorphic d C1 E F08/0022 DO CONCURRENT and file i/o d C1 E F08/0023 DO CONCURRENT and POINTER d C1 E F08/0024 Dummy arguments of impure elemental procedures d C1 E F08/0025 DO CONCURRENT and ALLOCATABLE d C1 E F08/0026 DO CONCURRENT and output interleaving d C1 E F08/0027 ATOMIC_REF example d C1 E F08/0028 Does a procedure reference cause loop termination? * P E F08/0029 G0 edit descriptor and floating-point output d C1 E F08/0030 Unlimited format repeat effects d C2 E F08/0031 PURE INTENT(OUT) finalization d C2 E F08/0032 PURE FUNCTION result finalization d C1 E F08/0033 PURE polymorphic finalization d C1 E F08/0034 ELEMENTAL INTENT(OUT) finalization d C1 I F08/0035 Maximum value for SHIFT argument to SHIFTL and SHIFTR d C1 E F08/0036 NORM2 example in Annex C d C1 E F08/0037 PROCEDURE POINTER vs PROTECTED d C2 C F08/0038 Are pointless restrictions on DIM arguments intended? d C1 E F08/0039 Many-one vector subscript usage d C2 E F08/0040 MOVE_ALLOC for coarrays * P E F08/0041 Segment ordering rules d C2 E F08/0042 SOURCE= questions d C2 E F08/0043 Executing a type-bound procedure on a coindexed object d C1 I F08/0044 Resolving the type of a coarray or coindexed object * P E F08/0045 constraints on entities of type LOCK_TYPE d C1 E F08/0046 VALUE attribute restrictions d C1 I F08/0047 public generic with same name as private type d C2 E F08/0048 Sequence association for coarrays d C1 E F08/0049 ELEMENTAL functions with nonconstant type parameters d C1 E F08/0050 Ordering requirements on definition of specification functions d C1 E F08/0051 Pure procedure arguments with VALUE d C1 E F08/0052 Private type-bound procedures d C1 E F08/0053 Restrictions on generic declarations, generic resolution d C2 E F08/0054 Requirements for needing an explicit interface d C2 E F08/0055 G editing for reals d C2 E F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE= d C2 E F08/0057 Interoperability with empty types d C2 E F08/0058 ENTRY point RESULT variable d C2 E F08/0059 Auto-targeting requirements d C2 E F08/0060 Procedure pointer assignment with an EXTERNAL target d C2 E F08/0061 Description of the CONTIGUOUS attribute misworded? d C2 C F08/0062 Mixing default initialization with DATA initialization d C2 I F08/0063 G editing to a narrow output field d C2 E F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE d C2 E F08/0065 Should certain procedures in intrinsic modules be pure? d C2 E F08/0066 Are certain expressions with pointer initialization constant? d C2 E F08/0067 Passing arrays of extended type objects d C2 E F08/0068 Pointer association and extended type arrays d C2 E F08/0069 Which part of an effective argument becomes undefined? d C2 E F08/0070 Finalization of INTENT(OUT) arguments d C3 E F08/0071 Vector subscript target d C2 E F08/0072 Final subroutines with corank d C2 E F08/0073 Polymorphic auto-targeting d C2 E F08/0074 Implicit type in BLOCK construct d C3 E F08/0075 Pointer function reference as variable in assignment d C3 E F08/0076* Pointer function reference in READ Subsumed by F08/0075 == W d C2 E F08/0077 Function references as variables in DATA statements d C2 E F08/0078 Are the IEEE values +0 and -0 distinguished d C2 E F08/0079 NAMELIST and type specification d C2 E F08/0080 Array constructors with polymorphic values d C2 E F08/0081 Deallocation error handling d C2 E F08/0082 Generic identifier and dtv arguments d C3 E F08/0083 Type parameter default expressions allow circular dependence d C3 E F08/0084 Pointer arguments to PURE functions d C3 E F08/0085 Problems with PARAMETERs d C3 E F08/0086 Implied-shape and separate PARAMETER statement d C3 E F08/0087 Mixed-kind character assignment d C3 E F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? * P E F08/0089 Variable-denoting functions change existing semantics d C3 E F08/0090 What restrictions apply to initialization and PARAMETER? d C3 E F08/0091 Derived type with no components d C3 E F08/0092 Derived type parameter requirements d C3 E F08/0093 Process exit status and error termination d C3 E F08/0094 Procedure statement and double colon d C3 E F08/0095 Is PRESENT allowed in specification and constant expressions d C3 E F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? d C3 E F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? d C3 E F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? d C4 I F08/0099 VOLATILE in specification expressions d C4 E F08/0100 IMPORT statement and prior explicit declaration d C4 E F08/0101 NAMELIST and multiple occurrences of a variable d C4 E F08/0102 MERGE and polymorphism d C4 E F08/0103 Pointers to internal procedures with different host instances d C4 E F08/0104 IEEE Inquiry Functions d C4 I F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? d C4 E F08/0106 MOVE_ALLOC for a remote array * P E F08/0107 LOCK_TYPE, ultimate components, subcomponents, and coarrays d C4 I F08/0108 ultimate components and coarrays d C4 E F08/0109 LOCK_TYPE and unlimited polymorphic * P E F08/0110 Interdependence of specifier values in input/output statements * P E F08/0111 Undefinition d C4 E F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE d C4 E F08/0113 Specifiers in image control statements * P E F08/0114 Can LOCK_TYPE components have the POINTER attribute? d C4 E F08/0115 ASYNCHRONOUS and argument passing d C4 E F08/0116 Interoperable procedures d C4 E F08/0117 TARGET and coindexed arguments d C4 E F08/0118 Subobject of variable in variable definition context d C4 E F08/0119 Branching to END BLOCK and END CRITICAL d C4 E F08/0120 Is the name of a procedure pointer a local identifier? d C4 E F08/0121 Add to introduction defined operations in specification exprs d C4 E F08/0122 Types with coarray components d C4 E F08/0123 SPACING intrinsic d C4 E F08/0124 Coindexed object with polymorphic subcomponent * P E F08/0125 Definition of objects of type LOCK_TYPE with pointer subobjects d C4 E F08/0126 Can cobounds be referenced in the same type declaration? d C4 E F08/0127 May an initial line begin with a semicolon? * P E F08/0128 Is recursive USE within a submodule permitted? d C4 E F08/0129 Is CLASS(type) required to refer to a prior type definition? d C4 E F08/0130 Does coarray allocation sync even with stopped images? d C4 E F08/0131 Are the changes to C_LOC in the 2010 revision intentional? d C4 E F08/0132 Can a procedure pointer be declared with an interface block? d C4 E F08/0133 Is unallocated actual associated with nonallocatable dummy OK? d C4 E F08/0134 in an image control statement d C4 E F08/0135 Vector subscripted actual makes VALUE dummy undefinable? d C4 E F08/0136 Argument correspondence with VALUE and ASYNCHRONOUS d C4 E F08/0137 Result of TRANSFER when MOLD is an array with element size zero d C4 C F08/0138 Type extension in submodules d C4 E F08/0139 Is the name of an external procedure that has a binding label a local identifier? d C4 E F08/0140 Assign to deferred-length coindexed character variable d C4 E F08/0141 Can a statement function have a variable-length PDT result? d C4 E F08/0142 Is useless module extension permitted? d C4 E F08/0143 May a pure procedure have an INTENT(OUT) polymorphic component? d C4 E F08/0144 Is nonadvancing I/O allowed during execution of DO CONCURRENT? d C4 E F08/0145 Can initial-data-target be coindexed? * P E F08/0146 Does intrinsic assignment copy inherited components twice? d C4 E F08/0147 Is generic resolution of elemental assignment done at runtime? d C4 E F08/0148 Pointer subobject in structure constructor in pure procedure * M E F08/0149 ID= specifier and other specifiers ====================================================================== Part 1: Interpretation Processing Rules ====================================================================== 0. All interpretations are listed in J3 standing document 006. 1. Interpretations are processed by the J3/interp group and given a number. The interpretation is marked "J3 consideration in progress". An answer is formulated and presented to J3 in a meeting paper. 2. J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". 3. 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. 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. 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. Interps so forwarded are marked "Corrigendum". 6. J3/interp creates a edit for the next Fortran Standard if one is needed for all interps marked "Corrigendum". ---------------------------------------------------------------------- ====================================================================== Part 2: Active F90/F95 interpretations ====================================================================== ---------------------------------------------------------------------- NUMBER: F90/0145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host or use association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.1.2.1 states: "A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association." Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. A named constant can appear in a of a function statement if it is accessible within the function by host or use association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor cannot appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject cannot be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement for objects declared within the function. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator cannot appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host ... ! associated. END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use ! associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable. A structure constructor cannot appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS to 10-007r1: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 F90/0145 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved uc 95-034r1 m132 X3J3 ballot failed 15-5 95-281 m135 revised response, reworded edit 3, WG5 approved (N1161) 96- m136 X3J3 ballot failed 15-1, WG5 approval removed. ---------------------------------------------------------------------- ====================================================================== Part 3: Active Fortran 2003 Interpretation Requests ====================================================================== ---------------------------------------------------------------------- NUMBER: F03/0051 TITLE: Repeat specifiers and UDDTIO KEYWORDS: repeat specifier, POS=, UDDTIO DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i INTEGER :: j END TYPE INTEGER :: ipos INTERFACE READ(FORMATTED) MODULE PROCEDURE formattedReadT END INTERFACE CONTAINS SUBROUTINE formattedReadT (dtv, unit, iotype, vlist, iostat, iomsg) CLASS(T), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ(unit, *) dtv%i INQUIRE(unit, POS=ipos) READ(unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted') WRITE(10, '(A)') '2*3 5' REWIND(10) READ(10, *) a PRINT *, a%i, a%j, ipos END PROGRAM 10.9 of Fortran 2003 states that the r*c form of list-directed input is equivalent to r occurrences of c. So, when the read is performed, it is as if the input record contains two occurrences of the number 3. The first child read statement reads the first 3, and does not advance the file position to the next record (because it is a child data transfer statement). It appears that the second read statement should read the second 3. But the file position between the child read statements is unclear. What does the above program print? ANSWER: The standard does specify the behavior of a processor when a list directed input record contains a r*c constant, but that is irrelevant to the question at hand. Executing an INQUIRE statement using an internal unit is prohibited by [235:16] 9.10.2.1p2. The program does not conform. EDITS to 10-007r1: None. SUBMITTED BY: Rob James HISTORY: 05-142 m171 F03/0051 submitted 05-142r2 m171 Passed by J3 meeting 05-167/170 m172 Failed J3 letter ballot #11 06-369r1 m178 Passed by J3 meeting 07-250r1/272 m181 Failed J3 letter ballot #13 13-248 m200 Revised - withdrawn The question raised at m200 was about the definition of "internal unit (9.6.4.8.3)" [226:4], which seems to conflict with the Terms and Definitions [12:26-31]: 1.3.94 internal file character variable that is connected to an internal unit (9.4) 1.3.95 internal unit input/output unit that is connected to an internal file (9.5.4) The clarification we needed but couldn't find is probably [208:8-10]: An internal unit is used to refer to an internal file and is specified by an internal-file-variable or a file-unit-number whose value is equal to the unit argument of an active defined input/output procedure (9.6.4.8). /Stan ---------------------------------------------------------------------- NUMBER: F03/0059 TITLE: Structure components in namelist input KEYWORDS: Namelist, UDDTIO, component DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: MODULE m PRIVATE TYPE, PUBLIC :: t INTEGER :: i INTEGER :: j CONTAINS PROCEDURE, PRIVATE :: readFormatted => readFormattedT GENERIC :: READ(FORMATTED) => readFormatted END TYPE CONTAINS SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, & & iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, *) dtv%i dtv%j = dtv%i * 2 END SUBROUTINE END MODULE PROGRAM p USE m TYPE(t) :: x NAMELIST /nml/ x READ (*, nml) PRINT *, x%i, x%j END PROGRAM Question 1: Is the following input valid for the above program? &nml x%i = 100 / Question 2: If the input is valid, what is the output of the program, when using this input? ANSWER: 1. No, this input is not valid for the given program. The name of a component of a structure should not appear in namelist input if that structure would be processed by a user-defined derived-type I/O procedure. Edits are supplied to correct this oversight. 2. N/A EDITS to 10-007r1: [243:24-27] Replace "If the namelist group object name is the name of a variable of derived type, the name in the input record may be either the name of the variable or the designator of one of its components, indicated by qualifying the variable name with the appropriate component name." with "If the namelist group object is a variable of derived type, the name in the input record may be the name of the variable. If the variable would not be processed by a user-defined derived-type input/output procedure, the name in the input record may also be the designator of one of its components, using the syntax of object designators." SUBMITTED BY: Rob James HISTORY: 05-174 m172 F03/0059 submitted 05-221 m173 Passed by J3 meeting 06-133 m175 Failed J3 letter ballot #12 - typo fixed Rich Bleikamp's NO comment for F03/0059: The replacement text reads "if the variable would not be processed by a UDDTIO ...", but I think the presence of an object designator might actually determine whether or not the object designator is processed by a UDDTIO routine (sort of the reverse decision process than what is being suggested, where being processed by a UDDTIO routine precludes the use of a non-simple variable name in the input record). Second, the sentence immediately after the replaced text talks about "Successive qualifications" being applied to the name. I think this reads awkwardly with the suggested edit. Third, I think the answer may be wrong. For namelist input, we should allow (perhaps we already do) object designators all the time, and just not invoke the UDDTIO routine if the object designator is not a simple variable name, or if the resulting objects datatype/shape do not match an existing interface for a UDDTIO routine. Also, it's not clear to me (it's too late in the day), but perhaps we really want to allow an object designator that's an array element reference to invoke a UDDTIO routine. We could use the datatype and shape of the object designator to determine whether or not a UDDTIO routine should be invoked (still a compile time decision). I'm not at all sure we'd want to allow component references in such a case, or perhaps a component reference in the input record just precludes the possibility of invoking a UDDTIO routine for that input value. The tradeoffs here are: 1) allow some more functionality (which we may already allow), such as array element references appearing in a namelist input record (as a namelist group object name, possibly qualified), and still cause a UDDTIO routine to be invoked, and 2) keep the rules simple enough that the user and compiler's I/O library can easily agree on what's supposed to happen, and what input values are therefore allowed. I was going to suggest a replacement edit, but my head hurts too much :). ---------------------------------------------------------------------- NUMBER: F03/0084 TITLE: IEEE_SET_ROUNDING_MODE in a subroutine KEYWORDS: IEEE_ARITHMETIC DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Section 7.1.7 of the Fortran 2008 standard says that if the value of an expression can be determined before execution of the program, it is standard-conforming to use the predetermined value. Consider the subprogram SUBROUTINE S() USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES INTEGER, PARAMETER :: sp = IEEE_SELECTED_REAL_KIND(6,30) real(sp) :: X = 0.5559013_sp real(sp) :: Y = 1.2092481_sp real(sp) :: Z1, Z2 IF (IEEE_SUPPORT_ROUNDING(IEEE_NEAREST,X) .AND. & IEEE_SUPPORT_ROUNDING(IEEE_UP,X)) THEN CALL IEEE_SET_ROUNDING_MODE(IEEE_UP) Z1 = X*Y CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) Z2 = X*Y PRINT *, 'Residual: ', Z1 - Z2 ENDIF END (1) Is a processor permitted always to print zero for the residual Z1 - Z2 ? (2) Same question, after giving X and Y the PARAMETER attribute. ANSWER: (1) Yes. The processor is allowed to evaluate expressions (constant or otherwise) in any mathematically equivalent way. In particular, it is permitted to evaluate using higher precision than any precision available when the program is executed. For example, it might compute Z1 == Z2 == 0.67222259081253, then compute Z1 - Z2 == 0.0, regardless of how the program might do rounding at the seventh decimal digit when it is executed. (2) Yes, for the same reasons as question (1). EDITS to 10-007r1: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-372 m178 F03/0084 submitted 11-218 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 F03/0084 Bader NO vote: The answers given to both (1) and (2) in the interp appear to me to be counterintuitive; the programmer would expect that the calculation of Z1 and Z2 respectively obey the imposed rounding mode. In particular, I suspect there are situations where it is more obvious to the compiler than to the programmer that expressions are evaluated at compile time, and that different processors may have differing capabilities in identifying such expressions. The resolution of such situations is one target that the IEEE facilities were designed for. I therefore am in favor of the stance that, if supported, the setting of the rounding mode should take precedence over processor-dependent compile-time evaluations. Corbett NO vote: I disagree with the interpretation given. I believe that the assignments should require conversions to be done and that the conversions should be done in accord with the rounding mode currently in effect. Therefore, the results should not be zero. Long NO vote: I was confused by John's comment that the rounding mode on entry to the subroutine affected the value of Z1 since the computation of Z1 follows a call that resets the rounding mode. I think the real question here is what the standard means by "mathematical". I had always thought in terms of things like algebra. John's answer seems to imply that computational numerics (as specified by IEEE) are part of the concept of "mathematical". In other contexts, I think that John's interpretation could be harmful. On the other hand, the current answer does seem to make the usefulness of the IEEE_SET_ROUNDING_MODE routine more limited that would be expected. Also, does the concept of mathematically equivalent apply to the aggregation of multiple statements, or does it apply to just one expression? A processor that used the "mathematically equivalent" argument to get 0 would need to forward sub the expressions for Z1 and Z2 into the print statement to get X*Y - X*Y. I don't think we intended to allow forward substitution of expressions across one of the IEEE mode setting routines. Maclaren comment: This relates to F03/0065, but is the other way round. Unlike that one, I consider this consistent with the majority of the semantic wording in the C standard. Muxworthy No vote: I agree with John's vote. Reid NO vote: The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. Snyder NO vote: The answer makes rounding mode changes pointless. The work-around usually advanced to cause rounding mode changes to have effect (but not advanced in the answer to the interpretation) is to store intermediate results that are computed with different rounding modes in VOLATILE variables if they are ultimately to be combined in a single expression. Subclause 5.3.19 states, in part, however, that "The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program." Setting the rounding mode is done by means that ARE specified by the program, so the advice is not germane. One who reads subclauses 5.3.19, 14.4, 14.11.6, and 14.11.21, and the answer to this interpretation, might not realize that the use of VOLATILE variables is required, under the present interpretation, for subclauses 14.4, 14.11.6, and 14.11.21 to be meaningful. A better answer would have been to amend 7.1.5.2.4 to require that all entities within the expression are evaluated with the same rounding mode, or to specify that quantities evaluated with different rounding modes cannot be considered to be mathematically equivalent, even if evaluated by textually identical expressions. This might require processors either to abandon certain optimizations, or to perform more detailed dataflow analysis that propagates rounding mode to determine when those optimizations are permitted. If the position implied by the answer to this interpretation is to be maintained, the absence of edits is entirely inadequate. The definition of VOLATILE must be changed to encompass actions that ARE specified by the program, and to encompass advice concerning rounding mode changes. Advice to store intermediate results that are computed with different rounding modes into VOLATILE variables, if they are to be combined in a single expression, must be included in subclauses 14.4 and 14.11.21. During the requirements phase for the 2008 standard, there was a request (in 04-219) for a "strict mode" similar to that described in section G.2 of the Ada standard, in which rounding mode settings would actually have an effect without needing to resort to VOLATILE variables. If a "strict mode" had been provided, it might have made sense to allow a processor to ignore rounding mode changes outside strict regions. A request for a "strict mode" will be presented during the requirements-gathering phase for the next revision of the standard, for this as well as other reasons. ...................................................................... F03/0084: Replies from the editor John Reid writes: <<< The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. >>> No it does not. IEEE peculiarities play no part in the mathematical Reals. IEEE is merely one form of computer arithmetic. (It would make very bad mathematics, since IEEE numbers are not even a subset of the 2-point compactification of the Reals, thus nearly all mathematical identities and theorems about the Reals would get destroyed.) Computer arithmetic is *computational* not *mathematical*. ALL computer arithmetics frequently give different computational answers for mathematically-equivalent expressions. And I cannot believe you are again trotting out this nonsense saying constant expressions should not be treated as constant. If I have "REAL(KIND=INT(a+b)) :: x(INT(a+b)) = a+b; y=a+b", with a and b being floating-point named constants, I am not allowed to evaluate a+b at compile time? Surely you jest. Or I can in the KIND= but not in the array bound? Unless the array is in COMMON or has the SAVE attribute? Surely you jest even more. Or I can everywhere except in the "y ="? You cannot be serious. Furthermore, the rationale you are using is applicable to all routines regardless of whether they call IEEE_SET_ROUNDING and would thereby destroy many basic optimisations. You.Really.Can.Not.Be.Serious. ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Must the intrinsic function REAL with KIND argument wp return a value that is a REAL (KIND=wp) floating point number? RATIONALE FOR THE QUESTION: Computer hardware may use a wider floating-point format for registers than for memory; e.g., 80 bits for registers and 64 bits for memory for the case of standard double precision floating point numbers. Some algorithms require a high level of control over floating point semantics. If the intrinsic function REAL with KIND parameter wp is guaranteed to return a REAL (KIND=wp) result then a programmer can use this to force intermediate results into main memory format, never mind that the optimizing compiler may have placed the intermediate in a register. I am interested in a J3 interpretation of this matter, especially a loud and clear affirmative interpretation, because it appears that some present Fortran compilers optimize away my explicit use of the REAL intrinsic with a KIND=wp argument. The context is code for compensated summation (Kahan summation). I appreciate that parentheses are inviolable courtesy of the Fortran standard, but in order to have code that cannot be broken by an optimizing compiler I seem to need also a language mechanism to force intermediate results into main memory format. The VOLATILE attribute is a large hammer, and the standard does not actually say that assigning a value to a variable with that attribute forces the result to main memory format. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANALYSIS: The fourth sentence of the second paragraph of subclause 13.7.1, as amended by Corrigendum 2, states: "A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters." However common optimizations have allowed the REAL intrinsic to be ignored in an expression when the result is mathematically equivalent to including the evaluation of the REAL intrinsic. Requiring the evaluation of the REAL intrinsic in all circumstances would be adding a new feature, incompatible with existing F2008 interpretations, and would be limiting optimizations on which Fortran customers rely. ANSWER: 10-007r1 [141:20-21] 7.1.5.2.4p2, says: "Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." The interpretation of this paragraph has always meant that the REAL intrinsic may return a mathematically equivalent result. The interp process must not be used to add a new feature, incompatible with existing practice. EDITS to 10-007r1: None. SUBMITTED BY: Bas Braams, Emory University, Atlanta, GA HISTORY: 08-208r1 m185 F03/0121 submitted 10-240 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1878 m186 Failed WG5 ballot 1 N1876 11-260 m196 Revised answer 11-260r1 m196 Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 16-118 m209 F03/0121 resubmitted as a new feature 16-118r1 m209 New feature not allowed; clarification; Passed by J3 meeting ---------------------------------------------------------------------- ====================================================================== Part 4: Active Fortran 2008 Interpretation Requests ====================================================================== ---------------------------------------------------------------------- NUMBER: F08/0029 TITLE: G0 edit descriptor and floating-point output KEYWORDS: G edit descriptor, 0 width DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: For data types other than floating-point, the effect of the G0 edit descriptor is precisely defined. For floating-point output, the effect is precisely defined only if the value is an IEEE NaN or Infinity, the result is otherwise left up to the processor to select "reasonable" values for w, e, and d (if d is unspecified). The standard states [258:7-9 10.7.5.2.2p2]: "the G0 and G0.d edit descriptors follow the rules for the Gw.dEe edit descriptor, except that any leading or trailing blanks are removed". One might deduce from the wording of this that there is no upper limit on the choice of w, since the production of additional leading (or trailing) blanks has no effect on the output. Q1. Is a value for w or e that results in the field being filled with asterisks reasonable? This is not, after all, an error condition. Q2. Is a value for d that results in significant loss of precision reasonable? E.g. d==1, or for a less extreme example, d==PRECISION(value)/2. Q3. Is a value for d that produces many more digits than the precision reasonable? E.g. d==1000000. Or, for a less extreme example, d==PRECISION(quad) with a single precision value. Q4. Is a value for e that produces many more digits in the exponent than the exponent range reasonable? E.g. e==1000000. Q5. If the standard cannot tell me what "reasonable" means, what purpose does it serve for it to say that it must be reasonable? I cannot see how to tell whether a processor conforms to the standard in this respect. DISCUSSION: The standard permits, but does not require, the "best" values of w, d or e to be chosen for each internal value. ANSWER: A1. No, that is not reasonable. An edit is supplied to clarify the meaning of "reasonable". A2. No, a value of d that results in a significant loss of precision is not reasonable. An edit is supplied to correct this. A3. No, it is not reasonable for d to be ridiculously large. An edit is supplied to clarify the intent. A4. No, e should not be bigger than that required to represent the largest finite machine-representable number. An edit is supplied to specify this. A5. Yes, the use of the word "reasonable" in this context is entirely meaningless. An edit is supplied to remove this misleading terminology. EDITS to 10-007r1: In 10.7.5.2.2, paragraph 2: [258:9] In 10.7.5.2.2p2 last sentence: "Reasonable processor-dependent" -> "Processor-dependent". {A5.} [258:10] In 7.5.2.2p2 last sentence, after "value" insert ", that do not result in the field being filled with asterisks". {A1.} [258:10] Append new sentences to 10.7.5.2.2p2: "The value of shall not result in the production of an output value that differs from the internal value by more than 100*SPACING(value), and shall not be more than two larger than the maximum number of digits that might be required to distinguish between two different machine numbers of the kind of the internal value. The value of shall not be so large that the exponent would have a leading zero both when the internal value is the largest finite machine number and when it is the smallest finite machine number of that kind." {The first sentence limits the choice of to lose no more than 2 digits of precision (A2) and to have no more than 2 spurious digits of precision (A3); for some floating-point formats, the upper bound is not strong, being d <= 2+MAX(PRECISION(value)+2,RANGE(value)*2). The second sentence would allow e==4 for a lop-sided exponent range, e.g. -1100 to +900, but would limit e to at most 3 if the exponent range is e.g. -308 to +308 (A4). Neither of these restrictions prevent a processor from producing fewer mantissa or exponent digits for particular values if that does not result in serious loss of accuracy.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-179 m192 F08/0029 submitted 10-179r1 m192 Draft answer with straw vote on alternative 10-179r2 m192 Revised draft - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m196 Failed WG5 ballot 2 N1877 F08/0029 Corbett NO vote: I agree that the word "reasonable" should not appear in the Fortran standard. The first two proposed edits should be incorporated. The third edit should not be adopted. I object to the third edit on general grounds. The issues dealt within the third edit should be matters of "quality of implementation." I see no reason for the Fortran standard to restrict implementors' choices in this area. I also object to the third edit on specific grounds. The proposed edit makes no provision for nonzero scale factors. If a nonzero scale factor is in effect, an implementation might reasonably choose a value of d that is outside the range specified by the edit, if only to avoid the scale factor being outside the allowed range of values. The phrase and shall not be no more than two larger than the maximum number of digits that might be required to distinguish between two different machine numbers of the kind of the internal value. should say either "any" between "between" and "two", or should say "all pairs of" instead of "two." ------------------------------------------------------------------------ NUMBER: F08/0041 TITLE: Segment ordering rules KEYWORDS: segment, allocation DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) Was it intended to allow the allocation of a variable that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t1 REAL,ALLOCATABLE :: c(:) END TYPE TYPE t2 TYPE(t1),POINTER :: p END TYPE TYPE(t1),TARGET :: x TYPE(t2) :: y[*] y%p => x ! y[n]%p => x[n] for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN ALLOCATE(x%c(1000)) ! Allocates x[1]%c. ELSE y[1]%p%c(THIS_IMAGE()) = 999 ! Defines some part of x[1]%c. END IF END PROGRAM (2) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in unordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,SUM(x) ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). ANSWER: (1) No, this example violates the requirement of the first bullet in paragraph 3 of 8.5.2, which says: "if a variable is defined on an image in a segment, it shall not be referenced, defined, or become undefined in a segment on another image unless the segments are ordered". x[1]%c is defined in segment 2 by images 2-N, but is made undefined on image 1 (allocation makes a variable undefined except when default initialization occurs). (2) No, this example was not intended to be standard-conforming. An edit is supplied to clarify the intent. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). {Forbid uncoordinated undefinings of variables.} SUBMITTED BY: John Reid HISTORY: 10-201 m193 F08/0041 submitted 10-201r1 m193 Revised - Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 ** start negative comments John Reid's NO vote on F08/0041: There are errors in both examples. In example (1), the component of type t2 should have type t1. In example (2), the PRINT statement should reference x on another image, e.g. PRINT *, x(1)[2]. More seriously, the edit proposed in 10-201 has been removed. While it is not necessary for allocation, it is needed for pointer association. This means that it is desirable to rewrite the questions and answers. Here is my suggestion QUESTION: (1) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in unordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,x(1)[2] ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). (2) Was it intended to allow a pointer assignment to a pointer that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t REAL,POINTER :: p END TYPE REAL,TARGET :: a=0.0, b=1.0 TYPE(t) :: y[*] y%p => a ! y[n]%p => a for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN y%p => b ! y[1]%p => b ELSE y[1]%p = 999 ! Defines a[1] or b[1]? END IF END PROGRAM ANSWER: (1) No. This case has been overlooked in the segment ordering rules. An edit is supplied to correct this. (2) No. This case, too, has been overlooked in the segment ordering rules. An edit is supplied to correct this. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and". Van Snyder's No vote on F08/0041: "is defined" is a static concept. The requirement should always have been "becomes defined". Therefore the edit should be to replace "variable is defined" to "variable becomes defined or undefined" -- or do we need another interp to repair this? Jim Xia's No vote on F08/0041: The first example should be fixed to have t2 contains a pointer component of type t1. The second example is perfectly legal. Seems we need to rework on this interp. result of ballot on F08/0041: In example (1), the component of type t2 is changed to type t1. However, more work is needed on this interp as a result of these comments => F08/0041 fails. The edit in 10-201 referred to above is: [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and" ** end negative comments ---------------------------------------------------------------------- NUMBER: F08/0045 TITLE: constraints on entities of type LOCK_TYPE KEYWORDS: lock, polymorphism DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: Program example Use Iso_Fortran_Env, Only:lock_type type :: m class(*), allocatable :: lock end type type(m) :: om[*] allocate(lock_type :: om%lock) call inner(om) ! Problem call. Contains Subroutine inner(omm) Type(m),Intent(Out) :: omm Print *,Allocated(omm%lock) End Subroutine End Program Constraint C1304 attempts to prohibit a variable with a LOCK_TYPE subobject from appearing in a variable definition context, such as the call to inner, but the dynamic type of om%lock cannot be determined statically. Is this program standard-conforming? ANSWER: The example was not intended to be standard-conforming. An ALLOCATE statement with a should not have been permitted to add components of type LOCK_TYPE; an edit is supplied to correct this error. EDITS to 10-007: [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", LOCK_TYPE (13.8.2.16), or a type with a direct component of type LOCK_TYPE that is not a direct component of the declared type of any ,". {Fix condition to prohibit LOCK_TYPE and any type with a LOCK_TYPE direct component. Note that we only want to prohibit "new" lock_type components from appearing in the , we don't want to forbid ones that are already in the declared type.} [127:8] After "LOCK_TYPE" delete "(13.8.2.16)". {Reference now appears one line earlier, so is unnecessary.} SUBMITTED BY: R. Bader HISTORY: 10-210 m193 F08/0045 submitted 10-210r1 m193 Revised - Passed by J3 meeting 11-129 m194 Failed by J3 letter ballot #22 10-254 ** start negative comments Jim Xia's No vote on F08/0045: The edits makes it illegal to specify LOCK_TYPE as if the coarray itself is of LOCK_TYPE. For example, type(lock_type), allocatable :: locks[*] The edits make the following allocate statement illegal ALLOCATE (LOCK_TYPE: locks[*]) result of ballot on F08/0045: /interp will take this back for more work since we think that Jim has a valid complaint => F08/0045 fails Perhaps the edit should be changed to [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", or a type with a direct component of type LOCK_TYPE (13.8.2.16) that is not a direct component of the declared type of any ,". [127:7+] Insert new constraint "C641a (R626) If an is unlimited polymorphic, shall not specify the type LOCK_TYPE (13.8.2.16)." ** end negative comments ---------------------------------------------------------------------- NUMBER: F08/0089 TITLE: Variable-denoting function references change existing semantics KEYWORDS: Pointer function, argument, ASSOCIATE, SELECT TYPE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Questions 1-3 use this module: Module m200c2 Integer,Target :: x = 42 Contains Function fx() Integer,Pointer :: fx fx => x End Function End Module Q1. Consider this main program Program q1 Use m200c2 Call test(x,fx()) ! The call. Contains Subroutine test(a,b) Integer :: a,b a = a*10 ! The assignment. Print *,a,b End Subroutine End Program According to Fortran 2003, "fx()" in the CALL statement is an expression and not a variable, and has the value 42. It follows that the assignment "a = a*10" is standard-conforming and does not affect the value of B. Therefore this program prints 420 42 However, according to Fortran 2008, "fx()" in the CALL statement is a variable, and therefore the assignment does not conform to the standard because it affects the value of B and so violates 12.5.2.13 item (3) which requires all updates to B to go through the dummy argument, and therefore the behaviour of the program is unspecified. This conflicts with the statement in clause 1 that all Fortran 2003 programs remain conforming in Fortran 2008. Is this program intended to remain standard-conforming? Q2. Consider this main program Program q2 Use m200c2 Call test(x,fx()) ! The call. Contains Subroutine test(a,b) Integer,Target :: a,b a = a*10 ! The assignment. Print *,a,b End Subroutine End Program According to Fortran 2003, "fx()" in the CALL statement is an expression and not a variable, and has the value 42. It follows that the assignment "a = a*10" is standard-conforming and does not affect the value of B. Therefore this program prints 420 42 However, according to Fortran 2008, "fx()" in the CALL statement is a variable, and therefore the assignment to A affects the value of B, so the program will print 420 420 This apparently conflicts with the statement in clause 1 that Fortran 2008 is an upwards compatible extension to Fortran 2003. Is this program intended to have altered semantics? Q3. Consider this main program Program q3 Use m200c2 Associate(y=>fx()) ! The association. x = 0 ! The assignment. Print *,x,y End Associate End Program This main program apparently conforms to both Fortran 2003 and Fortran 2008, but according to Fortran 2003 "fx()" in the association is an expression, evaluated on entry to the construct, and therefore Y becomes associated with the value 42, and therefore the program prints the values (spacing may differ) 0 42 whereas according to Fortran 2008 "fx()" in the association is a variable, and every reference to Y is a reference to the associated variable, so the assignment also changes the value of Y and therefore the program prints the values 0 0 This apparently conflicts with the statement in clause 1 that Fortran 2008 is an upwards compatible extension to Fortran 2003. Is this program intended to have altered semantics? Q4. Consider this program Module m200c2_q4 Integer,Target :: x = 42 Contains Function fx() Class(*),Pointer :: fx fx => x End Function End Module Program q4 Use m200c2_q4 Select Type (q=>fx()) Type Is (Integer) x = 0 Print *,x,q End Select End Program Using the same logic as Q2, this should print the values 0 42 in Fortran 2003, but the values 0 0 in Fortran 2008. Again, this is not upwards compatible with Fortran 2003. Is this program intended to have altered semantics. ANSWER: A1. This program is not intended to be conforming to Fortran 2008. An edit is supplied to note the incompatibility between Fortran 2008 and previous Fortran standards. A2. This program was intended to have different semantics in Fortran 2008. An edit is supplied to note the incompatibility. A3. This program was intended to have different semantics in Fortran 2008. An edit is supplied to note the incompatibility. A4. This program was intended to have different semantics in Fortran 2008. An edit is supplied to note the incompatibility. EDITS to 10-007r1: [24:11+] 1.6.2 "Fortran 2003 compatibility", insert new paragraphs at the end of the subclause, after the paragraphs added by Corrigendum 2: "An actual argument that corresponds to a nonpointer dummy argument and which is a to a pointer function is regarded as a variable by this part of ISO/IEC 1539 but was regarded as an expression by Fortran 2003; if the target of the pointer result is modified other than through that dummy argument during execution of the called procedure, and that dummy argument does not have the POINTER or TARGET attribute, the program does not conform to this part of ISO/IEC 1539. If that dummy argument does have the POINTER or TARGET attribute, any further reference to that dummy argument will have the modified value according to this part of ISO/IEC 1539 instead of the initial value as specified by ISO/IEC 1539-1:2004. A for an ASSOCIATE or SELECT TYPE construct that is a to a pointer function is regarded as a variable by this part of ISO/IEC 1539; if the target of the pointer result is modified during execution of the construct, any further references to the will have the modified value according to this part of ISO/IEC 1539 instead of the initial value as specified by ISO/IEC 1539-1:2004." [24:14-16] 1.6.3 "Fortran 95 compatibility", paragraph 1, sentence 2, Change "Any" to "Except as identified in this subclause, any", Delete "The following Fortran 95 features .. 1539." {We are about to add a non-conformance, so the last sentence will become wrong and it is in any case unnecessary.} [24:17-27] Change all bullet points into separate paragraphs. {These are no longer a list.} [24:27+] Insert new paragraph at end of subclause "An actual argument that corresponds to a nonpointer dummy argument and which is a to a pointer function is regarded as a variable by this part of ISO/IEC 1539 but was regarded as an expression by Fortran 95; if the target of the pointer result is modified other than through that dummy argument during execution of the called procedure, the program does not conform to this part of ISO/IEC 1539." [24:30] 1.6.4 "Fortran 90 compatibility", paragraph 1 Change "Any" to "Except as identified in this subclause, any", [25:6+] Insert new paragraph at end of subclause. "An actual argument that corresponds to a nonpointer dummy argument and which is a to a pointer function is regarded as a variable by this part of ISO/IEC 1539 but was regarded as an expression by Fortran 95; if the target of the pointer result is modified other than through that dummy argument during execution of the called procedure, the program does not conform to this part of ISO/IEC 1539." SUBMITTED BY: Malcolm Cohen HISTORY: 13-228 m200 F08/0089 submitted 13-228r1 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Failed WG5 ballot N1988/n1987 ----------------------- From N1990: F08/0089 Corbett reason for NO vote Questions Q1 and Q2 assume that if a pointer actual argument has the form of an expression and the corresponding dummy argument is a nonpointer dummy argument without the VALUE attribute, the dummy argument becomes argument associated with the value of the target of the value of the pointer actual argument. On the newsgroup comp.lang.fortran, Ian Harvey pointed out that the Fortran standards do not support that premise. Paragraph 2 of Clause 12.5.2.3 of the Fortran 2008 standard states If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that is pointer associated with a target, the dummy argument becomes argument associated with that target. Paragraph 8 of Clause 12.4.1.2 of the Fortran 2003 standard states Except in references to intrinsic inquiry functions, if the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be associated with a target and the dummy argument becomes argument associated with that target. Paragraph 6 of Clause 12.4.1.1 of the Fortran 95 standard states If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target The paragraph added between paragraphs 3 and 4 of Clause 12.4.1.1 of the Fortran 90 standard by Corrigendum 2 states If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. That text was added as a result of interpretation F90/000039. In the examples given in questions Q1 and Q2, the actual argument fx() is a pointer actual argument corresponding to a nonpointer dummy argument. Therefore, the dummy argument becomes argument associated with the target of the pointer actual argument, which is the module variable x. The dummy argument does not become argument associated with the value of the target of the pointer. Thus, there is no semantic difference between Fortran 2008 and the previous standards in this regard. The answers and edits given for questions Q1 and Q2 are based on the same premise as the questions themselves and should be rejected. I asked people to compile and run the example programs given in questions Q1 and Q2 and variations of them using a variety of compilers. In most, but not all, cases, the results were consistent with the semantics stated in the Fortran standards, not with the semantics assumed by questions Q1 and Q2. Questions Q3 and Q4 are consistent with the standards, as are the corresponding answers and edits, but I do not care for the nature of the changes that will result if interpretation F08/0075 is passed. I think changing the language so that the form of a function reference determines its meaning is a mistake. Long comment: Twice in the edits appears "...a to a pointer function is regarded as a variable...". Should this be a "data pointer function"? Snyder comment: The term "pointer function" is not used as a noun, although "nonpointer function" is so used at [454:36]. I have a slight preference that "pointer function" in the edit for [24:11+] be replaced by "function that returns a pointer result" in both paragraphs. The same change ought to be made in the edits for [24:27+] and [25:6+] A parallel change ought to be made at [454:36], but that can be done editorially rather than within this interpretation. Decision of /INTERP: Failed. ---------------------------------------------------------------------- NUMBER: F08/0107 TITLE: LOCK_TYPE, ultimate components, subcomponents, and coarrays KEYWORD: LOCK_TYPE, ultimate components, subcomponents, coarrays DEFECT TYPE: Erratum STATUS: J3 consideration in progress DISCUSSION: Constraint C433 in subclause 4.5.2.1 reads: C433 (R425) If EXTENDS appears and the type being defined has an ultimate component of type LOCK_TYPE from the intrinsic module ISO FORTRAN ENV, its parent type shall have an ultimate component of type LOCK TYPE. This was intended to prevent compromising protection of objects of type LOCK_TYPE by using type extension and polymorphism. According to subclause 1.3.33.4, an ultimate component is a component that is of intrinsic type, a pointer, or allocatable; or an ultimate component of a nonpointer nonallocatable component of derived type The type LOCK_TYPE is not intrinsic. Therefore, if a type has a nonallocatable component of type LOCK_TYPE, it does not have an ultimate component of type LOCK_TYPE. Therefore, constraint C433 fails to protect entities of type LOCK_TYPE. Constraint C433 prohibits reasonable constructions, such as extending the type LOCK_TYPE, or extending a type that has an allocatable component that has a component of type LOCK_TYPE, because the parent type does not have an ultimate component of type LOCK_TYPE. Constraint C1302 in subclause 13.8.2.16 reads: C1302 A named variable of type LOCK TYPE shall be a coarray. A named variable with a noncoarray subcomponent of type LOCK TYPE shall be a coarray. This was intended to require that components of type LOCK_TYPE, at any level of component selection, be coarrays. According to subclause 1.3.33.3, a subcomponent is a direct component that is a subobject of a structure According to subclause 1.3.33.1, a direct component is one of the components, or one of the direct components of a nonpointer nonallocatable component. The definition of the term "subcomponent" does not include components of allocatable components. Therefore, because of the use of the term "subcomponent," if an object has an allocatable component that in turn has a component of type LOCK_TYPE, C1302 can fail to require a component of type LOCK_TYPE to be a coarray. QUESTIONS: Assume type LOCK_TYPE from ISO_Fortran_Env is accessible. 1. Is the definition of type One below standard conforming? type, extends(LOCK_TYPE) :: One type(lock_type), allocatable :: LOCK end type One 2. Is the definition of type Four below standard conforming? type :: Two type(lock_type), allocatable :: LOCK[:] end type Two type :: Three type(two), allocatable :: L end type Three Type, extends(Three) :: Four type(lock_type), allocatable :: LOCK[:] end type Four 3. Is the definition of type Six below standard conforming? type :: Five end type Five type, extends(Five) :: Six type(two), allocatable :: L end type Six 4. Is the declaration of the variable X below standard conforming? type :: Seven type(lock_type) :: L end type Seven type :: Eight type(seven), allocatable :: C end type Eight type(eight) :: X ANSWERS: 1. This was intended to be permitted. An edit is provided to repair the constraint on adding a LOCK_TYPE component during type extension. 2. This was intended to be permitted. An edit is provided to repair the constraint on adding a LOCK_TYPE component during type extension. 3. This was not intended to be permitted. An edit is provided to repair the constraint on adding a LOCK_TYPE component during type extension. 4. This was not intended to be permitted. An edit is provided to repair the constraint on declaring objects which have a potential subobject of type LOCK_TYPE. EDITS to 10-007r1: [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)". [61:27-29] 4.5.2.1 Syntax, C433, "ultimate" -> "potential subobject", twice. After "parent type" insert "shall be LOCK_TYPE or". [127:8-9] 6.7.1.1 Syntax, C642, split into two constraints as follows: "C642 If an is a coarray, the declared type of shall not be C_PTR or C_FUNPTR. C642a If an is a coarray, the declared type of in a SOURCE= specifier shall not be LOCK_TYPE (13.8.2.16), nor shall it have a potential subobject component of type LOCK_TYPE." {Fix subobject component, there is no problem with MOLD=.} [127:18-19] 6.7.1.1, p4, "If" -> "If an ALLOCATE statement has a SOURCE= clause and an", {There is no problem with MOLD=. "subcomponent" works ok here because we have an object not a type.} [399:17-18] 13.8.2.16 LOCK_TYPE, C1302, Change "with a noncoarray subcomponent" to "of a type that has a noncoarray potential subobject component". {Constraints need to be about the type,} ALTERNATIVE replace entire constraint with "C1302 A named variable shall be a coarray if its declared type is LOCK_TYPE or has a potential subobject component whose declared type is LOCK_TYPE." {This makes it clear that we are talking about the declared type.} SUBMITTED BY: Van Snyder HISTORY: 14-154 m204 F08/0107 submitted 14-154r3 m204 Revised ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTIONS: 1. Are the following INQUIRE statements permitted? LOGICAL :: Exist, Opened INQUIRE ( FILE='fred', EXIST=exist ) INQUIRE ( UNIT=42, OPENED=opened ) 2. Is the following INQUIRE statement permitted? INTEGER :: U INTERFACE FUNCTION P ( A ) INTEGER, INTENT(IN) :: A INTEGER, POINTER :: P END FUNCTION P END INTERFACE INQUIRE ( FILE='fred', NUMBER=u, POS=p(u) ) 3. Is the following READ statement permitted? INTEGER :: STATS(42) NAMELIST /IN/ V READ ( *, IN, IOSTAT=STATS(V) ) ANSWERS: 1. According to 9.12p5 [243:3-5] "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statements are prohibited because the values of the variables EXIST and OPENED depend upon the values of the FILE= and UNIT= specifiers, respectively. They were intended to be permitted. Edits are provided to correct this mistake. 2. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statement is not prohibited because U is not a subscript or substring bound. According to 7.1.4p2 [139:3-4] "The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." the INQUIRE statement is not prohibited because, although U is assigned a value, it is not evaluated. The INQUIRE statement was intended to be prohibited. Edits are provided to correct this mistake. 3. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." and 9.12p7 [243:9-11] "In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if any, shall not be associated with any entity in the ... ...." and 9.12p8 [243:12-14] "In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an array element reference, its subscript values shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the ." the READ statement is not prohibited because V does not "depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." Although V is input from namelist, it is not "the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier." The READ statement was intended to be prohibited. Edits are provided to correct this mistake. EDITS to 10-007r1: [243:3-5 9.12p5] Within the second sentence, provided by Corrigendum 2, replace "values of any or" with "value of any". Append ", or be affected by data transfer caused by that statement". That sentence becomes "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT=, or SIZE= specifier shall not depend on the value of any in the same statement, or be affected by data transfer caused by that statement." {Using "data transfer" instead of "" covers the namelist case.} [243:6-7 9.12p6] Replace "value of any subscript or substring bound of a variable" with "denotation of a data object". Replace "depend ... , or on" with "be affected by the data transfer, the processing, or". The paragraph becomes "The denotation of a data object that appears in a specifier in an input/output statement shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the or in that statement." After the paragraph, insert a note: NOTE 9.nn The semantics of how a variable is denoted is its "denotation"; this includes such things as component selection, array element selection, and pointer function evaluation. {Using "data transfer" instead of "" covers the namelist case.} [243:9 9.12p7] "Insert "ID=," before "IOSTAT". {Not mentioned in a question, but was a problem.} [243:12-14 9.12p8] Repairing the paragraph would make it equivalent (if not identical) to 9.12p6, as revised above. Therefore, delete the paragraph. SUBMITTED BY: Van Snyder HISTORY: 14-193 m204 F08/0110 submitted 14-193r1 m204 Revised 14-272r1 m205 Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2094 m209 Modified by 1st Corrigendum 4 ballot N2088/89/90 N2102 m209 Failed WG5 ballot on 2nd Corrigendum 4 N2095/96 <> Malcolm: I'm sorry, but this draft corrigendum makes 9.12p5 say "The value of an \si{internal-file-variable} ... shall not ... be affected by data transfer caused by that statement." And yet, this is the ENTIRE PURPOSE of a WRITE to an internal file, to affect the value of the internal-file-variable by means of data transfer! It is clear that we cannot cover everything in a single sentence, since the requirements on input and output statements should be quite different. More words are needed. (20) The edits for F08/0110 need to be pulled (see previous message), but anyway, the edit instructions refer to the "fifth paragraph, provided by Technical Corrigendum 2", but in fact the fifth paragraph was NOT "provided" by corrigendum 2, but merely edited by it. So those instructions should be "fifth paragraph, as edited by Technical Corrigendum 2" (or "after applying the changes in ...", which phrasing you used elsewhere). Result: All 9.12 edits are from F08/0110 which is being pulled from Corr 4: Remove the edits for F08/0110: [243:3-5, 6-7, 9, 12-14]. F08/0110 failed 2nd F2008 Corrigendum 2 ballot N2096. ---------------------------------------------------------------------- NUMBER: F08/0111 TITLE: Undefinition KEYWORD: undefinition DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTIONS: 1. Does the following cause D to become undefined? Ought it? integer :: I(2) double precision :: D equivalence ( D, I ) d = 42.0 i(1) = 666 2. Does the following cause C to become undefined? Ought it? integer, parameter :: RK = kind(0.0d0) real(rk), pointer :: P complex(rk), target :: C = ( 1.0, 2.0 ) c = ( 1.0d0, 2.0d0 ) p => c%re p = 24.0d0 3. Does the following cause D1 to become undefined? Does it cause C%IM to become undefined? Ought it? integer, parameter :: RK = kind(0.0d0) real(rk), pointer :: D1, D2 complex(rk), target :: C c = ( 1.0d0, 2.0d0 ) d1 => c%re d2 => c%im call s ( d2 ) ... contains subroutine S ( D ) real(rk), intent(out) :: D .... 4. Does the following cause Y to become undefined? Ought it? type :: T1 sequence integer :: C1 = 42 end type T1 type :: T2 sequence real :: C1 = 42.0e0 end type T2 type(t1) :: X type(t2) :: Y equivalence ( X, Y ) x = t1(21) ANSWERS: 1. Item (1) in subclause 16.6.6 says "When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined.... When a scalar variable becomes undefined, all partially associated double precision scalar variables become undefined." D is not totally associated with I. I does not become undefined. Therefore, D does not become undefined. D ought to become undefined. Edits are provided to correct this mistake. 2. Item (1) in subclause 16.6.6 says "When a double precision scalar variable becomes defined, all partially associated scalar variables become undefined." P is partly associated with C, and therefore C becomes undefined by the assignment to the scalar variable P. C ought not to become undefined. Edits are provided to correct this mistake. 3. Item (1) in subclause 16.6.6 says "When a scalar variable becomes undefined, all partially associated double precision scalar variables become undefined." Subclause 16.6.1p5 says "A complex... scalar object is defined if and only if all of its subobjects are defined." The association of the scalar variable D2 with an INTENT(OUT) dummy argument causes it become undefined. 16.6.6p1(1) does not specify that when a scalar real variable becomes undefined, a totally associated part of a complex variable becomes undefined. Assuming C%IM ought to become undefined, then C ought to become undefined, even though C%RE is not undefined. D1 is associated with the C%RE, and therefore becomes undefined when C%IM becomes undefined. C%IM ought to become undefined, and D1 ought not to become undefined. Edits are provided to correct this mistake. 4. Item (1) in subclause 16.6.6 says "When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined. X and Y are totally associated, and of different type, but neither one is of intrinsic type. Therefore, Y does not become undefined as a consequence of X becoming defined. Y ought to become undefined. Edits are provided to correct this mistake. EDITS to 10-007r1: In Subclause 16.6.6p1, item(1), within the first sentence, remove "of intrinsic type". Before "different" insert "the same type with different values of kind type parameters, or of" In Subclause 16.6.6p1, replace item(1) with the following four sentences (all in one paragraph) "When a scalar variable becomes defined, all totally associated variables of different type become undefined. {Removing "of intrinsic type" from the existing first sentence of 16.6.6p1(1) addresses question 4.} When a scalar variable becomes defined, all partially associated variables of different type, or of the same type if corresponding kind type parameters have different values, become undefined, unless the scalar variable is totally associated with a subobject of the partially associated variable, that subobject is of the same type as the scalar variable, and corresponding kind type parameters have the same values. {This addresses questions 1 and 2. The references to kind type parameter values address the possibility of partially associating a double precision variable with a default real variable. Default real and double precision are now the same type (since 1990), but with a different kind type parameter value.} When a scalar variable becomes undefined, all partially associated variables become undefined, unless the partially associated variable is totally associated with a subobject of the scalar variable that does not become undefined. When a scalar variable becomes undefined, all totally associated subobjects of other variables become undefined if those subobjects are of different type from the scalar variable, or corresponding kind type parameters have different values." {The third and fourth sentences address question 3.} SUBMITTED BY: Van Snyder HISTORY: 14-195 m204 F08/0111 submitted ---------------------------------------------------------------------- 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 to 10-007r1: [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-258 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 ---------------------------------------------------------------------- NUMBER: F08/0125 TITLE: Definition of objects of type LOCK_TYPE with pointer subobjects KEYWORD: pointer subobject, variable definition context, LOCK_TYPE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Does the following conform to the Fortran 2008 standard? type :: t type(lock_type), pointer :: P = NULL() end type t type(t), parameter :: N = t(null()) type(t) :: V type(lock_type), target :: L 1 nullify ( v%p ) 2 v%p => l 3 v = n ANSWER: Constraint C1303 prohibits a variable of type LOCK_TYPE from appearing in a variable definition context, with a few exceptions that do not include statements 1 and 2. Subclause 16.6.7 specifies that the appearance of a variable as a in a , or as a or in a , is a variable association context. Therefore statements 1 and 2 do not conform to the Fortran 2008 standard. The appearance of a in a , or of a or in a , are pointer association contexts, and are listed as such in subclause 16.6.8; they ought not to be listed as variable definition contexts in subclause 16.6.7. {The above proposition was advocated in 14-139r3, accepted at meeting 204, and incorporated into 14-007r2. Therefore, statements 1 and 2 will conform to the next revision of the Fortran standard. Whether statements 1 and 2 ought to be included in the present question can be decided in due course.} Constraint C1304 prohibits a variable with a subobject of type LOCK_TYPE from appearing in a variable definition context, with a few exceptions that do not include statement 3. Therefore statement 3 does not conform to the Fortran 2008 standard. {The proposition that the prohibition should only apply to variables that have nonpointer subobjects of the type EVENT_TYPE being developed in TS 18508 was accepted, and incorporated into 14-231/N2027.} Statements 1-3 are harmless, and ought to be permitted. Edits are provided to correct this. EDITS to 10-007r1: [399:22 C1304] Insert "nonpointer" before "subobject". {A change parallel to this, concerning EVENT_TYPE, is already incorporated in 14-231/N2027.} EDITS already applied in 14-007r2: [312:33+ C1283(1)+] Insert a list item "(1a) in a pointer association context (16.6.8)," {This is a knock-on effect due to deleting pointer association contexts from the list of variable definition contexts. It recovers items (2), (3) and (12) from 16.6.7p1, which are deleted below.} [313:1-2 C1283(5)] Delete "with INTENT(OUT) or INTENT(INOUT)" from item (6) because it is covered by 16.6.7p1(12). [456:44-45 16.6.7p1(2-3)] Delete list items (2) and (3) because they are not variable definition contexts, and do not apply to nonpointer variables. [445:11 16.6.7p1(12)] Append "is not a pointer and" after "dummy argument", because an actual argument pointer corresponding to a dummy argument pointer is not a variable definition context, and doesn't apply to nonpointer variables. SUBMITTED BY: Van Snyder HISTORY: 14-241r1 m205 F08/0125 submitted Note: Interps that also ask about LOCK_TYPE: * P E F08/0045 constraints on entities of type LOCK_TYPE * P E F08/0107 LOCK_TYPE, ultimate components, subcomponents, and coarrays * P E F08/0109 LOCK_TYPE and unlimited polymorphic * P E F08/0114 Can LOCK_TYPE components have the POINTER attribute? ---------------------------------------------------------------------- NUMBER: F08/0128 TITLE: Is recursive USE within a submodule permitted? KEYWORDS: SUBMODULE, USE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider Module m1 Real x End Module Submodule(m1) subm1 Use m1 End Submodule Q1. The module m1 is referenced from within one of its own submodules. Is this standard-conforming? Note that the "submodule TR", Technical Report 19767 contains, an edit with the normative requirement: "A submodule shall not reference its ancestor module by use association, either directly or indirectly." along with a note which says "It is possible for submodules with different ancestor modules to access each other's ancestor modules by use association." It also contains an edit to insert the direct reference prohibition as a constraint. However, none of this text appears in ISO/IEC 1539-1:2010. The Introduction simply comments that submodules are available, but not that they have been extended beyond the Technical Report that created them. Also, consider Module m2 Real, Private :: a Real, Protected :: b ... End Module Submodule(m2) subm2 Contains Subroutine s Use m2 Implicit None a = 3 b = 4 End Subroutine End Submodule In submodule SUBM2, procedure S references M2 by use association. Use association does not make "A" accessible. Q2. Is "A" still accessible by host association? Also, procedure S attempts to assign a value to B, which is accessed by use association, but has the PROTECTED attribute. Normally, this attribute prevents assignment to variables accessed by use association. Q3. Is the assignment to "B" standard-conforming? DISCUSSION: The requirement appears in the early drafts of Fortran 2008, up to 08-007r1, then it was modified by paper 08-154r1 creating a UTI (because the modification was broken), and finally the requirement was completely removed by paper 09-141. ANSWER: A1. No, the example was not intended to be conforming. Permission for a submodule to access its ancestor module by use associated was a mistake. An edit is provided to correct this error. A2. Moot. A3. Moot. EDITS to 10-007r1: [275:9+] 11.2.3 Submodules, "A submodule shall not reference its ancestor module by use association, either directly or indirectly." {NOTE TO J3: This could be inserted at [272:23] if that is thought to be a better place.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-134 m206 F08/0128 submitted 15-134r1 m206 Revised edits - passed by J3 meeting 15-187 m207 Failed J3 letter ballot 15-159 15-208 m207 Revised with 3 options 15-208 m207 Option 3 passed by J3 meeting N2093 m209 Failed J3 LB #35/WG5 ballot #11 [N2091/92/93] N2093 reasons for failure: F08/0128 Reinhold Bader I agree with the answers A1.- A3., except that in A1. "use associated" should be replaced by "use association". I disagree with the suggested edit, because it is too broad. Instead, I suggest the following: [275:9+] 11.2.3 Submodules, "A submodule shall not directly reference its ancestor module by use association. If a submodule indirectly references its ancestor module by use association, every USE statement in its body that causes such a reference shall specify an ONLY option. An entity in the for that option that is not a generic specifier or a renamed operator shall not be specified in the submodule's ancestor module. For an entity that is a generic specifier or a renamed operator, the referenced specific procedure (12.5.5.2) shall not be specified in the submodule's ancestor module." I'm hoping that this not only yields the same answers to the interp, but also permits compile-time checking of any violations, avoiding the complaint made by UTI 151 in 09-007. If this turns out to be unfixably wrong, I'm willing to change my vote to "yes". The rationale for the above suggestion is as follows: Imagine that S(A) is a submodule of A (the ancestor) and wants to access some other module {M} that may be a single module or the beginning of a use-chain of modules. Prior to the interp, the following dependencies are permitted, where (u) stands for use and (h) for host association: -(u)---->{M} / | / (u) / | / v S(A) --(h)---> A With the interp's original edit, the line connecting one (or more) of the modules in {M} and A causes the program to become non-conforming. The alternative edit permits the programmer to avoid this with minimal (if any) overhead. During the London meeting it was pointed out that the dependency could be avoided by restructuring the code and moving dependent parts to an auxiliary module. This is true, but it may involve writing significantly more code, and often also a submodule of the auxiliary module is needed. As a result, the global code structure becomes more difficult to understand. Furthermore, if A implements "core" concepts that many other modules might depend on (pushing code to S(A) wouldn't be needed otherwise), it may well happen that the critical use association M->A gets established later on in the development process, triggering a potentially large amount of code restructuring (multiple submodules could be affected in one fell stroke!). With the alternative edit, the only fallout is that ONLY clauses must be added in S(A) if they're not already there anyway. Robert Corbett Answer A1 states that the example was not intended to be conforming. Paper 09-141, which is cited in the discussion section, begins The prohibition against a submodule accessing or referencing its ancestor module by use association appears to have been wrong-headed in the first place. There appears to be no reason to keep it in any form. I did not attend the meeting during which paper 09-141 was approved, but I find it hard to believe that the committee could have passed that paper without intending to allow such usage. I see no technical objection to implementing the feature as it is currently specified. Paper 09-141 contains remarks to that effect. The comments Reinhold Bader included in his ballot convinced me that the feature is useful, and that its removal will put a burden on users. If the feature is retained, Q2 and Q3 need answers. My reading of the Fortran 2008 standard as written is that the answer to both questions is "yes". On a minor note, the line Note that the "submodule TR", Technical Report 19767 contains, an edit does not conform to the rules of punctuation of American English. In American English, the comma that terminates an appositive phrase appears at the end of the phrase, not after the following verb. Also, the appearance of quotation marks in that line would be considered misuse in American English. It implies that the term "submodule TR" has an unconventional meaning, which I do not think is the case here Erik Kruyt In the light of F08/0142 the examples are incorrect due to the augmented C1113. Change the module in the first example to e.g.: Module m1 Interface Module Subroutine mp1 End Subroutine End Interface Real x End Module Change the module in the second example to e.g.: Module m2 Interface Module Subroutine mp2 End Subroutine End Interface Real, Private :: a Real, Protected :: b ... End Module Van Snyder Upon reflection, I prefer an answer very similar to Option 1 in 15-208. A proposed revision is: {begin revision} DISCUSSION: The prohibition against a submodule accessing its ancestor module by use association appears in the early drafts of Fortran 2008, up to 08-007r1. Then it was modified by paper 08-154r1 creating a UTI (because the modification was broken), and finally the requirement was completely removed by paper 09-141. ANSWER: A1. Yes, the example is conforming. An edit is supplied to add this extension to the Introduction, and to add normative text to clause 11 to make this completely unambiguous. A2. Yes, A is still accessible by host association. Subclause 16.5.1.4 paragraph 2 states "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." This does not apply since A is not accessed by use association (because it is PRIVATE and therefore not accessible by use association, according to the final sentence of the second paragraph of 5.3.2). Therefore, A can still be accessed by host association. An edit is provided to revise the referenced sentence to make it clear that the entity is accessible by use association but not host association, rather than being completely inaccessible. A3. No, the assignment to B is not conforming because, according to the first sentence of the second paragraph of subclause 16.5.1.4, it is accessed by use association, and therefore violates constraint C551 which states "A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition context..." An edit is provided to add an explanation of this. EDITS to 10-007r1: [xv] Introduction, p2, first bullet, After "Submodules provide ... for modules." Insert new sentence "A submodule can reference its ancestor module by use association." [100:12] Second paragraph of 5.3.15 PROTECTED attribute, insert this text immediately after the word "descendants" (i.e. before the comma) "where it is accessed by host association". [272:23] First paragraph of 11.2.2 The USE statement and use association, after "A module shall not reference itself, either directly or indirectly." Append to paragraph "A submodule is permitted to reference its ancestor module by use association. " [273:2+4] Same subclause, NOTE 11.7, append "If a submodule accesses a PROTECTED entity from its ancestor module by use association, use of that entity is constrained by the PROTECTED attribute (5.3.15).". [443:36-37] Replace the first sentence of the second paragraph of 16.5.1.4 Host Association: "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is not accessed by host association by that name." {end revision} The questions are simplified and combined. I vacillated whether to change the edit for [100:12], viz. "where it is accessed by host association" to "where it is not accessed by use association" to try to make it clearer that construct association is not involved. Ultimately, I did not change it, because both versions might be perversely interpreted in that context. Perhaps some work is needed here. The edit for NOTE 11.7 is revised simply to draw attention to 5.3.15 to refer to it by number instead of repeating material therein. An edit is provided for [443:36-37] to revise the first sentence of the second paragraph of 16.5.1.4p2, to make it clear that the entity B is still accessible, albeit by use association: "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is not accessed by host association by that name." ("... the host entity is inaccessible by that name" could be perversely interpreted to mean the entity is entirely inaccessible by that name, i.e., neither by host nor use association. The problem is the word "entity.") This edit would also clarify the situation wherein a host scoping unit and an internal scoping unit also access the same entity by the same name by use association (no submodules involved). I hope this doesn't need another interp, something like module M1 real, public :: X = 66 end module M1 module M2 use M1, only: X contains subroutine S1 use M1, only: X implicit NONE X = 42 end subroutine S1 subroutine S2 use M1, only: X X = 42 end subroutine S2 subroutine S3 call S2 print *, X end subroutine S3 end module M2 program P use M2, only: S3 call S3 end program P Is the assignment to X in S1 conforming? Assuming the program conforms, what is printed by the PRINT statement in subroutine S3, i.e., is the assignment to X in S2 an assignment to the entity in M1, or is X a local entity in S2? According to 16.5.1.4p2, "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." This could be interpreted to mean that the entity X is not accessible in S1 or S2, neither by use association nor by host association. Decision of /INTERP: Returned F08/0128 to J3 for further work. ---------------------------------------------------------------------- NUMBER: F08/0146 TITLE: Does intrinsic assignment copy inherited components twice? KEYWORDS: Intrinsic assignment, Type extension DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider Type base Integer a End Type Type,Extends(base) :: ext Real b End Type ... Type(ext) x,y ... x = y According to 7.2.1.2 Intrinsic assignment statement, p13, "An intrinsic assignment where the variable is of derived type is performed as if each component of the variable were assigned from the corresponding component of " This would seem to indicate that the above assignment "x = y" is interpreted as the following (in unspecified order): x%a = y%a x%b = y%b x%base = y%base and the assignment to x%base is treated as if it were x%base%a = y%base%a thus assigning to x%a twice, which does not seem to make sense. If a type is extended more than once, there can be a plethora of ancestor components inheritance-associated with a component, resulting in that component being assigned many times. Q1. Are these per-component assignment semantics intended to apply to ancestor components (and thus produce multiple assignments for inherited components). It is particularly problematic if the components have type-bound defined assignment, for example consider the program Module damod Type datype Contains Procedure asgnda Generic :: Assignment(=) => asgnda End Type Contains Subroutine asgnda(a,b) Class(datype),Intent(Out) :: a Class(datype),Intent(In) :: b Print *,'Hello asgnda' End Subroutine End Module Module types Use damod Type base Type(datype) c End Type Type,Extends(base) :: ext End Type End Module Program test Use types Type(ext) :: x = ext(datype()), y y = x End Program Q2. Does this program print "Hello asgnda" once or twice? ANSWER: A1. This sentence was not intended to apply to ancestor components; an edit is supplied to correct this oversight. A2. The program should print "Hello asgnda" only once. EDITS to 10-007r1: [156:3] 7.2.1.2 Intrinsic assignment statement, p13, Between "performed as if each" and "component" insert "nonancestor". SUBMITTED BY: Malcolm Cohen HISTORY: 15-218 m208 F08/0146 Submitted m208 Failed J3 meeting vote 3-4 << start of Tom Clune's comments on F08/0146>> [I] expect defind assignment to work like finalization on the parent of an extended type [15-007r2 4.5.6.2 78:19] - if the parent has defined assignment, it is called on the parent and not on its components. From: Tom Clune Sent: Friday, October 16, 2015 9:41 AM Attached below is a motivating example of my objection to the interp we discussed on Tuesday. (Paper 218 I think.) I also have a few additional arguments to bolster my case: 1) If I understand correctly, the semantics of finalization work on the base object, not on the components of the base object. In 15-007r2.pdf 4.5.6.2 The finalization process (78:19), we have: "If the entity is of extended type and the parent type is finalizable, the parent component is finalized." The proposed interp seems to run contrary to this treatment of the base as a coherent entity. 2) Not that it really matters, but C++ implicit copy/assignment semantics also use the copy/assignment operator for the base object, not its components. 3) Just to reiterate my point on Tuesday. The proposed interp in 218 adds considerable burden to implementors of type extensions. If a base type overrides default assignment, then the type extension almost certainly must as well, or risk ruining some invariant property that the base otherwise preserves. Further, this burden propagates down the inheritance hierarchy. Perhaps on some occasions, the implementor may find that default assignment is actually ok, but it would require looking "inside" the base type implementation. (And I cannot construct a plausible motivating example of this situation, though I've also not tried very hard.) ! The following is an example of how many users intuitively expect ! instrinsic assignment of an extended type when the ancestor type ! has a derived assignment. ! Here, we desire _deep_ copy semantics for type base, which happens to ! use POINTER components. In this instance, an allocatable component ! could fix the issue, but consider the case of a base type which ! implements a binary tree, and pointer components were thus much harder ! to avoid. module the_classes type :: base integer, pointer :: ptr => null() contains procedure :: equals generic :: assignment(=) => equals end type base ! We now extend the base class in a relatively trivial manner. ! There needs to be at least one new component or the casual ! observer might think that the assignment defined below ! could just use CLASS for the RHS argument and allow inheritance ! to do the "right thing" (TM). Often we would like the new components ! defined in the extension to be copied as well, and that ! approach becomes inadequate. type, extends(base) :: child character(len=:), allocatable :: name end type child contains subroutine equals(a, b) class (base), intent(out) :: a type (base), intent(in) :: b allocate(a%ptr) a%ptr = b%ptr end subroutine equals end module the_classes program main use the_classes implicit none type (child) :: c1, c2 allocate(c1%ptr) c1%ptr = 1 c1%name = 'Alice' c2 = c1 ! Because we want "deep copy" semantics, we want to be able to change ! c1%ptr without impacting c2 c1%ptr = 2 print*,'Results:' print '(10x,a10,1x,i1)', c2%name, c2%ptr print '(a9,1x,a10,1x,i1)', 'Expected: ','Alice',1 end program main <> ---------------------------------------------------------------------- NUMBER: F08/0149 TITLE: ID= specifier and other specifiers KEYWORDS: ID= specifier, other specifiers DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: Consider the following program: program P integer :: I integer :: J(2) namelist /in/ I open ( 10, file='F', form='formatted', status='old', & & asynchronous='yes' ) 1 read ( 10, '(i0)', asynchronous='no', iostat=i ) j(1) 2 read ( 10, '(i0)', asynchronous='yes', id=i ) 3 read ( 10, in, asynchronous='yes', id=i ) 4 read ( 10, in, asynchronous='yes', id=j(i) ) end program P Subclause 9.12, paragraph 7, prohibits the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier from being associated with any entity in a . Subclause 9.12, paragraph 7, prohibits a subscript value from being affected by data transfer. Both paragraphs are silent concerning the ID= specifier. Which of statements labeled 1-4 permitted? ANSWER: Statements 1 and 2 were intended to be permitted. IOSTAT= and ID= variables should be allowed to be in a namelist group as long as it is not the NML= specifier used by the I/O statement in which they appear. Statements 3 and 4 were not intended to be permitted. The variable specified by ID= cannot be associated with the same entities as the variable specified by IOSTAT=. Edits are provided to correct these defects. EDITS to 10-007r1: [243:9 9.12p7] Before "IOSTAT=" insert "ID=,". ok [243:10 9.12p7] After "" insert "of the in that statement". [243:12 9.12p8] Before "IOSTAT=" insert "ID=,". SUBMITTED BY: Van Snyder HISTORY: 16-127 m209 F08/0149 submitted 16-127r1 m209 Revised edit for J3 vote 16-127r2 m209 Passed by J3 meeting ----------------------------------------------------------------------