J3/15-006r2 To: J3 From: Stan Whitlock Subject: Outstanding Fortran Interpretations for m208 Date: 2015 Oct 04 Outstanding Fortran Interpretations, October 4, 2015 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 > m206: WG5 ballot #8: N2042/43/47 - 10 of 10 passed by WG5 ballot > m206: 14-279/15-121 LB #32 - 12 of 12 passed by J3 letter ballot > m206: 12 of 12 new interps passed by J3 meeting > m207: 15-159/15-187 LB #33: 11 of 12 passed by J3 letter ballot + remove interp text for interps in F2008 Corrigendum 3 + m207: WG5 ballot #9: N2061/62/80 - 23 of 23 passed by WG5 ballot + m207: 8 of 8 interps passed by J3 meeting = 33 passed WG5, 0 passed J3 LB, 8 passed J3 meeting, 16 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 {if S = C* | T*, then done is assumed} * == active Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot X Excluded for the reasons given C1 In F2008 Corrigendum 1 C2 In F2008 Corrigendum 2 C3 In F2008 Corrigendum 3 N S T number title - - - ------ ----- * 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 * P E 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? * P 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? * W I F08/0099 VOLATILE in specification expressions * W E F08/0100 IMPORT statement and prior explicit declaration * W E F08/0101 NAMELIST and multiple occurrences of a variable * W E F08/0102 MERGE and polymorphism * W E F08/0103 Pointers to internal procedures with different host instances * W E F08/0104 IEEE Inquiry Functions * W I F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? * W E F08/0106 MOVE_ALLOC for a remote array * P E F08/0107 LOCK_TYPE, ultimate components, subcomponents, and coarrays * W I F08/0108 ultimate components and coarrays * P E F08/0109 LOCK_TYPE and unlimited polymorphic * W E F08/0110 Interdependence of specifier values in input/output statements * P E F08/0111 Undefinition * W E F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE * W E F08/0113 Specifiers in image control statements * P E F08/0114 Can LOCK_TYPE components have the POINTER attribute? * W E F08/0115 ASYNCHRONOUS and argument passing * W E F08/0116 Interoperable procedures * W E F08/0117 TARGET and coindexed arguments * W E F08/0118 Subobject of variable in variable definition context * W E F08/0119 Branching to END BLOCK and END CRITICAL * W E F08/0120 Is the name of a procedure pointer a local identifier? * W E F08/0121 Add to introduction defined operations in specification exprs * W E F08/0122 Types with coarray components * W E F08/0123 SPACING intrinsic * W E F08/0124 Coindexed object with polymorphic subcomponent * P E F08/0125 Definition of objects of type LOCK_TYPE with pointer subobjects * W E F08/0126 Can cobounds be referenced in the same type declaration? * W E F08/0127 May an initial line begin with a semicolon? * M E F08/0128 Is recursive USE within a submodule permitted? * W E F08/0129 Is CLASS(type) required to refer to a prior type definition? * W E F08/0130 Does coarray allocation sync even with stopped images? * W E F08/0131 Are the changes to C_LOC in the 2010 revision intentional? * W E F08/0132 Can a procedure pointer be declared with an interface block? * W E F08/0133 Is unallocated actual associated with nonallocatable dummy OK? * W E F08/0134 in an image control statement * W E F08/0135 Vector subscripted actual makes VALUE dummy undefinable? * W E F08/0136 Argument correspondence with VALUE and ASYNCHRONOUS * W E F08/0137 Result of TRANSFER when MOLD is an array with element size zero * M C F08/0138 Type extension in submodules * M E F08/0139 Is the name of an external procedure that has a binding label a local identifier? * M E F08/0140 Assign to deferred-length coindexed character variable * M E F08/0141 Can a statement function have a variable-length PDT result? * M E F08/0142 Is useless module extension permitted? * M E F08/0143 May a pure procedure have an INTENT(OUT) polymorphic component? * M E F08/0144 Is nonadvancing I/O allowed during execution of DO CONCURRENT? ====================================================================== 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: 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: Erratum STATUS: J3 consideration in progress 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 penultimate sentences of 13.7 was intended for the case where all arguments on entry have normal or denormal values and edits are supplied to correct this. To specify the results of all the intrinsics for non-normal values is beyond the scope of an interpretation. Perhaps this should be considered for an extension that is adopted for the next revision of the standard. Meanwhile, guidance is provided by the second and third paragraphs of 14.8, which state "The inquiry function IEEE_SUPPORT_NAN is provided to inquire whether the processor supports IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. The inquiry function IEEE_SUPPORT_INF is provided to inquire whether the processor supports IEEE infinities. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. " EDITS: Page and line numbers refer to 04-007. [300:13&14] Subclause 13.7. In the penultimate sentence, replace "If" by "If the values of all input arguments are normal or denormal and" and replace "if" by "if the values of all input arguments are normal or denormal and" SUBMITTED BY: Fred Tydeman HISTORY: 05-121r1 m171 F03/0042 submitted ---------------------------------------------------------------------- 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: 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: [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: J3 consideration in progress QUESTION: Must the intrinsic function REAL with KIND parameter 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. 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. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANSWER: Yes, for purposes of determining the type and kind of the result, for use in subclause 7.1.9.3, the result of the intrinsic function REAL with KIND argument wp returns a value that is of type REAL(KIND=wp). However, if it is used within an expression involving intrinsic operations, "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." and "mathematically equivalent expressions of numeric type may produce different computational results", which means that it is unlikely to serve your purpose. Intermediate results can be rounded to storage format by assignment to a VOLATILE variable. 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 F03/0121 Bader NO vote: The answer as a whole seems misleading; given the specification of the REAL intrinsic and existing rules for type conversions (or their absence) in expressions, the answer should simply be "yes". The reference to mathematically equivalent expressions is mostly irrelevant (since by parenthesization the programmer's purpose should very likely be achievable), and that to VOLATILE variables is simply unnecessary. Corbett NO vote: I previously voted for the answer given. Since then, I have been convinced I was mistaken. I no longer think that REAL(X), where X has type REAL but has a different kind type parameter value from that of type default real, should be considered mathematically equivalent to X. I now agree with Mr. Braams that the intrinsic function REAL should do a real conversion. I agree with Van that nothing in the standard or in the existing interpretations requires VOLATILE to force a conversion. Interpretation F90/000001 is the only interpretation I have found that addresses the issue, and it, of course, could not require the use of VOLATILE. I agree with John that VOLATILE should not be required to force a conversion. Long NO vote: Similar to F03/0084, this hinges on the meaning of "mathematical". I'm not convinced that a processor is allowed to treat X and REAL(X,wp) as mathematically equivalent. The REAL function (may) perform an operation that is outside the scope of normal algebra. Maclaren comment: The recommendation to use VOLATILE is wrong. There is a common myth in among C and C++ programmers and even in informative text in the standards that volatile implies this semantic, but it is not justified by their normative text, nor do all compilers support it. Fortran should not follow suit - in particular, Fortran 2008 5.3.19 makes no such guarantee. In particular, because 5.3.19 provides license to the processor and not to the programmer, a compiler is at liberty to optimise all references to VOLATILE variables if it does not provide any method of accessing it other than those specified by the program. Regrettably, the correct response is: There is no feature in Fortran to provide this facility, though assignment to a VOLATILE variable will often work. On some processors, making that a BIND(C) variable in a module will be needed but, on a few, this recipe will not work at all. This should be addressed properly in a future revision. Muxworthy comment: Like Van, I find the Answer unsatisfactory although the outcome (no edit) is correct. The answer is Yes. This is stated clearly in 13.7.138. What a processor might or might not do behind the scenes is irrelevant. If it does not obey 13.7.138 it is non-standard- conforming. (We are talking about a high-level language, not C). Reid NO vote: I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defined, or becomes undefined only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ..."). Snyder NO vote: The answer refers to subclause 7.1.5.2.4 without identifying that subclause: "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated," and uses that as justification for the answer. Subclause 7.1.5.2.4 is entirely irrelevant to the question. Subclause 4.1.2 specifies that "For each type there is a set of valid values." Subclause 4.2 specifies that "the set of values... depend[s] on the values of the parameters." Subclause 13.7.2, as amended by the answer to interp F08/0008, says, in part, "A program shall not invoke an intrinsic procedure under circumstances where a value ... returned as a function result is not representable by objects of the specified type and type parameters." Allowing the REAL intrinsic function to return a result that is claimed to have a specified kind, and a value that is not a member of the set of valid values for that kind, violates the requirements of subclauses 4.1.2, 4.2, and 13.7.1 as amended by interpretation F08/0008. An interpretation should not introduce an inconsistency that will later need to be resolved by yet another interpretation. Even if F08/0008 were to fail, the result of the answer to this interpretation would be to introduce a conflict to 13.7.1 status quo ante, which reads, in part, "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," and continues with caveats not germane to the present interpretation. The only reason ever to invoke the REAL intrinsic function with a real argument and a KIND argument is to produce a result with the specified kind, and a value that is a member of the set of valid values for that kind. This is exceedingly rare, except perhaps as an actual argument (where the processor must necessarily produce a value that is a member of the set of valid values, and additionally is represented by the specified type and kind), and therefore requiring processors to produce a value for the result of REAL that is a member of the set of valid values for the kind of the result would have no measurable effect on performance in any program other than an arcane SPEC benchmark. The answer should be "Although a processor is allowed to replace an expression with a mathematically equivalent expression, subclauses 4.1.2, 4.2, and 13.7.1 (or 13.7.1 as amended by interpretation F08/0008) require the value of the result of every intrinsic function to be a member of the set of valid values for the type and kind of the function result." No normative edits would be required, although it would be helpful to add a recommendation in a note (or a requirement) to 13.7.138p5 Case (i) that the result have a value that is not different from the argument by more than one unit in its least significant place (unless the argument is NaN), and that it be rounded according to IEC 60559:1989 and the rounding mode currently in effect if the IEEE_ARITHMETIC module is accessible (unless the argument is NaN). Advice in the presently proposed answer is offered to use the VOLATILE attribute. 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." Invoking the REAL intrinsic function is a means that IS specified by the program, so the advice is not germane. One who reads subclauses 4.1.2, 4.2, 5.3.19, 7.1.5.2.4 and 13.7.1 would have no clue that the way to make REAL operate as essentially all users expect it to operate is to store its result into a variable that has the VOLATILE attribute! If one must have the presently proposed answer, having no edits is entirely inadequate. Subclause 5.3.19 must be amended to include effects that ARE specified by the program. Subclauses 5.3.19 and 13.7.138 must be amended to include advice to use the VOLATILE attribute to make REAL function as essentially all users expect it to. Further, there must be an explicit exemption for REAL in subclause 13.7.1, and maybe in 4.1.2 and 4.2 as well. A perverse reading of 13.7.1, adroitly sidestepping subclauses 4.1.2 and 4.2, might be that a function is allowed to return a value that is not a member of the set of valid values for the type and kind of the result, but that a program is not allowed to invoke the function in such a way as to produce that result. This would make it illegal instead of pointless to invoke the REAL intrinsic function with the hope to produce a value that is a member of the set of valid values for the kind of the result. That is, for example, that REAL is permitted to act consistently with the present answer to this interpretation, but a program is not permitted to invoke REAL(3.14159265358979323846264338d0,kind(1.0e0)) if the processor uses 32-bit IEEE arithmetic for default real, because the result would not be a member of the set of valid values. If so, in order to detect programs that are not standard conforming, a helpful processor should announce an error in this circumstance, which requires producing a value that is a member of the set of valid values, and comparing it to the proposed result value instead of using it as the result value. One might argue that 13.7.1 was aimed, for example, at SQRT(-1.0), for which the mathematical function approximated by the intrinsic function has no values that are representable by the type and kind of the result. But it doesn't say so, and that argument does not reasonably apply to REAL. Since 13.7.138p5 Case (i) explicitly says that REAL produces an approximation to its argument, it is more reasonable for REAL(3.14159265358979323846264338d0,kind(1.0e0)) to produce an approximation that is a member of the set of valid values for the kind of the result, than for its invocation to be prohibited, or for it to produce a result that is not a member of the set of valid values for the kind of the result. If a processor absolutely must reduce REAL with a real argument to the identity operation under certain circumstances, a command-line argument to cause this behavior could be provided, with a caveat that using that setting admits behavior that is not consistent with the standard. .................................................................... F03/0121: Replies from the editor <<< I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defined, or becomes undefined only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ..."). >>> Well no. Inter-statement optimisation is alive and well (re, in spite of F90/000001: some vendors have to compete on SPEC benchmarks and the like!), and the people moaning about the REAL() intrinsic not doing what they want frequently also want the optimisation cranked up to that level. In that case, VOLATILE is something that does, in fact, work. One might plausibly argue that we are being more helpful here than we need to. Nick opined: <<< ... is a common myth in among C and C++ and even in informative text in the standards that volatile implies this semantic >>> If informative text in the standard implies this semantic, that is a clear indication of the intent of the C committee. <<< but it is not justified by their normative text, >>> That is your opinion. You might or might not be right. My understanding of the normative text is otherwise i.e. the same as the informative implication. I might or might not be right. Under the circumstances, since this is the Fortran committee not the C committee, we should take the informative text as being correct rather than what some of the barracks-room lawyers say. <<< nor do all compilers support it >>> Many compilers have many bugs in many areas, and volatile is no exception to this. Indeed, papers have been written on such very topics. However, this case is very simple (no multi-threading required!) and in my experience it does work reliably. ---------------------------------------------------------------------- ====================================================================== 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: Passed by WG5 ballot QUESTION: Is the following subprogram required always to print "T T"? subroutine Wobbly ( N ) integer, volatile :: N integer :: A ( n, n ) integer :: B ( n * n ) print *, size(a) == size(b), size(a,1) == size(a,2) end subroutine Wobbly ANSWER: No. There are three specification expressions in the subroutine, and the volatile variable N appears in each of them. Since, being volatile, the variable N might have a different value each time it is referenced, these three specification expressions might receive different values for their references to N. If that happens, the array sizes might well be different. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 13-298r1 m202 F08/0099 submitted 13-298r2 m202 Revised answer - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Does the following program fragment conform to the 2008 standard? subroutine S ( P ) interface subroutine Q ( X ) real, intent(inout) :: X end subroutine Q end interface interface subroutine P ( A ) import procedure (R) :: A end subroutine P end interface procedure (Q) :: R end subroutine S 12.4.3.3p2 says "If an entity that is made accessible by this means is accessed by host association and is defined in the host scoping unit, it shall be explicitly declared prior to the interface body." However, although the procedure R is declared in the host scoping unit it is not defined in the host scoping unit, so this is ineffective. Q2. If the IMPORT statement were changed to "IMPORT R", would that be conforming? 12.4.3.3p1 says "An entity that is imported in this manner and is defined in the host scoping unit shall be explicitly declared prior to the interface body." Again, procedure R is declared but not defined in the host scoping unit, so this requirement is ineffective. ANSWER: These examples were not intended to conform to the Fortran standard. An edit is provided. EDITS: [282:7] 12.4.3.3p1, after "imported in this manner and is" change "defined" to "declared". [282:14] p2, after "is accessed by host association and is" change "defined" to "declared". SUBMITTED BY: Van Snyder HISTORY: 13-305 m202 F08/0100 submitted 13-305r1 m202 Revised answer & edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider Program p1 Real :: x = 3, y = 4 Namelist /n/ x, y Write (*,n) End Program According to 5.6, "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, this stops short of saying that the order is the same, merely that it determines it. Perhaps it might be standard-conforming for a processor to always produce the values in reverse order, for example. 10.11.4 does not seem to address the issue of what the order is. Q1: Is the order meant to be the same? Consider Program p2 Real :: x = 3, y = 4 Namelist /n/ x, y, x Write (*,n) End Program This program did not conform to Fortran 90, but does conform to Fortran 2003 and later. The Fortran 2008 standard says (5.6p2): "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, there are only two variables in the NAMELIST statement, X and Y. Therefore it seems to be ambiguous whether the output should be something like &N X=3 Y=4 / or &N Y=4 X=3 / Some compilers produce &N X=3 Y=4 X=3 / but this is not an ordering of the variables X and Y. Q2. Is this program intended to conform to the standard, and if so, what is the intended output? ANSWER: A1. Yes, the order is meant to be the same. An edit is supplied to clarify this. A2. The program was intended to conform to the standard, and the output was intended to be the third option. An edit is supplied to correct the text in 5.6. EDIT: [111:13-14] 5.6p2, replace entire paragraph with "The order in which the values appear on output is the same as the order of the s in the namelist group object list; if a variable appears more than once as a for the same namelist group, its value appears once for each occurrence". SUBMITTED BY: Malcolm Cohen HISTORY: 13-314 m202 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider Program test Type t End Type Type,Extends(t) :: t2 End Type Class(t),Allocatable :: x,y Type(t),Allocatable :: a x = t() y = t2() a = t() Do i=1,2 Select Type (z=>Merge(a,x,i==1)) ! A Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(x,a,i==1)) ! B Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(a,y,i==1)) ! C Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(y,a,i==1)) ! D Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(x,y,i==1)) ! E Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do End Program According to the standard, the type of the result of MERGE is the same as the type of TSOURCE. One might imagine that this means that the result is polymorphic if and only if TSOURCE is polymorphic. This would be a slightly unusual and unexpected asymmetry. Also, the types of FSOURCE and TSOURCE have to be the same. If this means both the declared and dynamic types, one might imagine that this means that the result is polymorphic if and only if both FSOURCE and TSOURCE are polymorphic, since otherwise the non-polymorphic argument decides the type. On the other hand, if the type requirements are talking about the declared type only, one might imagine that the result is polymorphic if either TSOURCE or FSOURCE is polymorphic. However, in any case there would seem to be an error in the standard, since the result is specified to be the same as TSOURCE, rather than the same as whichever argument is chosen to be the result value; if this refers to the dynamic type, it is contradictory when FSOURCE is chosen as the result value. And if it does not refer to the dynamic type, there appears to be no statement which says what the dynamic type of the result is. Q1. Is the apparent asymmetry between the treatment of TSOURCE and FSOURCE intended? Q2. Which of the MERGE invocations A-E are polymorphic? Q3. When the result of MERGE is polymorphic, are the dynamic types of TSOURCE and FSOURCE permitted to be different? And if they are, is the dynamic type of the result the same as the chosen argument and not necessarily the same as TSOURCE? ANSWER: A1. There is no asymmetry between TSOURCE and FSOURCE, because they are required to have the same type and type parameters. This means that both the declared and dynamic types and type parameters must be the same. A2. Only MERGE invocation E is polymorphic. An edit is provided to clarify this. A3. No, the dynamic types and type parameters are required to be the same. Note that because MERGE is elemental, it needs the type and type parameters to be the same for both the declared and dynamic types, otherwise the principle that all elements of an array have the same (declared and dynamic) type and type parameters would be broken. EDITS: [368:26] 13.7.110p4 (Result Characteristics), "Same as TSOURCE." -> "Same type and type parameters as TSOURCE. Because TSOURCE and FSOURCE are required to have the same type and type parameters (for both the declared and dynamic types), the result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." SUBMITTED BY: Malcolm Cohen HISTORY: 13-321 m202 F08/0102 submitted 13-321r1 m202 Revised example - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0103 TITLE: Pointers to internal procedures with different host instances KEYWORD: internal procedure, procedure pointer, host instance DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider: MODULE TYPES ABSTRACT INTERFACE SUBROUTINE SUBROUTINE() END SUBROUTINE SUBROUTINE END INTERFACE TYPE PPS PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR END TYPE PPS END MODULE TYPES SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTEGER I, J, N N = SIZE(PPA) DO I = 1, N CALL PPA(I)%SU_PTR() END DO PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N) END SUBROUTINE CPPS RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTERFACE SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE CPPS END INTERFACE IF (SIZE(PPA) .EQ. 3) THEN CALL CPPS(PPA) ELSE CALL OUTER( (/ PPA, PPS(INNER) /) ) END IF CONTAINS SUBROUTINE INNER() WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA) END SUBROUTINE INNER END SUBROUTINE OUTER PROGRAM MAIN USE TYPES INTERFACE RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE OUTER END INTERFACE TYPE(PPS),DIMENSION(0) :: PPA CALL OUTER(PPA) END PROGRAM MAIN Does this program print all true values? The procedure pointers are all associated with the internal procedure INNER, which might lead one to believe that the answer is yes (that is, they are all associated with the same target), but each procedure pointer at each nesting level has a different host instance, which might lead one to believe that the answer is no (and that therefore only one of each of the 3-element sequences printed will be T). ANSWER: No, the program does not print all true values; two procedure pointers to the "same" internal procedure are only associated if the host instances are also the same. An edit is supplied to the standard to clarify this. EDITS: [330:20] 13.7.16p5 Case (ii), after "with TARGET" insert "and, if TARGET is an internal procedure, they have the same host instance". [330:22] Case (iii), after "same procedure" insert "and, if the procedure is an internal procedure, they have the same host instance". SUBMITTED BY: Robert Corbett HISTORY: 13-357 m202 F08/0103 submitted with four answers 13-357r1 m202 Selected answer, added edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot All references are to Fortran 2008 10-007r1. On comp.lang.fortran Francis Coudert asked The Fortran 2008 standard defines an inquiry function as an "intrinsic function, or function in an intrinsic module, whose result depends on the properties of one or more of its arguments instead of their values". 10-007r1 section 1.3.89 [11:27-30] I wonder: by that definition, how can the IEEE_SUPPORT_HALTING(FLAG) function from the IEEE_EXCEPTIONS intrinsic module be an inquiry function? Its result depends on the value of FLAG, not its properties. QUESTIONS: Question 1. Are the functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc intended to be inquiry functions? Question 2. Are they consistent with the definition of inquiry functions? Question 3. Are they allowed in Specification expressions? Question 4. Are they allowed in Constant expressions? ANSWERS: Answer 1. No. These intrinsic module functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc are not inquiry functions because their results depend on other than the properties of their arguments. Edits are provided to correctly identify these functions as transformational: [18:35-37] section 1.3.146 transformational function intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function Answer 2. No. Their current classification is inconsistent with the definition of inquiry functions. Answer 3. They should be allowed in specification expressions. Edits are provided to correct this. Answer 4. No. Only the 3 IEEE_* functions should be allowed in constant expressions, not the 3 C_* functions. Edits are provided to correct this. EDITS to 10-007r1: [150:28+] section 7.1.11 Specification expression, paragraph 2, after bullet (10), insert a new bullet: "(nn) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC (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 bullet (8): "(8) a reference to the transformational function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE ARITHMETIC (14), where each argument is a constant expression," with: "(8) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant expression," [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 ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot 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. EDIT 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 ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Was it intended that MOVE_ALLOC can affect the allocation status of an array on an image other than the executing image? An example is CALL MOVE_ALLOC(A,B[I]%A) ANSWER: No, it was not intended that the executing image can affect the allocation status of an array on an image other than the executing image. Edits are provided to correct this. EDITS to 10-007r1: 13.7.118 MOVE_ALLOC(FROM,TO), para 3: [372:18] In the description of FROM, after "It shall be allocatable", add "and shall not be a coindexed object". [372:19] In the description of TO, after "It shall be allocatable", add "and shall not be a coindexed object". SUBMITTED BY: John Reid HISTORY: 14-119 m203 F08/0106 submitted - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- 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: [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: Passed by WG5 ballot QUESTIONS: 1. Is the declaration of V permitted: type :: one real, allocatable :: C[:] end type one type :: two type(one), allocatable :: A end type two type(two), pointer :: V(:) 2. Is the declaration of X permitted: type :: three real :: C end type three type :: four type(three), allocatable :: A[:] end type four type(four) :: X ANSWERS: 1. Type two is not conforming, because the entity A has a coarray ultimate component and C525 requires such an entity to be a nonpointer nonallocatable scalar. Therefore the declaration of V is not permitted. 2. X satisfies C525, so declaration of X is permitted. X has an ultimate (allocatable) coarray component (A[:]), and therefore according to C526 must be a dummy argument or have the SAVE attribute. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 14-163 m204 F08/0108 submitted 14-163r1 m204 Fixed examples in questions, revised answer - passed by J3 meeting 14-258 m205 Passed as amended by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0109 TITLE: LOCK_TYPE and unlimited polymorphic KEYWORD: LOCK_TYPE, unlimited polymorphic DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is available. Q1. Is allocation of X%C permitted? TYPE t TYPE(LOCK_TYPE),ALLOCATABLE :: c END TYPE TYPE(t) :: x[*],y[*] ALLOCATE(y%c) ALLOCATE(x%c,SOURCE=y%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=L ) Q3. Is allocation of C permitted? class(*), pointer :: C allocate ( LOCK_TYPE :: C ) Q4. Is pointer assignment to C permitted? class(*), pointer :: C type(lock_type), intent(in), target :: L[*] c => L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE, SAVE :: C[:] TYPE(LOCK_TYPE), SAVE :: X[*] ALLOCATE(C,MOLD=X) ANSWER: A1. Allocation of X%C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A2. Allocation of C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A3. This allocation of C is permitted. It cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. Edits are given to fix C1302 to say "declared type" explicitly to avoid this confusion. A4. Pointer assignment to C is permitted. A5. This statement was intended to be permitted. An edit is supplied to correct the requirements. EDITS: [6:7+] After definition 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component (4.5.1)". [127:8-9] 6.7.1.1 Syntax, C642, Change "C_PTR," to "C_PTR or" Delete ", LOCK_TYPE ... LOCK_TYPE". [127:9+] Insert new constraint "C643a (R627) If SOURCE= appears, the declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." [127:18-19] 6.7.1.1, p4, "If" -> "If an ALLOCATE statement has a SOURCE= specifier and an", {There is no problem with MOLD=. "subcomponent" works ok here because we have an object not a type.} [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". SUBMITTED BY: Van Snyder HISTORY: 14-164 m204 F08/0109 submitted 14-164r3 m204 As amended, passed by J3 meeting 14-258 m205 Failed the J3 letter ballot #31 14-233r1 Malcolm Cohen's yes vote with comment on F08/0109: Bill Long writes: "The example Q3 has a variable, C, of type LOCK_TYPE that is not a coarray. This violates C1302. Answer A3 is wrong." No, it cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. C1302 ought to be fixed to say "declared type" explicitly, to avoid this confusion; [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". Bill continues: "For the same reason the example Q4 is defective and answer A4 is wrong. " For the same reason, there is nothing wrong with Q4. Bill continues: "The example code in Q5 is also defective, although could be repaired by changing the declaration of X to TYPE(LOCK_TYPE),SAVE :: X[*] That seems to be sufficient to make answer A5 acceptable." X should certainly be explicitly made a coarray, but giving it SAVE seems unnecessary (this might be a main program or module, or might be a subprogram with a global SAVE, or X might be a dummy argument). I guess it doesn't hurt though (other than looking a bit strange to have X saved but C not, so if we're going to SAVE one we should SAVE the other). Van Snyder's yes vote with Comment on F08/0109: "C643" in edit at [127:8-9] ought to be "C642" Result for F08/0109: /INTERP accepts Van's "C643 should be C642". In Q5 make X a coarray and add SAVE to both C and X. Make the edit to clarify C1302. /INTERP agrees with Malcolm that Q3 and Q4 are them ok. This is a difficult subject and /INTERP believes that the J3 meeting should vote again on F08/0109 with these changes. F08/0109 failed the J3 letter ballot. ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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" with "denotation". Replace "depend ... , or on" with "be affected by the data transfer, the processing, or". The paragraph becomes "The denotation of a variable 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 and array element selection. Anything that affects this process is prohibited in this context; that includes the values of any subscripts used, and if the variable is specified by a pointer function reference, anything that affects the evaluation of that function. {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 ---------------------------------------------------------------------- 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: 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: Passed by WG5 ballot QUESTION: Consider CHARACTER(80) text(0:100), msg INTEGER stat,istat(0:80) REAL,ALLOCATABLE :: x(:),y(:,:) ... ALLOCATE(x(10),STAT=stat,ERRMSG=text(stat)) ! A DEALLOCATE(x,STAT=stat,ERRMSG=text(stat)) ! B msg = '' ALLOCATE(y(999999,999999),STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! C msg = '' DEALLOCATE(x,STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! D In each of the statements labelled A-D, there is a dependency between the STAT= specifier and the ERRMSG= specifier (from STAT= to ERRMSG= in A and B, and from ERRMSG= to STAT in C and D). There appears to be no prohibition against this (though there are many prohibitions against other dependencies in ALLOCATE and DEALLOCATE). Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: These are not standard-conforming, as no interpretation is established for them. An edit is supplied to clarify this prohibition. EDITS: [132:4] 6.7.4 STAT= specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG= specifier, p1, append "The shall not depend on the value of the .". SUBMITTED BY: Malcolm Cohen HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting 14-258 m205 Passed by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 ---------------------------------------------------------------------- NUMBER: F08/0113 TITLE: Specifiers in image control statements KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider CHARACTER(80) text(0:100),msg INTEGER stat,istat(2) REAL,ALLOCATABLE :: x(:) TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*] LOGICAL acq, aacq(0:80) ... SYNC ALL(STAT=stat,ERRMSG=text(stat)) ! A SYNC IMAGES (*,STAT=stat,ERRMSG=text(stat)) ! B SYNC MEMORY(STAT=stat,ERRMSG=text(stat)) ! C LOCK(lock,ACQUIRED_LOCK=acq, & STAT=istat(MERGE(1,2,acq)), & ERRMSG=text(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=stat,ERRMSG=text(stat)) ! E LOCK(alock(stat),STAT=stat) ! F msg = '' UNLOCK(alock(LEN_TRIM(msg)),STAT=stat, & ERRMSG=msg) ! G stat = 13 SYNC IMAGES(stat,STAT=stat) ! H msg = 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=stat, & ERRMSG=msg) ! I In each of the statements labelled A-F, there is a dependency between the STAT= specifier and the ERRMSG= specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK= specifier and the STAT= specifier (there is no dependency between ACQUIRED_LOCK= and ERRMSG= because the former is only set on successful execution and the latter is only set on an error condition). There appears to be no restrictions at all on any dependencies from ACQUIRED_LOCK=. In the LOCK statement (F), there is a dependency between the STAT= specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG= specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT= variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG= variable and the image set. Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: No interpretation is established and therefore these are not conforming. An edit is provided to clarify this. EDITS: [190:16-] 8.5.4 SYNC IMAGES statement, insert new p1, "The value of shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the 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 ---------------------------------------------------------------------- NUMBER: F08/0114 TITLE: Can LOCK_TYPE components have the POINTER attribute? KEYWORD: LOCK_TYPE component, POINTER DEFECT TYPE: Erratum STATUS: J3 consideration in progress Assume LOCK_TYPE is accessible from ISO_Fortran_Env. QUESTION: The following type definition and variable declaration are permitted by C1302: type :: One type(lock_type), pointer :: L end type One type(one), allocatable :: L1[*] C1302 requires a named variable of LOCK_TYPE to be a coarray. C526 requires a coarray to be allocatable or to have the SAVE attribute. The following declaration is apparently prohibited because L4 is not a coarray: type(lock_type), pointer :: L4 Was it intended that pointer components of type LOCK_TYPE be permitted, but that named variables of type LOCK_TYPE with the POINTER attribute be prohibited? ANSWER: It was intended that components of type LOCK_TYPE not be permitted to have the POINTER attribute. Edits are provided to correct this mistake. EDITS: [399:18+] 13.8.2.16 LOCK_TYPE, after C1302, insert new constraint "C1302a A component of type LOCK_TYPE, or that has a nonallocatable direct component of type LOCK_TYPE, shall not have the POINTER attribute.". SUBMITTED BY: Van Snyder HISTORY: 14-140 m204 F08/0114 submitted 14-140r1 m204 Revised to reverse decision 14-140r2 m204 Passed by J3 meeting 14-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: Passed by WG5 ballot 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: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or". 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 ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [300] 12.5.2.13p1(3)(b) append to the end of the paragraph "or a coindexed object". [300] 12.5.2.13p1(4)(b) append to the end of the paragraph "or a coindexed object". 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 ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [440:4, 16.3.1p1] Replace "named constants, named" with "named constants, named procedure pointers, named". 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 ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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. EDIT 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 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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", 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}$. 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 ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [6:7+] After 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" {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 ---------------------------------------------------------------------- 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: [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: Passed by WG5 ballot 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. Edits are provided to correct this oversight. EDITS: [10-007r1:151:7-8 7.1.11p8] Replace "or an array bound" with ", an array bound, or a coarray bound". Replace "or array bound" with ", array bound, or coarray bound". 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 ---------------------------------------------------------------------- NUMBER: F08/0127 TITLE: May an initial line begin with a semicolon? KEYWORDS: Semicolon DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 is permitted to 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 ---------------------------------------------------------------------- NUMBER: F08/0128 TITLE: Is recursive USE within a submodule permitted? KEYWORDS: SUBMODULE, USE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0129 TITLE: Is CLASS(type) required to refer to a prior type definition? KEYWORDS: CLASS, type definition DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 the of the specified derived type." {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 ---------------------------------------------------------------------- NUMBER: F08/0130 TITLE: Does coarray allocation sync even with stopped images? KEYWORDS: ALLOCATE, DEALLOCATE, coarray, synchronization, stopped DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [128:16-17] 6.7.1.2 Execution of an ALLOCATE statement, p4, Change "On each image" to "If no error condition apart from 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 apart from STAT_STOPPED_IMAGE occurs, execution of the segment 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 images." {A2,A4: Last sentence is the consistency requirement.} [131:17-18] 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 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 ---------------------------------------------------------------------- NUMBER: F08/0131 TITLE: Are the changes to C_LOC in the 2010 revision intentional? KEYWORDS: C_LOC, interoperability DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [xvi] Introduction, "Intrinsic modules" bullet point, Before "The function C_SIZEOF" insert new sentence "A contiguous array that is not interoperable but which has interoperable kind and kind type parameter, 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 ---------------------------------------------------------------------- NUMBER: F08/0132 TITLE: Can a procedure pointer be declared with an interface block? KEYWORDS: procedure pointer, interface block DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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:27-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 and is not a 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 and is not a 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 ---------------------------------------------------------------------- NUMBER: F08/0133 TITLE: Is unallocated actual associated with nonallocatable dummy OK? KEYWORDS: OPTIONAL, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0134 TITLE: in an image control statement KEYWORDS: stat=, image control statement DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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. EDIT: [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 ---------------------------------------------------------------------- NUMBER: F08/0135 TITLE: Vector subscripted actual makes VALUE dummy undefinable? KEYWORDS: VALUE, definable, vector subscript DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [295:3] 12.5.2.4 Ordinary dummy variables, p18, after applying the changes in 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 ---------------------------------------------------------------------- NUMBER: F08/0136 TITLE: Argument correspondence with VALUE and ASYNCHRONOUS KEYWORDS: VALUE, ASYNCHRONOUS, coindexed, contiguous DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- 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: Passed by WG5 ballot 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0138 TITLE: Type extension in submodules KEYWORDS: submodules, deferred type-bound procedures DEFECT TYPE: Clarification STATUS: Passed by J3 meeting 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 C456 in 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. EDIT: 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 --------------------------------------------------------------------- NUMBER: F08/0139 TITLE: Is the name of an external procedure that has a binding label a local identifier? KEYWORDS: TRANSFER, zero-sized scalar DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program fragment: 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0140 TITLE: Assign to deferred-length coindexed character variable KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 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: [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] change "each" to "if the variable is allocatable, each". 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 - if the variable is allocatable, each deferred length type parameter 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 ---------------------------------------------------------------------- NUMBER: F08/0141 TITLE: Can a statement function have a variable-length PDT result? KEYWORDS: Statement function, parameterized derived type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [22: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 ---------------------------------------------------------------------- NUMBER: F08/0142 TITLE: Is useless module extension permitted? KEYWORDS: SUBMODULE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0143 TITLE: May a pure procedure have an INTENT(OUT) polymorphic component? KEYWORDS: PURE, INTENT(OUT), polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: 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 ---------------------------------------------------------------------- NUMBER: F08/0144 TITLE: Is nonadvancing I/O allowed during execution of DO CONCURRENT? KEYWORDS: nonadvancing I/O, DO CONCURRENT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider program P integer :: I do concurrent ( I = 1:10 ) write ( *, *, 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 nonadvancing input/output not be permitted within a DO CONCURRENT construct. An edit is provided to address this oversight. [10-007r1:178:18+ at the end of the list in 8.1.6.7p1] insert a list item: " 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 ----------------------------------------------------------------------