J3/16-006 To: J3 From: Stan Whitlock Subject: Outstanding Fortran Interpretations for m210 Date: 2016 May 15 Outstanding Fortran Interpretations, May 15, 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 = N2006 == F08 Corrigenda 1-3 interps + N2103 == F08 Corrigendum 4 + N2098 == F08 Corrigendum 4 interps + corrections F2008 from Corrigendum 4: - F08/0122: edits for the constraints - ',or' should be ', or' twice - F08/0123: throughout the edits, "b", "e" and "p" should be in italics - F08/0130: in the replacement text - 'segment' should be followed by '(8.5.2)' - F08/0132: the new text at [281:26] should be ", a dummy procedure, or a procedure pointer" - F08/136: edits for [295:9] and [295:13] - delete final commas in replacement text + m208: 5 of 6 interps passed by J3 meeting + m209: 5 of 5 interps passed by J3 letter ballot #34 [16-101/103] + m209: 5 of 5 interps passed by WG5 ballot #10 [N085/86/87] + m209: 2 interps modified by 1st F08 Corrigendum 4 ballot [N2088/89/90/94] + m209: 6 of 8 interps passed by J3 LB #35/WG5 ballot #11 [N2091/92/93] + m209: F2008 Corrigendum 4 N2103 completed - 44 interps in N2098 + m209: 2 of 2 interps passed by J3 meeting = 0 passed WG5, 0 passed J3 LB, 2 passed J3 meeting, 17 in progress [keep this text document to 75 characters per line] ....................4 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 * P 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 u.c 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/0042 TITLE: IEEE funny values and Standard real generic intrinsic procedures KEYWORDS: IEEE-754, real math library DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: Is an infinite result from an infinite argument to a real math function exceptional (raises an exception)? Is a NaN result from a NaN argument to a real math function exceptional (raises an exception)? What are the results (value and exceptions) for the following (section 13.7.*) real math library functions [suggested results for most are included; no exception happens unless specified]: ABS(-0.0) returns +0.0 ABS(+/-infinity) returns +infinity ABS(NaN) returns a NaN ACOS(x), where |x|>1, returns a NaN and raises invalid ACOS(NaN) returns a NaN AINT(-0.0) returns -0.0 AINT(NaN) returns a NaN AINT(+infinity) returns +infinity AINT(-infinity) returns -infinity ANINT(-0.0) returns -0.0 ANINT(NaN) returns a NaN ANINT(+infinity) returns +infinity ANINT(-infinity) returns -infinity ASIN(x), where |x|>1, returns a NaN and raises invalid ASIN(NaN) returns a NaN ATAN(-0.0) returns -0.0 ATAN(+infinity) returns +pi/2 ATAN(-infinity) returns -pi/2 ATAN(NaN) returns a NaN ATAN2(NaN,x) returns a NaN ATAN2(y,NaN) returns a NaN ATAN2(+/-0.0, -0.0) returns +/-pi (and not raise invalid) ATAN2(+/-0.0, +0.0) returns +/-0.0 (and not raise invalid) ATAN2(+/-0.0, x) returns +/-pi for x < 0.0 ATAN2(+/-0.0, x) returns +/-0.0 for x > 0.0 ATAN2(y, +/-0.0) returns -pi/2 for y < 0.0 (and not raise divide by zero) ATAN2(y, +/-0.0) returns +pi/2 for y > 0.0 (and not raise divide by zero) ATAN2(+/-y, -infinity) returns +/-pi for finite y > 0.0 ATAN2(+/-y, +infinity) returns +/-0.0 for finite y < 0.0 ATAN2(+/-infinity, x) returns +/-pi/2 for finite x ATAN2(+/-infinity, -infinity) returns +/-3pi/4 (and not raise invalid) ATAN2(+/-infinity, +infinity) returns +/-pi/4 (and not raise invalid) CEILING(+/-infinity) returns +/-infinity CEILING(-0.0) returns -0.0 CEILING(NaN) returns a NaN COS(+/-0.0) returns 1 COS(NaN) returns a NaN COS(+/-infinity) returns a NaN and raises invalid COSH(+/-0.0) returns 1 COSH(NaN) returns a NaN COSH(+/-infinity) returns a +infinity DIM(NaN,y) returns a NaN DIM(x,NaN) returns a NaN DIM(+/-0.0, +/-0.0) returns a +0.0 DIM(+infinity, -infinity) returns a NaN and raises invalid DIM(+infinity, +infinity) returns +0.0 DIM(-infinity, -infinity) returns +0.0 DIM(-infinity, +infinity) returns +0.0 DPROD(NaN,y) returns a NaN DPROD(x,NaN) returns a NaN DPROD(+/-0.0, +/-infinity) returns a NaN and raises invalid DPROD(+/-infinity, +/-0.0) returns a NaN and raises invalid DPROD(+/-infinity, +/-infinity) returns an infinity with its sign being the XOR of the arguments, and raises no exceptions. DPROD(+/-0.0, +/-0.0) returns a zero with its sign being the XOR of the arguments, and raises no exceptions. EXP(NaN) returns a NaN EXP(+/-0.0) returns 1 EXP(-infinity) returns +0.0 EXP(+infinity) returns +infinity EXPONENT(+/-0.0) returns 0 [should be -HUGE(0)] and raises invalid EXPONENT(NaN) returns HUGE(0) and raises invalid EXPONENT(+/-INF) returns HUGE(0) and raises invalid EXPONENT(denormal) returns the value as if the number were normalized and the exponent range were unbounded If /e/ is not representable as a default integer, invalid is raised and sign(/e/)*HUGE(0) should be returned. FLOOR(NaN) returns a NaN FLOOR(-0.0) returns -0.0 FLOOR(+/-infinity) returns +/- infinity FRACTION(-0.0) returns -0.0 FRACTION(NaN) returns a NaN FRACTION(denormal) returns the value as if the number were normalized and the exponent range were unbounded FRACTION(+/-infinity) returns +/- infinity INT(NaN) returns an unspecified value and raises invalid INT(+/-infinity) returns an unspecified value and raises invalid INT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid LOG(+/-0.0) returns -infinity and raises divide-by-zero LOG(NaN) returns a NaN LOG(1.0) returns +0.0 LOG(x), for x < 0, returns a NaN and raises invalid LOB(+infinity) returns +infinity LOG10(+/-0.0) returns -infinity and raises divide-by-zero LOG10(NaN) returns a NaN LOG10(1.0) returns +0.0 LOG10(x), for x < 0, returns a NaN and raises invalid LOG10(+infinity) returns +infinity MAX(NaN,NaN) returns a NaN MAX(NaN,y) returns y [some say it should be NaN] MAX(x,NaN) returns x [some say it should be NaN] MAX(-0.0,+0.0) returns +0.0 MAX(-0.0,-0.0) returns -0.0 MAX(+infinity,y) returns +infinity MAX(-infinity,y) returns y MIN(NaN,NaN) returns a NaN MIN(NaN,y) returns y [some say it should be NaN] MIN(x,NaN) returns x [some say it should be NaN] MIN(-0.0,+0.0) returns -0.0 MIN(-0.0,-0.0) returns -0.0 MIN(-infinity,y) returns -infinity MIN(+infinity,y) returns y MOD(NaN,y) returns a NaN MOD(x,NaN) returns a NaN MOD(+/-infinity,y) returns a NaN and raises invalid MOD(+/-infinity,+/-infinity) returns a NaN and raises invalid MOD(x,+/-0.0) returns a NaN and raises invalid MOD(+/-0.0,+/-0.0) returns a NaN and raises invalid MODULO(NaN,y) returns a NaN MODULO(x,NaN) returns a NaN MODULO(+/-infinity,y) returns a NaN and raises invalid MODULO(+/-infinity,+/-infinity) returns a NaN and raises invalid MODULO(x,+/-0.0) returns a NaN and raises invalid MODULO(+/-0.0,+/-0.0) returns a NaN and raises invalid NEAREST(NaN,y) returns a NaN NEAREST(x,NaN) returns a NaN NEAREST(x,+/-0.0) returns a NaN and raises invalid [why???] NEAREST(+infinity,+num) returns +infinity ??? NEAREST(+infinity,-num) returns +maximum finite number NEAREST(-infinity,+num) returns -maximum finite number NEAREST(-infinity,-num) returns -infinity ??? NINT(NaN) returns an unspecified value and raises invalid NINT(+/-infinity) returns an unspecified value and raises invalid NINT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid RRSPACING(NaN) returns a NaN RRSPACING(+/-infinity) returns +/-infinity [differs from current F2003] RRSPACING(+/-0.0) returns +0.0 RRSPACING(+/-denormal) returns ??? SCALE(NaN,y) returns a NaN SCALE(+/-infinity,y) returns +/-infinity SCALE(-0.0,y) returns -0.0 SET_EXPONENT(NaN,y) returns a NaN SET_EXPONENT(+/-infinity,y) returns +/-infinity SET_EXPONENT(-0.0,y) returns -0.0 SET_EXPONENT(denormal,y) returns ??? SIGN(NaN,y), where 0 < y, returns the same NaN, but with the sign bit cleared. SIGN(NaN,y), where y < 0, returns the same NaN, but with the sign bit set. SIN(NaN) returns a NaN SIN(+/-infinity) returns a NaN and raises invalid SIN(-0.0) returns -0.0 SINH(NaN) returns a NaN SINH(+/-infinity) returns +/- infinity SINH(-0.0) returns -0.0 SPACING(NaN) returns a NaN SPACING(+/-infinity) returns +infinity SPACING(-0.0) returns TINY(+0.0) SPACING(denormal) returns TINY(+0.0) ??? SQRT(NaN) returns a NaN SQRT(+infinity) returns +infinity SQRT(-0.0) returns -0.0 SQRT(x), where x < 0.0, returns a NaN and raises invalid TAN(NaN) returns a NaN TAN(+/-infinity) returns a NaN and raises invalid TAN(-0.0) returns -0.0 TANH(NaN) returns a NaN TANH(+/-infinity) returns +/-1.0 TANH(-0.0) returns -0.0 13.7 [300:13-15] incorrectly requires an infinite result or a NaN result to always signal some IEEE exception. Consider changing [300:13] "infinite result" to "infinite result (from finite arguments)". Reason: IEEE-754 mathematical operations on infinity that produce an infinity are unexceptional. Consider changing [300:14] "NaN result" to "NaN result (from non-NaN arguments)". Reason: IEEE-754 mathematical operations on quiet NaN operands that produce a quiet NaN result are unexceptional. Consider adding to 13.7 [300:15+] something along the lines of: "Unless specified otherwise, a math function with NaN argument(s) shall return a NaN, which should be one of the NaN arguments." This allows not having to specify the results for each specific math function. Consider adding the above suggested cases to each of the 13.7.* functions, perhaps, with a bold face IEEE sub-heading. ANSWER: The erroneous text quoted from 13.7 in Fortran 2003 has been revised in Fortran 2008, and again by Corrigendum 2 for Fortran 2008, and now no longer conflicts with the IEEE-754 standard. To specify the results of all the intrinsics for non-normal values is beyond the scope of an interpretation. This could be considered for a future revision. EDITS to 10-007r1: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-121r1 m171 F03/0042 submitted 15-248 m208 Revised answer and edits - passed by J3 meeting 16-103 m209 Passed by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- 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, its not clear to me (its 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 interpretration. Decision of /INTERP: Failed. ------------------------------------------------------------------------ NUMBER: F08/0099 TITLE: VOLATILE in specification expressions KEYWORD: VOLATILE, specification expression DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: Is the following subprogram required always to print "T T"? subroutine Wobbly ( N ) integer, volatile :: N integer :: A ( n, n ) integer :: B ( n * n ) print *, size(a) == size(b), size(a,1) == size(a,2) end subroutine Wobbly ANSWER: No. There are three specification expressions in the subroutine, and the volatile variable N appears in each of them. Since, being volatile, the variable N might have a different value each time it is referenced, these three specification expressions might receive different values for their references to N. If that happens, the array sizes might well be different. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 13-298r1 m202 F08/0099 submitted 13-298r2 m202 Revised answer - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Q1. Does the following program fragment conform to the 2008 standard? subroutine S ( P ) interface subroutine Q ( X ) real, intent(inout) :: X end subroutine Q end interface interface subroutine P ( A ) import procedure (R) :: A end subroutine P end interface procedure (Q) :: R end subroutine S 12.4.3.3p2 says "If an entity that is made accessible by this means is accessed by host association and is defined in the host scoping unit, it shall be explicitly declared prior to the interface body." However, although the procedure R is declared in the host scoping unit it is not defined in the host scoping unit, so this is ineffective. Q2. If the IMPORT statement were changed to "IMPORT R", would that be conforming? 12.4.3.3p1 says "An entity that is imported in this manner and is defined in the host scoping unit shall be explicitly declared prior to the interface body." Again, procedure R is declared but not defined in the host scoping unit, so this requirement is ineffective. ANSWER: These examples were not intended to conform to the Fortran standard. An edit is provided. EDITS to 10-007r1: [282:7] 12.4.3.3p1, after "imported in this manner and is" change "defined" to "declared". [282:14] p2, after "is accessed by host association and is" change "defined" to "declared". SUBMITTED BY: Van Snyder HISTORY: 13-305 m202 F08/0100 submitted 13-305r1 m202 Revised answer & edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Program p1 Real :: x = 3, y = 4 Namelist /n/ x, y Write (*,n) End Program According to 5.6, "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, this stops short of saying that the order is the same, merely that it determines it. Perhaps it might be standard-conforming for a processor to always produce the values in reverse order, for example. 10.11.4 does not seem to address the issue of what the order is. Q1: Is the order meant to be the same? Consider Program p2 Real :: x = 3, y = 4 Namelist /n/ x, y, x Write (*,n) End Program This program did not conform to Fortran 90, but does conform to Fortran 2003 and later. The Fortran 2008 standard says (5.6p2): "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, there are only two variables in the NAMELIST statement, X and Y. Therefore it seems to be ambiguous whether the output should be something like &N X=3 Y=4 / or &N Y=4 X=3 / Some compilers produce &N X=3 Y=4 X=3 / but this is not an ordering of the variables X and Y. Q2. Is this program intended to conform to the standard, and if so, what is the intended output? ANSWER: A1. Yes, the order is meant to be the same. An edit is supplied to clarify this. A2. The program was intended to conform to the standard, and the output was intended to be the third option. An edit is supplied to correct the text in 5.6. EDITS to 10-007r1: [111:13-14] 5.6p2, replace entire paragraph with "The order in which the values appear on output is the same as the order of the s in the namelist group object list; if a variable appears more than once as a for the same namelist group, its value appears once for each occurrence". SUBMITTED BY: Malcolm Cohen HISTORY: 13-314 m202 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Program test Type t End Type Type,Extends(t) :: t2 End Type Class(t),Allocatable :: x,y Type(t),Allocatable :: a x = t() y = t2() a = t() Do i=1,2 Select Type (z=>Merge(a,x,i==1)) ! A Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(x,a,i==1)) ! B Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(a,y,i==1)) ! C Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(y,a,i==1)) ! D Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(x,y,i==1)) ! E Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do End Program According to the standard, the type of the result of MERGE is the same as the type of TSOURCE. One might imagine that this means that the result is polymorphic if and only if TSOURCE is polymorphic. This would be a slightly unusual and unexpected asymmetry. Also, the types of FSOURCE and TSOURCE have to be the same. If this means both the declared and dynamic types, one might imagine that this means that the result is polymorphic if and only if both FSOURCE and TSOURCE are polymorphic, since otherwise the non-polymorphic argument decides the type. On the other hand, if the type requirements are talking about the declared type only, one might imagine that the result is polymorphic if either TSOURCE or FSOURCE is polymorphic. However, in any case there would seem to be an error in the standard, since the result is specified to be the same as TSOURCE, rather than the same as whichever argument is chosen to be the result value; if this refers to the dynamic type, it is contradictory when FSOURCE is chosen as the result value. And if it does not refer to the dynamic type, there appears to be no statement which says what the dynamic type of the result is. Q1. Is the apparent asymmetry between the treatment of TSOURCE and FSOURCE intended? Q2. Which of the MERGE invocations A-E are polymorphic? Q3. When the result of MERGE is polymorphic, are the dynamic types of TSOURCE and FSOURCE permitted to be different? And if they are, is the dynamic type of the result the same as the chosen argument and not necessarily the same as TSOURCE? ANSWER: A1. There is no asymmetry between TSOURCE and FSOURCE, because they are required to have the same type and type parameters. This means that both the declared and dynamic types and type parameters must be the same. A2. Only MERGE invocation E is polymorphic. An edit is provided to clarify this. A3. No, the dynamic types and type parameters are required to be the same. Note that because MERGE is elemental, it needs the type and type parameters to be the same for both the declared and dynamic types, otherwise the principle that all elements of an array have the same (declared and dynamic) type and type parameters would be broken. EDITS to 10-007r1: [368:26] 13.7.110p4 (Result Characteristics), "Same as TSOURCE." -> "Same type and type parameters as TSOURCE. Because TSOURCE and FSOURCE are required to have the same type and type parameters (for both the declared and dynamic types), the result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." SUBMITTED BY: Malcolm Cohen HISTORY: 13-321 m202 F08/0102 submitted 13-321r1 m202 Revised example - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0103 TITLE: Pointers to internal procedures with different host instances KEYWORD: internal procedure, procedure pointer, host instance DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider: MODULE TYPES ABSTRACT INTERFACE SUBROUTINE SUBROUTINE() END SUBROUTINE SUBROUTINE END INTERFACE TYPE PPS PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR END TYPE PPS END MODULE TYPES SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTEGER I, J, N N = SIZE(PPA) DO I = 1, N CALL PPA(I)%SU_PTR() END DO PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N) END SUBROUTINE CPPS RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTERFACE SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE CPPS END INTERFACE IF (SIZE(PPA) .EQ. 3) THEN CALL CPPS(PPA) ELSE CALL OUTER( (/ PPA, PPS(INNER) /) ) END IF CONTAINS SUBROUTINE INNER() WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA) END SUBROUTINE INNER END SUBROUTINE OUTER PROGRAM MAIN USE TYPES INTERFACE RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE OUTER END INTERFACE TYPE(PPS),DIMENSION(0) :: PPA CALL OUTER(PPA) END PROGRAM MAIN Does this program print all true values? The procedure pointers are all associated with the internal procedure INNER, which might lead one to believe that the answer is yes (that is, they are all associated with the same target), but each procedure pointer at each nesting level has a different host instance, which might lead one to believe that the answer is no (and that therefore only one of each of the 3-element sequences printed will be T). ANSWER: No, the program does not print all true values; two procedure pointers to the "same" internal procedure are only associated if the host instances are also the same. An edit is supplied to the standard to clarify this. EDITS to 10-007r1: [330:20] 13.7.16p5 Case (ii), after "with TARGET" insert "and, if TARGET is an internal procedure, they have the same host instance". [330:22] Case (iii), after "same procedure" insert "and, if the procedure is an internal procedure, they have the same host instance". SUBMITTED BY: Robert Corbett HISTORY: 13-357 m202 F08/0103 submitted with four answers 13-357r1 m202 Selected answer, added edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 All references are to Fortran 2008 10-007r1. On comp.lang.fortran Francis Coudert asked The Fortran 2008 standard defines an inquiry function as an "intrinsic function, or function in an intrinsic module, whose result depends on the properties of one or more of its arguments instead of their values". 10-007r1 section 1.3.89 [11:27-30] I wonder: by that definition, how can the IEEE_SUPPORT_HALTING(FLAG) function from the IEEE_EXCEPTIONS intrinsic module be an inquiry function? Its result depends on the value of FLAG, not its properties. QUESTIONS: Question 1. Are the functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc intended to be inquiry functions? Question 2. Are they consistent with the definition of inquiry functions? Question 3. Are they allowed in Specification expressions? Question 4. Are they allowed in Constant expressions? ANSWERS: Answer 1. No. These intrinsic module functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc are not inquiry functions because their results depend on other than the properties of their arguments. Edits are provided to correctly identify these functions as transformational: [18:35-37] section 1.3.146 transformational function intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function Answer 2. No. Their current classification is inconsistent with the definition of inquiry functions. Answer 3. They should be allowed in specification expressions. Edits are provided to correct this. Answer 4. No. Only the 3 IEEE_* functions should be allowed in constant expressions, not the 3 C_* functions. Edits are provided to correct this. EDITS to 10-007r1: [150:28+] section 7.1.11 Specification expression, paragraph 2, after item (10), insert a new item: "(10a) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC (14), IEEE_EXCEPTIONS (14), or ISO_C_BINDING (15.2), where each argument is a restricted expression," [152:7-8] section 7.1.12 Constant expression, paragraph 1, replace item (8): "(8) a reference to the transformational function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE ARITHMETIC (14), where each argument is a constant expression," with: "(8) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant expression," [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.1, for procedure IEEE_SUPPORT_ROUNDING: change the "Class" column entry from "I" to "T". [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.2, for procedures IEEE_SUPPORT_FLAG and IEEE_SUPPORT_HALTING: change the "Class" column entries from "I" to "T". [418:16] section 14.11.27 IEEE_SUPPORT_FLAG (FLAG) or IEEE_SUPPORT_FLAG (FLAG, X), paragraph 2: "Inquiry function." -> "Transformational function." [418:32] section 14.11.28 IEEE SUPPORT HALTING (FLAG), paragraph 2: "Inquiry function." -> "Transformational function." [420:4] section 14.11.32 IEEE_SUPPORT_ROUNDING (ROUND_ VALUE) or IEEE_SUPPORT_ROUNDING (ROUND_VALUE, X), paragraph 2: "Inquiry function." -> "Transformational function." [426:19] section 15.2.3.2 C_ASSOCIATED (C_PTR_1 [, C_PTR_2]), paragraph 2: "Inquiry function." -> "Transformational function." [428:9] section 15.2.3.5 C_FUNLOC (X), paragraph 2: "Inquiry function." -> "Transformational function." [428:21] section 15.2.3.6 C_LOC (X), paragraph 2: "Inquiry function." -> "Transformational function." SUBMITTED BY: Dick Hendrickson HISTORY: 14-100 m203 F08/0104 submitted 14-100r1 m203 Answer proposed 14-100r2 m203 Passed by J3 meeting 14-192 m204 Passed as amended by J3 letter ballot 14-146 N2047 m206 Passed as amended by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute is not argument associated with the corresponding actual argument. Rather, it is associated with an anonymous data object whose value is copied from the actual argument before execution of the executable constructs of the subprogram commences, and before expressions in the specification part are evaluated. Therefore, it can successfully take part in asynchronous operations that both start and complete within that procedure call, independently of whether the corresponding actual argument has or has not the ASYNCHRONOUS attribute. There is no problem if a dummy argument has the VALUE attribute and the corresponding actual argument has the ASYNCHRONOUS attribute, independently of whether the dummy argument has the ASYNCHRONOUS attribute. Subclause 9.6.4.1, paragraph 6 [220:13-15], prohibits an actual argument that is part of a pending input storage sequence affector from being associated with a dummy argument that has the VALUE attribute. EDITS to 10-007r1: None. SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting 14-192 m204 Failed J3 letter ballot #30 14-146 14-269 m205 Revised answer - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Was it intended that MOVE_ALLOC can affect the allocation status of an array on an image other than the executing image? An example is CALL MOVE_ALLOC(A,B[I]%A) ANSWER: No, it was not intended that the executing image can affect the allocation status of an array on an image other than the executing image. Edits are provided to correct this. EDITS to 10-007r1: 13.7.118 MOVE_ALLOC(FROM,TO), para 3: [372:18] In the description of FROM, after "It shall be allocatable", add "and shall not be a coindexed object". [372:19] In the description of TO, after "It shall be allocatable", add "and shall not be a coindexed object". SUBMITTED BY: John Reid HISTORY: 14-119 m203 F08/0106 submitted - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- 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/0108 TITLE: ultimate components and coarrays KEYWORD: ultimate components, coarrays DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTIONS: 1. Is the declaration of V permitted: type :: one real, allocatable :: C[:] end type one type :: two type(one), allocatable :: A end type two type(two), pointer :: V(:) 2. Is the declaration of X permitted: type :: three real :: C end type three type :: four type(three), allocatable :: A[:] end type four type(four) :: X ANSWERS: 1. Type two is not conforming, because the entity A has a coarray ultimate component and C525 requires such an entity to be a nonpointer nonallocatable scalar. Therefore the declaration of V is not permitted. 2. X satisfies C525, so declaration of X is permitted. X has an ultimate (allocatable) coarray component (A[:]), and therefore according to C526 must be a dummy argument or have the SAVE attribute. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 14-163 m204 F08/0108 submitted 14-163r1 m204 Fixed examples in questions, revised answer - passed by J3 meeting 14-258 m205 Passed as amended by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0109 TITLE: LOCK_TYPE and unlimited polymorphic KEYWORD: LOCK_TYPE, unlimited polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is available. Q1. Is allocation of X%C permitted? TYPE t TYPE(LOCK_TYPE),ALLOCATABLE :: c END TYPE TYPE(t) :: x[*],y[*] ALLOCATE(y%c) ALLOCATE(x%c,SOURCE=y%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=L ) Q3. Is allocation of C permitted? class(*), pointer :: C allocate ( LOCK_TYPE :: C ) Q4. Is pointer assignment to C permitted? class(*), pointer :: C type(lock_type), intent(in), target :: L[*] c => L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE, SAVE :: C[:] TYPE(LOCK_TYPE), SAVE :: X[*] ALLOCATE(C[*],MOLD=X) ANSWER: A1. Allocation of X%C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A2. Allocation of C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A3. This allocation of C is permitted. It cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. Edits are given to fix C1302 to say "declared type" explicitly to avoid this confusion. Note that it is impossible to actually use the allocated target of C in any useful fashion; SELECT TYPE cannot access it because the associate-name would be a named lock variable, but it is not a coarray so that would not be allowed. So this is permitted, but useless, and because it is useless it is also harmless. A future revision could disallow this without the concomitant incompatibility inconveniencing any programs. A4. Pointer assignment to C is permitted. As in A3, this is useless but harmless. A future revision could disallow this without the concomitant incompatibility inconveniencing any programs. A5. This statement was intended to be permitted. An edit is supplied to correct the requirements. Note that the term "potential subobject component" is defined in interp F08/0124 and will be in F2008 Corrigendum 4: [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". EDITS to 10-007r1: [127:8-9] 6.7.1.1 Syntax, C642, Change "C_PTR," to "C_PTR or" Delete ", LOCK_TYPE ... LOCK_TYPE". [127:9+] Insert new constraint "C642a (R627) If SOURCE= appears, the declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." [127:18-19] 6.7.1.1, p4, Instead of the edit in Corr. 2, make this change to the 10-007r1 text: Change "If is" -> "If an ALLOCATE statement has a SOURCE= specifier and an that is". {There is no problem with MOLD=. "subcomponent" works ok here because we have an object not a type.} so p4 reads: "If an ALLOCATE statement has a SOURCE= specifier and an that is a coarray, shall not have a dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a subcomponent whose dynamic type is LOCK_TYPE." [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK_TYPE" -> "variable with declared type LOCK_TYPE". SUBMITTED BY: Van Snyder HISTORY: 14-164 m204 F08/0109 submitted 14-164r3 m204 As amended, passed by J3 meeting 14-258 m205 Failed the J3 letter ballot #31 14-233r1 15-253 m208 Revised - passed by J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed as amended by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: J3 considertion 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/0112 TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider CHARACTER(80) text(0:100), msg INTEGER stat,istat(0:80) REAL,ALLOCATABLE :: x(:),y(:,:) ... ALLOCATE(x(10),STAT=stat,ERRMSG=text(stat)) ! A DEALLOCATE(x,STAT=stat,ERRMSG=text(stat)) ! B msg = '' ALLOCATE(y(999999,999999),STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! C msg = '' DEALLOCATE(x,STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! D In each of the statements labelled A-D, there is a dependency between the STAT= specifier and the ERRMSG= specifier (from STAT= to ERRMSG= in A and B, and from ERRMSG= to STAT in C and D). There appears to be no prohibition against this (though there are many prohibitions against other dependencies in ALLOCATE and DEALLOCATE). Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: These are not standard-conforming, as no interpretation is established for them. An edit is supplied to clarify this prohibition. EDITS to 10-007r1: [132:4] 6.7.4 STAT= specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG= specifier, p1, append "The shall not depend on the value of the .". SUBMITTED BY: Malcolm Cohen HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting 14-258 m205 Passed by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0113 TITLE: Specifiers in image control statements KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider CHARACTER(80) text(0:100),msg INTEGER stat,istat(2) REAL,ALLOCATABLE :: x(:) TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*] LOGICAL acq, aacq(0:80) ... SYNC ALL(STAT=stat,ERRMSG=text(stat)) ! A SYNC IMAGES (*,STAT=stat,ERRMSG=text(stat)) ! B SYNC MEMORY(STAT=stat,ERRMSG=text(stat)) ! C LOCK(lock,ACQUIRED_LOCK=acq, & STAT=istat(MERGE(1,2,acq)), & ERRMSG=text(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=stat,ERRMSG=text(stat)) ! E LOCK(alock(stat),STAT=stat) ! F msg = '' UNLOCK(alock(LEN_TRIM(msg)),STAT=stat, & ERRMSG=msg) ! G stat = 13 SYNC IMAGES(stat,STAT=stat) ! H msg = 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=stat, & ERRMSG=msg) ! I In each of the statements labelled A-F, there is a dependency between the STAT= specifier and the ERRMSG= specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK= specifier and the STAT= specifier (there is no dependency between ACQUIRED_LOCK= and ERRMSG= because the former is only set on successful execution and the latter is only set on an error condition). There appears to be no restrictions at all on any dependencies from ACQUIRED_LOCK=. In the LOCK statement (F), there is a dependency between the STAT= specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG= specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT= variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG= variable and the image set. Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: No interpretation is established and therefore these are not conforming. An edit is provided to clarify this. EDITS to 10-007r1: [190:16-] 8.5.4 SYNC IMAGES statement, insert new p1, "The value of shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the value of the , , or .". [195:2-] 8.5.7 STAT= and ERRMSG= specifiers..., insert new p1, "The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 14-209 m204 F08/0113 submitted - passed by J3 meeting 14-258 m205 Passed by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- 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/0115 TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider PROGRAM Main INTEGER, ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') CALL async_read(array) CALL fred(array(::2)) ! Problematic? WAIT (11) PRINT *, array CONTAINS SUBROUTINE async_read(array) INTEGER, ASYNCHRONOUS, INTENT(INOUT) :: array(:) READ (11, *, ASYNCHRONOUS='yes') array END SUBROUTINE END PROGRAM SUBROUTINE Fred (arg) ! In general, an external procedure INTEGER :: arg(*) ! Otherwise unused CONTINUE ! In general, something that takes more time END SUBROUTINE Is the call to "Fred" standard-conforming? It is not excluded by 5.3.4p2, because 'array' is merely associated with 'arg' in subroutine Fred, and not used in any executable statement or specification expression there. However, if copy-in/out is used for argument passing and the actual i/o transfer occurs in between the copy-in and copy-out, the wrong answers will be given. ANSWER: This program was not intended to be conforming. An edit is provided to correct this oversight. EDITS to 10-007r1: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or" and insert a comma after "scoping uinit". SUBMITTED BY: Nick Maclaren HISTORY: 14-218 m205 F08/0115 submitted 14-218r1 m205 Revised 14-218r2 m205 Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: In all cases, Alf is a Fortran procedure like this: SUBROUTINE Alf (Arg) BIND(C,NAME='Alf') INTERFACE SUBROUTINE Arg () BIND(C) END SUBROUTINE Arg END INTERFACE CALL Arg END SUBROUTINE Alf Q1. Consider extern void Bert (void) { ; } int main (void) { Alf(Bert); } 15.5.1p2 requires a procedure defined by means other than Fortran to have the same binding label as the interface. Function Bert() has a binding label of 'Bert', but 15.5.2p2 states that the dummy argument Arg has no binding label, therefore 15.5.1p2 is not satisfied. Was this intended to be conforming? Q2. Consider static void Fred (void) { ; } int main (void) { Alf(Fred); } 15.5.1p2 requires a procedure defined by means other than Fortran to have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999. Function Fred() has no such name, as its definition has internal linkage. However, linkage in C affects only the visibility of the external name, and has no application to either types or values, whether in the form of function parameters or other pointers. Was this intended to be conforming? Q3. Consider extern inline void arg (void) { ; } int main (void) { Alf(Joe); } C99 6.7.4 describes the inline specifier. This does not prevent it from having external linkage, but "An inline definition does not provide an external definition for the function" i.e. despite having external linkage, there might be no external definition that could be invoked from Fortran. Was it not an oversight not to exclude inline in 15.5.1? ANSWERS: A1. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A2. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A3. A C function with no external definition is not "defined by means other than Fortran" so much as "not defined". This was not intended to be conforming. An edit is provided to clarify this situation. EDITS to 10-007r1: [436:15] 15.5.1 Definition and reference of interoperable procedures, p1, Append sentence "A C function that has an inline definition and no external definition is not considered to be defined in this sense.". In 15.5.1p2, apply these edits [436:16] After "means other than Fortran," delete "it shall", [436:17] Before "be describable" insert "it shall", after "the interface," insert "and", [436:18-19] Before "have a name" insert "if it is accessed using its binding label, it shall" and begin a bullet sub-list, and make the "have the same" bullet the second sublist item. This makes that whole paragraph read "If the procedure is defined by means other than Fortran, -- it shall be describable by a C prototype that is interoperable with the interface, and -- if it is accessed using its binding label, it shall - have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999, and - have the same binding label as the interface." {Note this wording uses "accessed" rather than "invoked" since it can be the argument of C_FUNPTR or the target in a procedure pointer assignment.} SUBMITTED BY: Nick Maclaren HISTORY: 14-221 m205 F08/0116 submitted 14-221r1 m205 Revised 14-221r2 m205 Further Revised - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Is the following program conforming and required to print 10, 10, 10 and 123, 123, 123? PROGRAM Main INTEGER, TARGET :: coarray(3)[*] coarray = 10*THIS_IMAGE() SYNC ALL IF (THIS_IMAGE() == 1) THEN SYNC ALL coarray = 123 SYNC ALL ELSE IF (THIS_IMAGE() == 2) THEN CALL Fred(coarray(:)[1]) ELSE SYNC ALL SYNC ALL END IF CONTAINS SUBROUTINE Fred (arg) INTEGER, TARGET :: arg(:) PRINT *, arg SYNC ALL SYNC ALL PRINT *, arg END SUBROUTINE Fred END PROGRAM Main DISCUSSION: This program is modifying an actual argument while it is associated with a dummy argument. That is normally prohibited by the anti-aliasing rules in 12.5.2.13, but these do not operate in the TARGET dummy argument case. However, coindexed actual arguments are accessing remote memory, so in general will be passed by copy-in/out; in this case permitting aliasing is not reasonable. ANSWER: The program is not intended to be conforming. Edits are provided to correct this oversight. EDITS to 10-007r1: [300:14] 12.5.2.13p1(3)(b) after "target other than" insert "a coindexed object or". [300:22] 12.5.2.13p1(4)(b) after "target other than" insert "a coindexed object or". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-223 F08/0117 submitted m205 14-223r1 Revised example and discussion - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does this program conform to the Fortran 2008 standard? type :: T integer :: C end type T type(t), parameter :: V = T(41) associate ( W => V ) w%c = 42 end associate end DISCUSSION: Because the selector is not permitted to appear in a variable definition context, the associate-name is not permitted to appear in a variable definition context. However, that does not affect subobjects of the associate-name. ANSWER: The associate-name is not permitted to appear in a variable definition context because no interpretation is established; however, it should be explicitly stated that this is not permitted. An edit is provided to clarify this. EDITS to 10-007r1: [170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801, Change " shall not appear" to "neither the nor any subobject thereof shall appear". [171:12] 8.1.3.3 Attributes of associate names, p2, Change "the associate name shall not appear" to "neither the associate name nor any subobject thereof shall appear". [184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836, Change " shall not appear" to "neither the nor any subobject thereof shall appear". SUBMITTED BY: Van Snyder HISTORY: 14-240r1 m205 F08/0118 submitted 14-240r2 m205 Revised question and answer - 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 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Do the GO TO statements in the following conform to the Fortran 2008 standard? go to 1 block 1 end block go to 2 critical 2 end critical ANSWER: Branching to an END BLOCK or END CRITICAL statement from outside the construct was intended to be prohibited. Edits are provided to correct this omission. EDITS to 10-007r1: [172:13+] 8.1.4 BLOCK construct, after p3 (before NOTE 8.5), Insert new paragraph "It is permissible to branch to an only from within its BLOCK construct.". [173:21+] 8.1.5 CRITICAL construct, after p3 (before NOTE 8.6), Insert new paragraph "It is permissible to branch to an only from within its CRITICAL construct.". FUTURE REVISION: A future revision could make all of these constraints, and combine them into a single requirement as follows. [170:36 8.1.3.2p3] Delete the paragraph. [175:35-36 8.1.6.4p1] Delete "It is permitted ... DO construct." [175:40 8.1.6.4p2] Delete "Transfer of control ... ." [180:25 8.1.7.2p2] Delete "It is permissible ... IF construct." [182:26 8.1.8.2p3] Delete the paragraph. [185:26 8.1.9.2p9] Delete the paragraph. [187:7+ 8.2.1p1+] Insert constraint: "C847a If a branch target statement is an , , , , , , or , the branching statement that references the label of that branch target statement shall be within the construct completed by that branch target statement." SUBMITTED BY: Van Snyder HISTORY: 14-242 m205 F08/0119 submitted 14-242r1 m205 Revised question and answer 14-242r2 m205 Fixed typo in example - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Is the name of a procedure pointer a local identifier? The list of classes of local identifiers given in paragraph 1 of subclause 16.3.1 of J3/10-007r1 (page 440) does not include procedure pointers. ANSWER: Yes, if a procedure pointer is named, the name of the procedure pointer is a local identifier. An edit is provided to amend the oversight. EDITS to 10-007r1: [440:4, 16.3.1p1] In item (1) after "named constants," insert "named procedure pointers,". SUBMITTED BY: Robert Corbett HISTORY: 14-256 m205 F08/0120 submitted - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Fortran 2003 7.1.6 (Specification expressions), says on 141:12: A restricted expression is an expression in which each operation is intrinsic Fortran 2008 7.1.11 says on 150:8: A restricted expression is an expression in which each operation is intrinsic or defined by a specification function This new feature is not called out in the Introduction but should be. ANSWER: This was an oversight. An edit to correct the problem is supplied. EDITS to 10-007r1: Introduction, page xv. Add to the "Data declaration" list in paragraph 2: "A can be used in a specification expression." SUBMITTED BY: Steve Lionel HISTORY: 14-259 m205 F08/0121 submitted 14-259r1 m205 In edit, replace "defined operator" with "" - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTIONS: Q1. Consider Module m Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] Contains Subroutine dubious Volatile x Volatile xco ... End Subroutine End Module Program bad Use m Volatile x Volatile xco ... End Program 5.3.19 C560 says "The VOLATILE attribute shall not be specified for a coarray that is accessed by use (11.2.2) or host (16.5.1.4) association." That means that the two "VOLATILE XCO" statements are not conforming. However, the "VOLATILE X" statements have essentially the same effect, but are unaffected by the constraint, which seems inconsistent. Was this constraint also intended to apply to objects with coarray components? Q2. Consider Program blockvolatile Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] ... Block Volatile x Volatile xco End Block 5.3.19 C561 says "Within a BLOCK construct (8.1.4), the VOLATILE attribute shall not be specified for a coarray that is not a construct entity (16.4) of that construct." That means that VOLATILE XCO is not standard-conforming. However, the constraint apparently does not apply to X, so VOLATILE X is standard- conforming, even though it has essentially the same effect as the forbidden case. Was this constraint intended also to apply to objects with coarray components? Q3. 5.3.19p1 says "A noncoarray object that has the VOLATILE attribute may be associated with an object that does not have the VOLATILE attribute..."; does this apply to objects with a coarray component? Q4. 12.4.2.2p1 says "A procedure other than a statement function shall have an explicit interface if it is referenced and ... (2) the procedure has a dummy argument that ... (c) is a coarray, ...." Is this intended also to apply to objects with coarray components? Q5. Consider: Program volatility Type t Real,Allocatable :: co[:] End Type Type(t) :: x Type(t),Volatile :: y ... Call s1(x) Call s2(x) ! Dummy is volatile, X is not. Call s1(y) ! Y is volatile, dummy is not. Call s2(y) Contains Subroutine s1(a) Type(t) :: a ... End Subroutine Subroutine s2(b) Type(t),Volatile :: b ... End Subroutine End Program 12.5.2.8p1 says "If the dummy argument is a coarray, the corresponding actual argument shall be a coarray and shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." That means that if the program were passing the component CO directly (and the TYPE(T) declarations in S1 and S2 were changed to REAL), the second and third calls would not be conforming because of the VOLATILE mismatch. It seems inconsistent that there is no requirement for VOLATILE to match when there are coarray components, since it has the same effect that X%CO is VOLATILE in S2 but not in the caller, and Y%CO is VOLATILE in the caller but not in S1. Was this requirement also intended to apply to objects with coarray components? Q6. 12.8.1 C1289 says "All dummy arguments of an elemental procedure shall be scalar noncoarray dummy data objects and shall not have the POINTER or ALLOCATABLE attribute." Is this intended also to apply to objects with coarray components? ANSWER: A1. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A2. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A3. No, this does not apply to objects with coarray components, as there is no way of giving the noncoarray parts of the object the VOLATILE attribute without giving the coarray part the VOLATILE attribute, which is forbidden. That the quoted text gives permission for a noncoarray to have the VOLATILE attribute does not override any other requirements in the standard. A4. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. A5. Yes, this requirement was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A6. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. EDITS to 10-007r1: [102:9] 5.3.19 VOLATILE attribute, C560, Between "for a coarray" and "that is accessed by use or" insert ", or a variable with a coarray ultimate component,". {A1.} [102:11] 5.3.19 VOLATILE attribute, C561, Between "for a coarray" and "that is not a construct entity" insert ", or a variable with a coarray ultimate component,". {A2.} [295:4+] 12.5.2.4 Ordinary dummy variables, p18+, add paragraph "If the dummy argument has a coarray ultimate component, the corresponding actual argument shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." {A5.} SUBMITTED BY: Nick Maclaren HISTORY: 14-228 m205 F08/0122 submitted 14-228r1 m205 Revised questions with answers - 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 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following program Program test_spacing Real :: x, y, tiny_spacing, z x = Tiny(x) y = Nearest(x,1.0) tiny_spacing = y - x If (tiny_spacing>0) Then ! Probably IEEE arithmetic with subnormals: ! the spacing y - x is representable. Else ! Probably no subnormals, so y - z is not representable. tiny_spacing = Tiny(x) End If z = Spacing(x) If (z/=tiny_spacing) Then Print *,'FAIL' Else Print *,'ok' End If End Program Furthermore let us assume that the processor supports IEEE arithmetic with subnormals, and that default REAL is IEEE single precision. According to Fortran 95, the result for SPACING is: "If X is not zero, the result has the value b**(e-p), where b, e, and p are as defined in 13.7.1 for the model representation of X, provided this result is within range." therefore the program is expected to print the value "ok". However, according to Fortran 2008, the result for SPACING is: "If X does not have the value zero ..., the result has the value b**max(e-p,emin-1), where ..." Unsurprisingly, e-p is not equal to max(e-p,emin-1) for smallish numbers, and therefore the program would be expected to print the value "FAIL". However, there is no such incompatibility with Fortran 90/95 listed in clause 1, therefore the standard contradicts itself. (The value specified in Fortran 2008 also contradicts the Description of the function which says "Spacing of model numbers (13.4)", since it does not even attempt to return that value.) Is the new specification a deliberate incompatibility or a mistake? DISCUSSION: The description of SPACING was changed in Fortran 2003 by paper 01-361r2 "Comments on Section 13", which contains no justification for this technical change and indeed does not even mention it is a technical change - there is just the bare edit (buried in a huge list of bare edits) with no indication as to why. This would seem to indicate that the technical change is an inadvertent error (presumably the paper simply forgot about subnormal numbers and assumed the new formula gave the same result as the old one). ANSWER: The new wording of SPACING inadvertently changed the return values when IEEE subnormal values were available. An edit is provided to correct this mistake. EDITS to 10-007r1: [389:4-5] 13.7.157 SPACING (X), p5 Result Value, Change "max(e-p,emin-1)" to "e-p" where e and p are in italics. After "that of X" insert ", provided this result is representable; otherwise the result is the same as that of TINY (X).", Change "; if there are two such values" to "If there are two extended model values equally near to X,". This makes the whole paragraph read: If X does not have the value zero and is not an IEEE infinity or NaN, the result has the value b**(e-p), where b, e, and p are as defined in 13.4 for the value nearest to X in the model for real values whose kind type parameter is that of X, provided this result is representable; otherwise the result is the same as that of TINY (X). If there are two extended model values equally near to X, the value of greater absolute value is taken. If X has the value zero, the result is the same as that of TINY (X). If X is an IEEE infinity, the result is an IEEE NaN. If X is an IEEE NaN, the result is that NaN." where "b**(e-p)" represents the typesetting of $b^{e-p}$ and throughout the edits, "b", "e" and "p" are in italics. SUBMITTED BY: Malcolm Cohen HISTORY: 14-263 m205 F08/0123 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following type definitions and object declarations: Type t1 Class(*),Allocatable :: bad End Type Type t2 Type(t1),Allocatable :: oops End Type Type(t1) x[*] Type(t2) y[*] Do the following subroutine calls conform to the Fortran 2008 standard? Call s1(x[2]) Call s2(y[2]) DISCUSSION: If Y[2]%OOPS and Y[2]%OOPS%BAD are both allocated they are subobjects, but only OOPS is a subcomponent of Y[2]. Since OOPS is not polymorphic and BAD is not a subcomponent, this clearly does not violate C617. That seems inconsistent since in both cases a copy of the coindexed variable would necessarily copy the polymorphic BAD component. ANSWER: The intent of C617 was to prevent copying a polymorphic subobject of a coindexed object. Since a subobject is not always a subcomponent, an edit is provided to correct the mistake of using the term "subcomponent" in C617. EDITS to 10-007r1: [6:7+] After the definition of <> (1.3.33.2), insert new term "1.3.33.2a <> nonpointer component, or potential subobject component of a nonpointer component" {We need a new term to describe this properly.} [119:13 C617] Replace "subcomponent" with "potential subobject component". SUBMITTED BY: Van Snyder HISTORY: 14-262 m205 F08/0124 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- 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/0126 TITLE: Can cobounds be referenced in the same type declaration? KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Do the following declarations conform to the Fortran 2008 standard? integer :: A[5,*] = ucobound(a,1) ) integer :: C[5,ucobound(c,1),*] integer :: B[5,*], C[ucobound(b,1),*], D(ucobound(c,1)) ANSWER: 7.1.11p8 says "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the ...." This does not establish an interpretation for any of the declarations. The intent of interpretation F95/000090 was that the third one be allowed, while the first and second be prohibited.0104 Edits are provided to correct this oversight. EDITS to 10-007r1: [10-007r1:151:7-8 7.1.11p8] Replace "a type parameter or an array bound" with "a type parameter, array bound, or cobound" and replace "the type parameter, or array bound" with "the type parameter, array bound, or cobound". SUBMITTED BY: Van Snyder HISTORY: 15-102 m206 F08/0126 submitted 15-102r2 m206 Passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0127 TITLE: May an initial line begin with a semicolon? KEYWORDS: Semicolon DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: The Introduction to ISO/IEC 1539-1:2010, page xvi, states "A line in the program is permitted to begin with a semicolon." Therefore, do the following 3 lines constitute a valid program. ;PROGRAM bad PRINT *,'No' END PROGRAM ANSWER: No, the example is not a valid program as it does not satisfy the syntax rules and constraints. As stated in 3.3.2.5 and 3.3.3.4, a semicolon may be used to terminate a statement. That is not the case in the example, since there is no statement before the semicolon. The semicolon does not appear anywhere else in the Fortran syntax and therefore the example does not conform. An edit is supplied to the Introduction to clarify the change in Fortran 2008. EDITS to 10-007r1: [xvi] Introduction, bullet "Programs and procedures:", Replace "A line in the program is permitted to begin with a semicolon." with "A free form continuation line can begin with zero or more blanks followed by a semicolon." SUBMITTED BY: Malcolm Cohen HISTORY: 15-105 m206 F08/0127 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0128 TITLE: Is recursive USE within a submodule permitted? KEYWORDS: SUBMODULE, USE DEFECT TYPE: Erratum STATUS: J3 considertion 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/0129 TITLE: Is CLASS(type) required to refer to a prior type definition? KEYWORDS: CLASS, type definition DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does the CLASS(T) declaration of X in the following conform? recursive subroutine S ( N, X ) integer :: N class(t), optional :: X type :: T integer :: Q end type T ... ANSWER: Although subclause 4.3.1.3 does not require the in a CLASS specifier to refer to a previously-defined type, it was intended that CLASS declarations with be parallel to TYPE declarations. In a TYPE declaration (4.3.1.2), the specified derived type is required to be previously defined, or accessed by use or host association. Therefore the example ought not to conform. Edits are provided to correct this oversight. EDITS to 10-007r1: [52:6+] 4.3.1.3 CLASS, p1+, insert new paragraph: "Where a data entity other than a component is declared explicitly using the CLASS specifier to be of derived type, the specified derived type shall have been defined previously. If the data entity is a function result, the derived type may be specified in the FUNCTION statement provided the derived type is defined within the body of the function or is accessible there by use or host association. If the derived type is specified in the FUNCTION statement and is defined within the body of the function, it is as if the function result variable were declared with that derived type immediately following its ." {This is essentially identical to 4.3.1.2p1, except for the replacement of "TYPE" with "CLASS" and the addition of "other than a component" (4.3.1.2p1 does not mention components, but it ought to because otherwise it would contradict C440), but that's a different question.} SUBMITTED BY: Van Snyder HISTORY: 15-127 m206 F08/0129 submitted 15-127r1 m206 Passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0130 TITLE: Does coarray allocation sync even with stopped images? KEYWORDS: ALLOCATE, DEALLOCATE, coarray, synchronization, stopped DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Example 1: Consider the trivial program Program m206c7e1 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Stop 'Image 1 is now stopping' End If Allocate(x(100)[*],Stat=stat) ! If (me==2) Print *,'Arrived' !***A ! If (stat==0) Error Stop 'INCONCEIVABLE' If (stat/=Stat_Stopped_Image) Error Stop 'Bad STAT' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***B End Do End Program Q1. On images other than image 1, does execution ever reach the statement with comment "!***A"? 6.7.1.2 Execution of an ALLOCATE statement, p4 says "When an ALLOCATE statement is executed for which an allocate-object is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the statement is delayed until all other images have executed the same statement the same number of times." The second sentence seems to say that execution on images>1 is delayed forever, since image 1 will never execute that ALLOCATE statement. Example 2: Consider the program Program m206c7e2 Use Iso_Fortran_Env Implicit None Real(real32), Allocatable :: x(:,:,:,:)[:],y(:,:,:,:) Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Allocate(y(1000,1000,1000,1000)) !***C End If Allocate(x(1000,1000,1000,1000)[*],Stat=stat) !***D ! If (me==1 .And. stat==0) Error Stop 'Inconceivable!' ! If (stat==0) Print *, 'ALLOCATE ok on image', me !***E ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***F End Do End Program For purposes of discussion, let us assume that each image has 6 Terabytes of memory available to it for dynamic allocation. The ALLOCATE statement commented "!***C" will allocate 4 terabytes of memory on image 1. Execution of the ALLOCATE statement commented "!***D" will attempt to allocate 4 terabytes on each image; this will fail on image 1 as there is insufficient memory available, but could succeed on other images. Q2. Is the success of an ALLOCATE statement the same on every image, or may it fail on some images and succeed on others? That is, might the statement commented "!***E" execute the PRINT on some images (but not all). Q2 continuation: If the answer is that the ALLOCATE must either succeed or fail on all images, can the STAT= value differ by image (for example, might a processor return a different STAT= code for "no memory on this image" and "no memory on some other image"). Example 3: Consider the program Program m206c7e3 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Call do_something_that_takes_a_very_long_time End If Allocate(x(100)[*],Stat=stat) !***G ! If (stat==0) Error Stop 'INCONCEIVABLE' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***H End Do End Program Let us imagine that the processor operates some form of "timeout" mechanism, for example, if an image fails to reach a synchronization point within an hour of the first image reaching that statement, an error is returned. (If the slow image subsequently reaches that statement, one might conjecture that it will also get an error, but probably STAT_YOU_ARE_TOO_SLOW rather than STAT_TIMEOUT). In the example above, let us assume that the ALLOCATE statement commented "!***G" fails, e.g. with a timeout error as we imagined above. Q3. After resolution of question 1, which images are synchronized after execution of an ALLOCATE statement that fails? That is, is execution of the statements commented "!***B" (in Q1), "!***F" (in Q2) and "!***H" (above) permitted, or are they impermissible references to variables in unordered segments? In the case of "!***B", one might conjecture that all the non-stopped images are synchronized. In the case of "!***F" the text of the standard appears to require that image 1 has to wait for all the other images, but it might equally be conjectured that that is a mistake and that since it knows straightaway that it cannot satisfy the memory allocation it should be allowed to return straightaway without synchronizing, i.e. the "!***F" is not allowed. In the case of "!***H", image 1 has still not even reached the ALLOCATE statement (after an hour of the others waiting), so it would seem that it is impossible for it to have synchronized as required by the standard, and therefore that (for i==1 at least) the execution of "!***H" is not allowed. Q4. When allocation of a coarray is involved, and an error occurs (e.g. as in the examples above, plus other cases), under what situations does the coarray in question become allocated? In particular, can a coarray be allocated on some images but not others? If the answer is that the coarray never becomes allocated, that means that in the case of a stopped image, the remaining images cannot allocate any coarray. Q5. Do the answers to Q1-Q4 also apply to DEALLOCATE statements? ANSWER: A1. In the case of stopped images, the requirement in 6.7.1.2 was only intended to apply to the non-stopped images. An edit is provided to correct this mistake. A2. Allocation of a coarray was intended only to succeed if it succeeds on all images. An edit is provided to add this missing requirement. (A2 continuation) There was not intended to be any requirement that a nonzero STAT= value be the same on each image. No edit is provided to add such a requirement. A3. After execution of an ALLOCATE statement that returns an error other than STAT_STOPPED_IMAGE, there was not intended to be any requirement for synchronization. An edit is provided to correct this mistake. A4. The coarray can become allocated on an image if and only if it can become allocated on all other images. An edit is provided to add this requirement. The consequence in the case of a stopped image is indeed that no image can subsequently change the allocation status of any coarray. A5. Yes, the answers also apply to DEALLOCATE statements. Corresponding edits are supplied. EDITS to 10-007r1: [128:15-17] 6.7.1.2 Execution of an ALLOCATE statement, p4, Change "On each image" to "If no error condition other than STAT_STOPPED_IMAGE occurs" Change "all other images" to "all non-stopped images". {A1,A3: Synchronization only applies to successful allocations and to allocations that fail only due to STAT_STOPPED_IMAGE.} Append a sentence requiring allocation success consistency for coarrays, making the whole paragraph read: "When an ALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition other than STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2) following the statement is delayed until all non-stopped images have executed the same statement the same number of times. The coarray shall not become allocated on an image unless it is successfully allocated on all non-stopped images." {A2,A4: Last sentence is the consistency requirement.} [131:16-19] 6.7.3.2 Deallocation of allocatable variables, p11, Change "On each image" to "If no error condition other than STAT_STOPPED_IMAGE occurs" Change "all other images" to "all non-stopped images". Append a sentence requiring deallocation consistency, making the whole paragraph read: "When a DEALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition other than STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2) following the statement is delayed until all non-stopped images have executed the same statement the same number of times. If the coarray is a dummy argument, its ultimate argument (12.5.2.3) shall be the same coarray on every image. The coarray shall not become deallocated on an image unless it is successfully deallocated on all non-stopped images." SUBMITTED BY: Malcolm Cohen HISTORY: 15-133 m206 F08/0130 submitted 15-133r1 m206 Passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2094 m209 Modified by 1st Corrigendum 4 ballot N2088/89/90 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0131 TITLE: Are the changes to C_LOC in the 2010 revision intentional? KEYWORDS: C_LOC, interoperability DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: The description of C_LOC in the intrinsic module ISO_C_BINDING permits noninteroperable array arguments that are contiguous, provided the type and kind are interoperable. This was not permitted by the previous revision of ISO/IEC 1539-1, which required all type parameters to be interoperable (and only exempted allocatable arrays from the "interoperable variable" requirement); however this is not listed in the Introduction as a change. For example, each of the following is apparently permitted as arguments to C_LOC by the requirements in Fortran 2008 but not in Fortran 2003: CHARACTER(13,C_char),TARGET :: x(100) CHARACTER(14,C_char),TARGET :: y REAL(C_float),CONTIGUOUS :: dummy1(:) INTEGER(C_int),CONTIGUOUS,POINTER :: z(:) (the CONTIGUOUS attribute does not exist in Fortran 2003). and also REAL(C_float) :: dummy2(:) INTEGER(C_int),POINTER :: z2(:) when dummy1 is argument-associated with a contiguous array, and z2 is pointer-associated with a contiguous array. Was this change intended? ANSWER: Yes, this change was intentional. An edit is provided to add this to the Introduction. EDITS to 10-007r1: [xvi] Introduction, "Intrinsic modules" bullet point, Before "The function C_SIZEOF" insert new sentence "A contiguous array variable that is not interoperable but which has interoperable type and kind type parameter (if any), and a scalar character variable with length>1 and kind C_CHAR, can be used as the argument of the function C_LOC in the intrinsic module ISO_C_BINDING, provided the variable has the POINTER or TARGET attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 15-132 m206 F08/0131 submitted 15-132r1 m206 Revised edits 15-132r2 m206 Revised question - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0132 TITLE: Can a procedure pointer be declared with an interface block? KEYWORDS: procedure pointer, interface block DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the program PROGRAM c11 INTERFACE REAL FUNCTION F() END FUNCTION END INTERFACE POINTER F EXTERNAL G F => G PRINT *,F() END PROGRAM REAL FUNCTION G() G = 206 END FUNCTION According to 12.4.3.2 paragraph 5, F is an external procedure (and seems to be missing). There is no mention of the possibility of a procedure pointer in the subclause on interface blocks. Is this intended to be standard-conforming? ANSWER: Yes, this is intended to be standard-conforming. An edit is supplied to correct the mistake in 12.4.3.2. EDITS to 10-007r1: [281:26] In 12.4.3.2 Interface block, paragraph 5, After "specific interface for an external procedure" change "or a dummy procedure" to ", dummy procedure, or procedure pointer". {Add procedure pointer for the list of things this can declare.} [281:25-28] Same paragraph, After "interface body, the procedure is a dummy procedure" change "; otherwise" to ". If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure or procedure pointer". {Correct how we establish what it is.} This makes that whole paragraph read: An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an explicit specific interface for an external procedure, dummy procedure, or procedure pointer. If the name of the declared procedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a dummy procedure. If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure or procedure pointer, it is an external procedure. {Note careful wording to avoid saying that a dummy procedure is not a procedure pointer, since a dummy procedure pointer is indeed both a dummy procedure and a procedure pointer.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-136 m206 F08/0132 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0133 TITLE: Is unallocated actual associated with nonallocatable dummy OK? KEYWORDS: OPTIONAL, ALLOCATABLE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does the following program conform to the 2008 standard? program P integer, allocatable :: I(:) call s ( i ) contains subroutine S ( A ) integer, intent(in), optional :: A(:) if ( present(a) ) then print *, 'A = ', a else print *, 'A is not present' end if end subroutine S end program P Subclause 6.7.1.3 says, concerning an unallocated allocatable variable, "It shall not be supplied as an actual argument corresponding to a nonallocatable dummy argument, except to certain intrinsic inquiry functions." On the other hand, subclause 12.5.2.12 says a dummy argument "is not present if the dummy argument ... does not have the ALLOCATABLE ... attribute, and corresponds to an actual argument that ... has the ALLOCATABLE attribute and is not allocated...." ANSWER: The intent was that the program conforms, and prints "A is not present", as specified by subclause 12.5.2.12. Edits are provided to correct this mistake. EDITS to 10-007r1: [10-007r1:129:8 6.7.1.3 p1, second item in bulleted list] Insert "nonoptional" before "nonallocatable". SUBMITTED BY: Van Snyder HISTORY: 15-141 m206 F08/0133 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0134 TITLE: in an image control statement KEYWORDS: stat=, image control statement DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Was it intended to allow or in an image control statement to be coindexed? For example, was it intended that this statement SYNC IMAGES(1, stat = is[2]) be allowed? It seems undesirable to involve image 2 when synchronizing the executing image with image 1. ANSWER: No, it was not intended to allow the or in an image control statement to be coindexed. An edit is provided to correct this oversight. EDITS to 10-007r1: [190:5+] Add constraint "C851a (R859) A or in a shall not be a coindexed object. SUBMITTED BY: John Reid HISTORY: 15-144 m206 F08/0134 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0135 TITLE: Vector subscripted actual makes VALUE dummy undefinable? KEYWORDS: VALUE, definable, vector subscript DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: 12.5.2.4p18 [295:3-4] says "If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes." This would seem to be a strange requirement when the dummy argument has the VALUE attribute (and so is not argument-associated with the actual argument anyway). Consider program P1 real :: X(3) call S1 ( X ( [ 1, 3, 2 ] ) ) contains subroutine S1 ( A ) real, value :: A(:) A = 3 print *, A end subroutine end program and PROGRAM p2 REAL :: x(3) = [ 10,20,30 ] OPEN(10,ASYNCHRONOUS='YES',FORM='UNFORMATTED') CALL s2( x( [ 1,2,2,1 ] ) ) CONTAINS SUBROUTINE s2(a2) REAL,VALUE,ASYNCHRONOUS :: a2(:) READ(10,ASYNCHRONOUS='YES') a2 PRINT *,'reading...' WAIT(10) PRINT *,a2 END SUBROUTINE END PROGRAM Are these two programs standard-conforming? In particular, is the assignment to A permitted in S1, and is the dummy argument a2 permitted to have the ASYNCHRONOUS attribute in s2. ANSWER: These two programs were intended to be standard-conforming. Subclause 12.5.2.3 states that a VALUE dummy argument is associated with a definable data object and not with the actual argument. An edit is supplied to correct this mistake. EDITS to 10-007r1: [295:3] 12.5.2.4 Ordinary dummy variables, p18, after applying the changes in F2008 Corrigendum 1, between "is nonelemental" and "and the actual argument", insert ", the dummy argument does not have the VALUE attribute,". This makes that whole sentence read "If the procedure is nonelemental, the dummy argument does not have the VALUE attribute, and the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes." SUBMITTED BY: Van Snyder HISTORY: 15-148 m206 F08/0135 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0136 TITLE: Argument correspondence with VALUE and ASYNCHRONOUS KEYWORDS: VALUE, ASYNCHRONOUS, coindexed, contiguous DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following three programs and discussions: program P1 real, asynchronous :: X[*] call S1 ( X [ 1 ] ) contains subroutine S1 ( A ) real, value, asynchronous :: A a = 3 end subroutine S1 end program P1 Program P1 appears to violate C1238 which says "An actual argument that is a coindexed object with the ASYNCHRONOUS or VOLATILE attribute shall not correspond to a dummy argument that has either the ASYNCHRONOUS or VOLATILE attribute." but the dummy argument is not associated with the actual argument so it is unclear why that should be the case. program P2 real, asynchronous :: X(3) call S2A ( X ) contains subroutine S2A ( A ) real, asynchronous :: A(:) call S2B ( A(1:3) ) end subroutine S2A subroutine S2B ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S2B end program P2 This appears to violate C1239 which says "If an actual argument is a nonpointer array that has the ASYNCHRONOUS or VOLATILE attribute but is not simply contiguous (6.5.4), and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS attribute." but again, it is unclear why that should matter for a VALUE dummy argument. program P3 real, target :: X(3) real, pointer, asynchronous :: Y(:) y => x call S3 ( y ) contains subroutine S3 ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S3 end program P3 This program appears to violate C1240 which says "If an actual argument is an array pointer that has the ASYNCHRONOUS or VOLATILE attribute but does not have the CONTIGUOUS attribute, and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an array pointer or an assumed-shape array that does not have the CONTIGUOUS attribute." but it is unclear why this should matter for a VALUE dummy argument. Are those programs intended to be standard-conforming? ANSWER: Yes, all those programs were intended to be standard-conforming. There is no need for those constraints to apply to dummy arguments with the VALUE attribute, because a VALUE dummy argument is not associated with the actual argument but with an anonymous definable data object. Edits are supplied to correct the mistakes in the constraints. EDITS to 10-007r1: [295:6] 12.5.2.4 Ordinary dummy arguments, C1238, Between "VOLATILE attribute" and "." insert ", unless the dummy argument has the VALUE attribute". [295:9] Same subclause, C1239, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute". [295:13] Same subclause, C1240, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute". SUBMITTED BY: Van Snyder HISTORY: 15-149 m206 F08/0136 submitted 15-149r4 m206 Fix answer and typos - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0137 TITLE: Result of TRANSFER when MOLD is an array with element size zero KEYWORDS: TRANSFER, zero-sized scalar DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following examples: Example 1: CHARACTER(0),PARAMETER :: nothing1(100) = '' PRINT *,SIZE(TRANSFER(111014,nothing1)) Example 2: TYPE empty END TYPE ! When the physical representation of empty() has size zero; ! this is not required but does seem to be permitted. TYPE(empty),PARAMETER :: nothing2(1) = empty() PRINT *,SIZE(TRANSFER(111014,nothing2)) Example 3: TYPE nonempty REAL c(0) END TYPE TYPE(nonempty),PARAMETER :: nothing3(0) = nonempty(0.0) PRINT *,SIZE(TRANSFER(111014,nothing3)) According to Fortran 2008, 13.7.168, the result of TRANSFER in this case is an array of rank one whose "size is as small as possible such that its physical representation is not shorter than that of SOURCE". However, the size of a zero-length character is zero and the size of the above derived types may be zero, no matter how many array elements there are, so these examples do not seem to be well-defined. Also consider the following examples, with nothing1 defined as in example 1. Example 4: CHARACTER(0) :: source1 = '' PRINT *,SIZE(TRANSFER(source1,nothing1)) Example 5: CHARACTER(999) :: source2(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source2,nothing1)) In these cases the physical representation of an element of MOLD has size zero, but then so does the physical representation of the SOURCE argument. According to the quoted text, that would mean that TRANSFER should return a zero-sized array, i.e. the examples will print zero. Example 6: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source3(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source3,maybe_nothing)) Example 7: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source4(10) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source4,maybe_nothing)) In these examples, the physical representation of MOLD is not known at compile time, but depends on the length of the dummy argument. Using the analysis above, example 6 would seem to be conforming (and print zero), while example 7 would seem to be conforming if and only if the length of maybe_nothing is nonzero at execution time. Which of the examples are conforming? If any of examples 1-3 are conforming, what value is printed? ANSWER: Example 1 is not conforming, and if the derived types have size zero in examples 2 and 3, those examples are also not conforming, as no interpretation is established for them. An edit is provided to clarify that they are not valid. Examples 4-6 are conforming, and the value zero is printed. Example 7 is conforming if and only if the length of maybe_nothing is not zero. The same edit clarifies that the zero-length case is not valid. EDITS to 10-007r1: [393:18] 13.7.168 TRANSFER, p3 Arguments, MOLD, append "If the storage size of SOURCE is greater than zero and MOLD is an array, a scalar with the type and type parameters of MOLD shall not have a storage size equal to zero.". {It is ok for MOLD itself to have storage size zero, in the case where MOLD is a zero-sized array but the storage size of a scalar with its type and type parameters would be greater than zero.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-152 m206 F08/0137 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0138 TITLE: Type extension in submodules KEYWORDS: submodules, deferred type-bound procedures DEFECT TYPE: Clarification STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following code: module mod_a implicit none type, abstract :: t_a contains procedure(p_a), deferred :: p end type t_a abstract interface subroutine p_a(this, q) import :: t_a class(t_a), intent(inout) :: this class(*), intent(in) :: q end subroutine end interface end module mod_a submodule(mod_a) imp_p_a type, extends(t_a) :: t_imp real :: b contains procedure :: p => psub ! (A) end type t_imp contains subroutine psub(this, q) class(t_imp), intent(inout) :: this class(*), intent(in) :: q ... ! don't care end subroutine psub end submodule imp_p_a Constraint C465 in 10-007r1 reads "C465 (R448) The procedure-name shall be the name of an accessible module procedure or an external procedure that has an explicit interface." Therefore it would appear that statement (A) above is not standard conforming since PSUB is not the name of a module procedure. Q1. Is this correct? If so, extension of a derived type with a deferred type-bound procedure cannot be done within the specification part of a submodule. Q2. Was this intended? ANSWER: A1. No, this is not correct. A module procedure is a procedure that is defined by a module subprogram (1.3.112.4). A submodule program unit contains a module-subprogram-part (R1116), and this contains a (possibly-empty) sequence of module-subprogram's (R1107). Therefore, PSUB is defined by a module subprogram and is therefore a module procedure. Therefore, the statement that is commented "(A)" is standard-conforming. A2. Moot. EDITS to 10-007r1: None. SUBMITTED BY: R. Bader HISTORY: 15-160 m207 F08/0138 Submitted 15-160r1 m207 Revised 15-160r2 m207 Revised example passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 --------------------------------------------------------------------- NUMBER: F08/0139 TITLE: Is the name of an external procedure that has a binding label a local identifier? KEYWORDS: binding label, local identifier DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the program fragment containing the external subprograms: Subroutine s() Bind(C,Name='Hello') Print *,'Hello' End Subroutine Subroutine s() Bind(C,Name='World') Print *,'World' End Subroutine This does not conform to Fortran 2003, and is not listed as an extension in the Introduction to Fortran 2008, but the rules for global names seem to indicate that this is now conforming. Is this extension deliberate? ANSWER: Yes, this was a deliberate change to the Fortran standard. An edit is provided to mention this in the Introduction. EDITS to 10-007r1: [xvi] Introduction, paragraph 2, bullet "Programs and procedures", append to paragraph "The name of an external procedure that has a binding label is a local identifier and not a global identifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 15-177 m207 F08/0139 submitted - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0140 TITLE: Assign to deferred-length coindexed character variable KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Q1. Consider the program: Program p1 Type t Character(:), Allocatable :: C End Type Type(t) x[*] Allocate ( Character(42) :: x%c ) Sync All If (This_Image()==1) x[2]%c = 'stuff' End Program Is the assignment permitted? Q2. Consider Program p2 Type t Character(:), Pointer :: C End Type Type(t) x[*] Allocate ( Character(42) :: x%c ) Sync All If (This_Image()==1) x[2]%c = 'stuff' End Program Is the assignment permitted? ANSWER: A1. This is not permitted, as it violates the requirement in 7.2.1.2 Intrinsic assignment statement, paragraph 2, which states that if the variable (in an intrinsic assignment statement) is coindexed, its deferred length type parameters shall be the same as the corresponding type parameters of the expression. There is a grammatical error in this requirement; an edit is supplied to correct the grammatical error. A2. This was intended to be permitted, but was inadvertently caught in the prohibition that was intended to apply only to allocatable variables. An edit is supplied to correct this error. EDITS to 10-007r1: [153:25] 7.2.1.2p2, after "coindexed object,", delete "the variable", [153:26] before "shall not be" insert "the variable", [153:27] before "shall not have" insert "the variable", [153:28] after "deferred length type parameter" insert "of the variable" making the whole paragraph read "If is a coindexed object, - the variable shall not be polymorphic, - the variable shall not have an allocatable ultimate component, and - each deferred length type parameter of the variable shall have the same value as the corresponding type parameter of .". SUBMITTED BY: Van Snyder HISTORY: 15-161 m207 F08/0140 submitted 15-161r1 m207 Revised question and answers 15-161r2 m207 Passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0141 TITLE: Can a statement function have a variable-length PDT result? KEYWORDS: Statement function, parameterized derived type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider MODULE m207c006 TYPE string(n) INTEGER,LEN :: n CHARACTER(n) :: v END TYPE END MODULE PROGRAM test USE m207c006 CALL s(3) CALL s(7) CONTAINS SUBROUTINE s(n) TYPE(string(n)) sf TYPE(string(n)) var(3) sf(nn) = var(nn) var(1) = string(n)('123456789') var(2) = string(n)('abcdefgh') PRINT *,sf(1),sf(2) END SUBROUTINE END PROGRAM If this is conforming, it would appear that the output ought to be 123abc 1234567abcdefg However, for the following reasons, perhaps this is not intended to be conforming. (1) A statement function of type character is required to have a constant length type parameter. There is no such requirement on a statement function of parameterized derived type. This seems inconsistent, since one can wrap a variable-length character in a parameterized derived type. (2) A statement function is not permitted to invoke a nonintrinsic function that requires an explicit interface (and having a PDT result requires an explicit interface), nor is it permitted to contain a structure constructor. This would seem to render such a statement function almost completely useless, since all it can do is to choose between PDT constants or variables, or use an intrinsic function such as TRANSFER to construct the result. (3) Statement functions were declared to be obsolescent long before the addition of parameterized derived types to the standard. It has been general policy not to "improve" obsolescent features. This would seem to indicate that statement functions were not intended to be capable of having parameterized derived type in the first place. Q1. Are statement functions of parameterized derived type intended to be conforming? Q2. If so, are statement functions of parameterized derived type with nonconstant length type parameters intended to be conforming? Q3. If so, is the expected output from the example program above as described? ANSWER: A1. No, statement functions were not intended to be permitted to be of parameterized derived type. The exception for statement functions from the explicit interface requirements was overlooked. An edit is provided to prohibit these. A2, A3. Moot. EDITS to 10-007r1: [24:11+] 1.6.2 Fortran 2003 compatibility, insert new paragraph "Fortran 2003 permitted a statement function to be of parameterized derived type; this part of ISO/IEC 1539-1 does not permit that." {Previous corrigenda have already inserted incompatibility paragraphs.} [311:34+] 12.6.4 Statement function, after C1275, insert constraint "C1275a A statement function shall not be of a parameterized derived type." SUBMITTED BY: Malcolm Cohen HISTORY: 15-179 m207 F08/0141 submitted 15-179r1 m207 Revised edits - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0142 TITLE: Is useless module extension permitted? KEYWORDS: SUBMODULE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: If a module declares no separate module procedure, it cannot have a useful submodule as such a submodule has nothing to provide. Its module procedures and variables cannot be referenced by any program. Should useless extension have been prohibited? ANSWER: Yes. Permitting such extension would require the implementation to export the private details of a module merely for the purpose of compiling a useless submodule. An edit is provided to require the ancestor of a submodule to have declared a separate module procedure. EDITS to 10-007r1: [275:18] 11.2.3 Submodules, C1113, After "shall be the name of a nonintrinsic module" insert "that declares a separate module procedure". SUBMITTED BY: Daniel Chen HISTORY: 15-209 m207 F08/0142 submitted - passed by J3 meeting N2093 m209 Passed by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0143 TITLE: May a pure procedure have an INTENT(OUT) polymorphic component? KEYWORDS: PURE, INTENT(OUT), polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider: Type t Class(*),Allocatable :: c End Type ... Pure Subroutine zap(x) Type(t),Intent(Out) :: x x%c = 'I wonder if that invoked an impure procedure?' End Subroutine Is this program standard-conforming? ANSWER: No, this is not standard-conforming. Corrigendum 1 of Fortran 2008 added the constraint "C1284a A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure." The type declaration statement with INTENT(OUT) causes the deallocation of the polymorphic component X%C, and is therefore not allowed. However, this is difficult to understand, so a clarifying edit is provided. EDITS to 10-007r1: In Clause 12.7, para, 2, in 10-007r1 [312:23+], in the constraint added by Corrigendum 1, "C1278a An INTENT (OUT) dummy argument of a pure procedure shall not be polymorphic." after the word "polymorphic" insert "or have a polymorphic allocatable ultimate component". SUBMITTED BY: Malcolm Cohen HISTORY: 15-211 m207 F08/0143 submitted - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0144 TITLE: Is ADVANCE= allowed during execution of DO CONCURRENT? KEYWORDS: nonadvancing I/O, DO CONCURRENT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider program P integer :: I do concurrent ( I = 1:10 ) write ( *, '(I5)', advance='NO' ) I end do write ( *, * ) end program P Q1. Is this conforming and if so, what output is produced? program Q integer :: I logical :: L(10) = .FALSE. real :: X(10) = 0 do concurrent ( I = 1:10 ) if ( mod(i,2) == 0 ) then read ( *, '(g15.6)', advance='no' ) X(I) else read ( *, '(l3)', advance='no' ) L(I) end if end do print *, X, L end program Q2. Is this conforming and what kind of output would be expected? ANSWER: No, these programs are not conforming as no interpretation is established for them. It was intended that the ADVANCE= specifier not be permitted within a DO CONCURRENT construct. An edit is provided to address this oversight. EDITS to 10-007r1: [10-007r1:178:16+ 8.1.6.7p1] after the fourth bullet point, add new bullet point: " o A DO CONCURRENT construct shall not contain an input/output statement that has an ADVANCE= specifier." SUBMITTED BY: Van Snyder HISTORY: 15-213 m207 F08/0144 submitted 15-213r1 m207 Option 2 selected, edit revised - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0145 TITLE: Can initial-data-target be coindexed? KEYWORDS: initialization, pointers, coarrays DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: In pointer assignment, the standard is quite clear that data-target cannot be coindexed: C725 (R737) A data-target shall not be a coindexed object. And there are a couple of notes related to this: NOTE 7.45 A data pointer and its target are always on the same image. A coarray may be of a derived type with pointer or allocatable subcomponents. For example, if PTR is a pointer component, Z[P]%PTR is a reference to the target of component PTR of Z on image P. This target is on image P and its association with Z[P]%PTR must have been established by the execution of an ALLOCATE statement or a pointer assignment on image P. NOTE 7.46 A pointer assignment statement is not permitted to involve a coindexed pointer or target, see C723 and C725. This prevents a pointer assignment statement from associating a pointer with a target on another image. If such an association would otherwise be implied, the association status of the pointer becomes undefined. For example, a derived-type intrinsic assignment where the variable and expr are on different images and the variable has an ultimate pointer component. Fortran 2008 added the ability to specify an initial-data-target in pointer initialization: R505 initialization is = constant-expr or => null-init or => initial-data-target R506 null-init is function-reference C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = appears in initialization, the entity shall not have the POINTER attribute. C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it (4.5.4.6). Initial-data-target is defined in 4.5.4.6 and the only relevant constraint for it is: C461 (R443) The designator shall designate a nonallocatable variable that has the TARGET and SAVE attributes and does not have a vector subscript. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be a constant expression. The definition of "data-pointer-initialization compatible" is: "A pointer variable or component is data-pointer-initialization compatible with a target if the pointer is type compatible with the target, they have the same rank, all nondeferred type parameters of the pointer have the same values as the corresponding type parameters of the target, and the target is contiguous if the pointer has the CONTIGUOUS attribute." Given this, is initializing a pointer to a coindexed object permitted? For example: program test integer, save, target :: C[*] integer, pointer :: P => C[3] ! Permitted? end While ordinary pointer assignment to a coindexed object is prohibited by C725, there is no corresponding constraint prohibiting such association by way of data pointer initialization. Note that 16.5.2.5p1(2) says that pointer-assigning to a target on a different image causes the pointer to become undefined. Since the initialization occurs on all images, and it's not possible to restrict the target to only the same image, the effect would be to make a program that does this nonconforming. ANSWER: No, this was not intended to be permitted. A clarifying edit is provided. EDITS to 10-007r1: [70:3] 4.5.4.6 In the first sentence of C461, insert ", noncoindexed" after "nonallocatable" so that the sentence reads: C461 (R443) The designator shall designate a nonallocatable, noncoindexed variable that has the TARGET and SAVE attributes and does not have a vector subscript. SUBMITTED BY: Steve Lionel HISTORY: 15-216 m208 F08/0145 submitted - passed by J3 meeting 16-103 m209 Passed by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- 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/0147 TITLE: Is generic resolution of elemental assignment done at runtime? KEYWORDS: Type-bound defined assignment, Allocatable DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Module da_module Type t Real c End Type Interface Assignment(=) Module Procedure edasgn End Interface Contains Elemental Subroutine edasgn(a,b) Type(t),Intent(Out) :: a Type(t),Intent(In) :: b a%c = -b%c End Subroutine End Module Program edatest Call test(10,10,13) Contains Subroutine test(n,n2,m) Use da_module Type(t) :: x(n),z(m) Type(t),Allocatable :: y(:) x%c = [ (i,i=1,n) ] z%c = [ (i,i=1,m) ] Allocate(y(n2),Source=t(0)) y = x ! A Print 1,y 1 Format(*(1X,F0.1,:)) y = z ! B Print 1,y End Subroutine End Program According to 7.2.1.2 Intrinsic assignment statement, an assignment statement is an intrinsic assignment statement if (and only if) it is not a defined assignment statement. According to 7.2.1.4 Defined assignment statement, a defined assignment statement needs to have a subroutine that defines the assignment "x1 = x2". For elemental subroutines (item (5)(b)), that is true only if "x1 and x2 are conformable" which when x1 and x2 are both arrays, means "has the same shape". For the example above, in the assignment marked (A), x and y will be conformable (as both n and n2 are equal to 10), making that a defined assignment, thus the PRINT statement after it would print -1.0 -2.0 -3.0 -4.0 -5.0 -6.0 -7.0 -8.0 -9.0 -10.0 while in the assignment statement marked (B), y and z will not be conformable (n2 being 10 and m being 13), making it an intrinsic assignment. In this case, because Y is allocatable it will be reallocated, and so the output from the second PRINT statement would be 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 However, this would seem to violate the fundamental principle that generic references are resolvable at compile time. It would also seem to be nearly useless since if the variable is not allocatable the shapes are required to conform anyway. Is this feature intended to work like this? ANSWER: No, this was a mistake. Edits are provided to remove the runtime generic resolution. After the edits: 1) The assignment A is defined assignment and is conforming (from first edit). 2) The assignment B is defined assignment but is not standard conforming, since the shapes differ (from second edit). 3) For a defined assignment statement, auto-reallocation of allocatables does not occur, as that is only done by an intrinsic assignment statement. EDITS to 10-007r1: [24:11+] 1.6.2 Fortran 2003 compatibility, insert new incompatibility "Fortran 2003 interpreted assignment to an allocatable variable from a nonconformable array as intrinsic assignment, even when an elemental defined assignment was in scope; this part of ISO/IEC 1539 does not permit assignment from a nonconformable array in this context.". {The unintended extension is weird and violates our own principles, but is not in itself contradictory or ambiguous so this is an incompatibility.} [157:14] 7.2.1.4 Defined assignment statement, p2, item (5)(b), Change "$x_1$ and $x_2$ are conformable" to "$x_2$ is scalar or has the same rank as $x_1$". {$x_1$ is TeX for italics x subscript 1.} [157:16] Same subclause, p3, append new sentence "If the subroutine is elemental, $x_2$ shall have the same shape as $x_1$." {Retain conformability as a normal requirement instead of as a condition.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-219 m208 F08/0147 submitted - passed by J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed as amended by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0148 TITLE: Pointer subobject in structure constructor in pure procedure KEYWORDS: pointer subobject, structure constructor, pure procedure DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the module program P type :: T1 integer, pointer :: P1 end type T1 type :: T2 type(t1) :: P2 end type T2 type(t1), target :: V1 allocate ( V1%p1, source = 42 ) contains pure subroutine S ( ) type(t2) :: A 1 a = t2(v1) a%p2%p1 = a%p2%p1 + 1 end subroutine S end program P Item (3) in the list in constraint C1283 in subclause 12.7 prohibits an object that is accessed by host or use association (and other categories) to be the in a structure constructor that corresponds to a component that has the POINTER attribute. It is silent concerning type constructors for types that have potential subobject components with the POINTER attribute. Is the statement labeled 1 permitted? If so, was that intended? ANSWER: The statement labeled 1 was inadvertently allowed because V1 corresponds to a component of the structure constructor for type T2 that does not have the POINTER attribute. An edit is provided to correct this mistake. EDITS to 10-007r1: [312:35 12.7p2 C1283(3)] Replace this list item by "(3) as the corresponding to a component in a if the component has the POINTER attribute or has a pointer component at any level of component selection," SUBMITTED BY: Van Snyder HISTORY: 15-249 m208 F08/0148 submitted 15-249r1 m208 fix typos - passed J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------