J3/13-006Ar2 To: J3 From: Stan Whitlock Subject: Outstanding Fortran Interpretations, September 5, 2013 Date: 2013 October 13 Outstanding Fortran Interpretations, September 5, 2013 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 > 021 = N1907 == F08 Corrigendum 1 > 022 = N1902 == F08 Corrigendum 1 interps > 023 = N1957 == F08 Corrigendum 2 > 024 = N1959 == F08 Corrigendum 2 interps > J3 LB #28 13-255r1/13-262: 12 interps, all passed > J3 interp answers from m201: 8 passed by J3 meeting > remove interp text that is in N1957/59 F08 Corrigendum 2 + J3 LB #29 13-297/13-313: 8 interps, all passed + WG5 LB #6 N1987/88/90: 17 interps, 15 passed, 1 subsumed = WG5 LB #7 N1991/92/??: 8 interps, due 28-Oct-2013 = 10 J3 consideration in progress [keep this text document to 70 characters per line]................... 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 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? * W 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 * W 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 * W E F03/0053 The BIND attribute for C_PTR and C_FUNPTR * P E F03/0059 Structure components in namelist input * W 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? * W 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 * W 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-targetting 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 * W E F08/0071 Vector subscript target d C2 E F08/0072 Final subroutines with corank d C2 E F08/0073 Polymorphic auto-targetting d C2 E F08/0074 Implicit type in BLOCK construct * W E F08/0075 Pointer function reference as variable in assignment * X E F08/0076 Pointer function reference in READ Subsumed by F07/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 * W E F08/0083 Type parameter default expressions allow circular dependence * W E F08/0084 Pointer arguments to PURE functions * W E F08/0085 Problems with PARAMETERs * W E F08/0086 Implied-shape and separate PARAMETER statement * W E F08/0087 Mixed-kind character assignment * W E F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? * P E F08/0089 Variable-denoting functions change existing semantics * W E F08/0090 What restrictions apply to initialization and PARAMETER? * B E F08/0091 Derived type with no components * B E F08/0092 Derived type parameter requirements * B E F08/0093 Process exit status and error termination * B E F08/0094 Procedure statement and double colon * B E F08/0095 Is PRESENT allowed in specification and constant expressions * B E F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? * B E F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? * B E F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? ====================================================================== 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. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 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 can not 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 can not 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 can not 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 can not 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/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS to 10-007r1: [403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW), Replace with "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the operation or conversion, and as determined by the processor otherwise. It occurs in an intrinsic real exponentiation as determined by the processor. It occurs in a complex operation, or conversion by the intrinsic function CMPLX, if it is caused by the calculation of the real or imaginary part of the result." [403:10-11] Clause 14.3, first paragraph, second bullet (IEEE_DIVIDE_BY_ZERO), Replace with "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the division, and as determined by the processor otherwise. It is processor-dependent whether it occurs in a real exponentiation with a negative exponent. It occurs in a complex division if it is caused by the calculation of the real or imaginary part of the result." [462:24+] Clause A.2, after the fifth bullet from the end of the clause "the extent to which a processor supports IEEE arithmetic (14)", Insert new bullet points "- the conditions under which IEEE_OVERFLOW is raised in a calculation involving non-IEC 60559:1989 floating-point data; - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are raised in a floating-point exponentiation operation; - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a calculation involving non-IEC 60559:1989 floating-point data;" SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 F03/0030 submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 10-238r1 m193 Revised answer - Passed J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m196 Failed WG5 ballot 1 N1876 13-246 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: The descriptions of the intrinsic procedures often use the term "type" without qualification. It is unclear whether they mean "declared type" or "dynamic type". If they mean "dynamic type", then this would appear to allow unlimited polymorphic arguments to intrinsic procedures like ABS and SIN. Resolution of generic intrinsic procedures in this case would create an undue (and likely unintended) burden on the processor, and the declared type of the result of such a function call would be unclear as well. Question 1: Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic? Question 2: (a) Is the ARRAY argument of the intrinsic function CSHIFT permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 3: (a) Are the ARRAY and BOUNDARY arguments of the intrinsic function EOSHIFT permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, then must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 5: (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 6: Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC permitted to be polymorphic? Question 7: (a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 8: (a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 10: (a) Is the SOURCE argument of the intrinsic function SPREAD permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 11: (a) Is the SOURCE argument of the intrinsic function TRANSFER permitted to be polymorphic? (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? If the answer to (b) is yes: (c) If the MOLD argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 12: (a) Is the MATRIX argument of the intrinsic function TRANSPOSE permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 13: (a) Are the VECTOR and FIELD arguments of the intrinsic function UNPACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 14: Are any of the other arguments of any intrinsic procedure permitted to be polymorphic? ANSWER: The assertion that it is unclear whether "type" means declared, dynamic, or both, is misguided. The general rule is that wherever it makes sense, it means both. Where only one meaning makes sense, it means that one. Where only one meaning is intended but it would otherwise not be clear from context, it is qualified as "declared type" or "dynamic type". Answer 1: Yes. Answer 2: (a) Yes. (b) Yes. "The result is of the type ... of ARRAY". Answer 3: (a) Yes. (b) No. (c) The requirements apply to both the declared type and the dynamic type. (d) "The type has ... the type ... of ARRAY". Therefore it is polymorphic if ARRAY is polymorphic. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the declared type; this is explicitly stated. Answer 5: (a) TSOURCE and FSOURCE are required have the same declared type, but may be polymorphic. (b-d) The questions of what the requirements are on the dynamic type, and whether the result is polymorphic, are deferred to interp F08/0102. Answer 6: Yes. Answer 7: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. Note that this means that if either ARRAY or VECTOR is not polymorphic, the requirement for type matching means that the dynamic type of the polymorphic argument is known. (d) The result "has the same type" as ARRAY, and therefore is polymorphic if ARRAY is polymorphic. Answer 8: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. (d) The result "has the same type" as SOURCE, and therefore is polymorphic if and only if SOURCE is polymorphic. Answer 9: (a) Yes. (b) No. (c) The requirements are explicitly stated to refer to the declared type. Answer 10: (a) Yes. (b) Yes. "The result is ... of the same type ... as ARRAY.". Answer 11: (a) Yes. (b) Yes. (c) "The result is of the same type ... as MOLD.". Answer 12: (a) Yes. (b) Yes. The declared and dynamic types of the result are those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) The result has the same declared and dynamic types as VECTOR, and is polymorphic if and only if VECTOR is polymorphic. Answer 14: Yes. For example, IMAGE_INDEX, LCOBOUND, PRESENT, STORAGE_SIZE, and UCOBOUND. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-138 m171 F03/0047 submitted - contained the questions/answers 05-138r1 m171 Contained the edits, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 13-242 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C5101 in the Fortran 2008 standard states "If a common-block-object is of a derived type, it shall be a sequence type or a type with the BIND attribute and it shall have no default initialization." 2. Whether the derived types C_PTR and C_FUNPTR have the BIND attribute affects whether they are extensible. Subclause 4.5.7.1 of the Fortran 2008 standard states "A nonsequence derived type that does not have the BIND attribute is an extensible type." Are these types extensible? 3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. No, these types do not have the BIND attribute. 15.3.3 does not specify that they have the BIND attribute. 15.3.4 does not require them to have the BIND attribute in order to make them interoperable. 15.3.5 would require them to interoperate with a C struct if they had the BIND attribute; this is absurd, since C object pointers and C function pointers are clearly not structs. Note that whether these types have default initialization is not specified by the standard, so possession of BIND would not necessarily have allowed them in COMMON anyway. Edits are provided to correct incomplete, and thus misleading, statements about derived types and the BIND attribute. 2. No, these types were not intended to be extensible. It was an oversight that these types were not explicitly excluded from being extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008 standard. An edit is provided to correct this. 3. Yes, a user-defined derived type with the BIND attribute is permitted to have private components. This situation is the same as for SEQUENCE types, which are similar (but not interoperable). As with SEQUENCE types, making a component PRIVATE does prevent access, in a conforming program, to the component by a programmer who is sufficiently determined; however, it continues to fulfill the software engineering role for which it was intended. Note further that there are many other situations where two different Fortran derived types will interoperate with the same C derived type; this is not a defect in either standard, but simply a consequence of the two languages having different approaches to type compatibility. EDITS to 10-007r1: [19:15-16] In 1.3.147.6, replace the definition of "extensible type" with "type that may be extended using the EXTENDS clause (4.5.7.1)". {Repair definition of extensible type.} [77:3] In 4.5.7.1p1, After "A derived type" insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," {Prohibit these types from subsequent extension.} [431:6] In 15.3.4p1, replace entire paragraph with "Interoperability between derived types in Fortran and struct types in C is provided by the BIND attribute on the Fortran type." {Reduce misleading opening blather - this is just here so we didn't start the subclause with a bunch of constraints. Alternatively we could move paragraph 2 (and note 15.12) to replace paragraph 1.} [431:12+2] In 15.3.4, Note 15.11, After "is interoperable" insert "with a C struct type". {Correct another misleading sentence.} [431:13-18] In 15.3.4p2, Change all four occurrences of "Fortran derived type" to "derived type"; change the single occurrence of "Fortran type" to "derived type". {Remove unnecessary and confusing qualification of "derived type" with "Fortran".} SUBMITTED BY: John Reid HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-217r1 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 by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 12-190 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed as amended by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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/0064 TITLE: Recursive declaration of procedure interfaces KEYWORDS: procedure, interface DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1216 appears to prohibit the case of an interface name in a procedure declaration statement being the name of something declared in a later procedure declaration statement. But it does not appear to prohibit the case of an interface name being the name of something declared in a later interface body. In the above program, the characteristics of p rely on the characteristics of sub. The characteristics of sub, in turn, rely on the characteristics of p. Is this program standard-conforming? Q2. Consider the module MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE Constraint C1216 does not apply here since "s" is not declared by a procedure declaration statement; unlike Q1, it is also not declared by an interface body. However, the characteristics of S have not been determined before the procedure declaration statement has been processed, and that cannot be processed until we know what the interface of S is. Is this program unit standard-conforming? Q3. Consider the module MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE The interface of A depends on the interface of S2, which depends on the characteristics of B, which depends on the characteristics of S1, which depends on the characteristics of A; a circular dependency. Is this program unit standard-conforming? Q4. Consider MODULE m3 PROCEDURE(s),POINTER :: sptr CONTAINS SUBROUTINE s(p) PROCEDURE(sptr) :: p END SUBROUTINE END MODULE In the normal course of events there is no problem declaring a procedure pointer to have the interface of a module procedure that is defined later, and this is desirable, but in this case there seems to be a circular dependency between the characteristics of sptr, s, and p. Is this program unit standard-conforming? ANSWER: None of the examples are standard-conforming, as the standard does not establish an interpretation for them. An edit is provided to clarify this. EDIT to 10-007r1: [288:3] 12.4.3.6p2, append new sentence "The interface specified by shall not depend on any characteristic of a procedure identified by a in the of the same procedure declaration statement." SUBMITTED BY: Rob James HISTORY: 05-179 m172 F03/0064 submitted 05-226 m173 Passed by J3 meeting 06-133 m175 Failed J3 letter ballot #12 09-149 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 13-245 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is there an error in the description for the output of a IEEE infinity with a sign and a field width of 3 or 8? Fortran 2008, 10.7.2.3.2 paragraph 7, [252:33-34], describes the output of IEEE infinities; this specifies asterisks (field overflow) if the field width is less than 3, and omission of "inity" if the field width is less than 8. However, this does not take into account the fact that there might be a plus or minus sign in the field. The current text also fails to take into account the case of = 0, for both Infinity and NaN values. ANSWER: Yes, there is an error in the special cases. Edits are provided to correctly describe the required field widths for signed infinities. An edit is also provided to repair the description of the output of NaN values. EDITS to 10-007r1: [252:33-34] 10.7.2.3.2p7, Replace "If is ... produced." with "The minimum field width required for output of the form 'Inf' is 3 if no sign is produced, and 4 otherwise. If is greater than zero but less than the minimum required, the field is filled with asterisks. The minimum field width for output of the form 'Infinity' is 8 if no sign is produced and 9 otherwise. If is greater than or equal to the minimum required for the form 'Infinity', the form 'Infinity' is output. If is zero or is less than the minimum required for the form 'Infinity' and greater than or equal to the minimum required for the form 'Inf', the form 'Inf' is output. Otherwise, the field is filled with asterisks." [252:37] Same subclause, p8, Replace "If ... askerisks." with "If is greater than zero and less than 3, the field is filled with asterisks. If is zero, the output field is 'NaN'.". SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 submitted 07-271r2 m181 Passed by J3 meeting 07-321 m182 Failed J3 letter ballot #14 07-279 07-340r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Failed WG5 ballot #5 N1722-N1726 13-247 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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. 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 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 licence 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. ---------------------------------------------------------------------- NUMBER: F03/0139 TITLE: Functions returning procedure pointers KEYWORDS: procedure pointer DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: (1) Is a function permitted to return a procedure pointer? Much of the language talks about the function result variable, but a procedure pointer is not a variable. For example, 2.2.3 says [12:16] "The VARIABLE that returns the value of a function is called the RESULT VARIABLE." (emphasis mine); which indicates that the value of a function is returned in a variable. (2) Where may a function reference that returns a procedure pointer appear? In particular, (a) as a in a SELECT TYPE or an ASSOCIATE statement; (b) within parentheses as a primary; (c) as the argument to an intrinsic inquiry function such as KIND or LEN. (3) [12:18-19] says "a subroutine may be used to change the program state by changing the values of any of the data objects accessible to the subroutine". A procedure pointer is not a data object, so is this meant to imply that a subroutine is not permitted to change the state of a procedure pointer? Similar text for functions appears in the same paragraph. ANSWER: (1) Yes, a function is permitted to return a procedure pointer; the text calling this a variable is in error. Edits are supplied to correct these mistakes. (2) It was intended that a function reference that returns a procedure pointer only be permitted as an argument to the ASSOCIATED and NULL intrinsic functions and in places where an ordinary procedure name would be acceptable. Parentheses around a pointer act to dereference the pointer and return a copy of the value: this action is inapplicable to procedures. Thus the answers to the specific sub-questions are No, No, and No again. Clarifying edits are provided. (3) No, this implication is not intended. A clarifying edit is provided. EDITS for (1): [10:33+] Insert new term after "1.3.77 <>" "1.3.77a <> entity that returns the value of a function". [15:31-33] Delete term 1.3.121 <>. [52:2] 4.3.1.2p2, after "function result" delete "variable". [58:23] 4.4.3.2p5, "result variable in the function" -> "function result". [87:9] 5.1p2 "its result variable" -> "the function result". [109:24] 5.5p4, "name of the result variable of that function subprogram" -> "result of that function". {Function *subprogram*s do not have results, the function specified by the FUNCTION statement does, as do the ones defined by the ENTRY statements, but the subprogram is just syntax.} [112:15] 5.7.1.1 C587, "result variable" -> "function result". [114:22] 5.7.2.1 C5100, "result variable" -> "function result". [130:26] 6.7.3.2p2, after "function result" delete "variable". [278:11] 12.3.1 "result value"->"function result". {Reads a bit awkwardly, but it is important to use the correct terms and to be consistent with 12.3.3 (which does) otherwise this is undefined meaningless blather.} [307:5,9] 12.6.2.2p3, "result variable" -> "function result", twice. [307:12,14,15] p4, "result variable" -> "function result", thrice. [307:15-16] Delete "The characteristics ... variable.". [307:16-17] "result value"->"function result". [307:17] "is a pointer" -> "is a data pointer". [307:18,18,20] "result variable" -> "function result", thrice. [307:20+2] NOTE 12.41, "The ... subprogram." -> "The function result is similar to any other entity (variable or procedure pointer) local to the function subprogram.". [307:20+4] "this variable" -> "this entity". [307:20+5] "that variable" -> "that entity". [309:23,24] 12.6.2.5p3, "result variable name" -> "name of the function result", twice. [310:2] 12.6.2.6p3, after "name of its result" delete "variable". [310:2-3] Delete "The characteristics ... the result variable.". [310:5-6] "result variables identify the same variable" -> "result names identify the same entity" and delete ", although their names need not be the same". [310:6] "scalars" -> "scalar variables". [314:3] After "The result" delete "variable". [433:7] "result variable is a scalar"->"result is a scalar variable". [441:7,10] 16.3.1p4, "result variable" -> "function result", twice. [441:18-20] 16.3.3p1, "result variable" -> "function result", thrice. [449:3-4] 16.5.3.1p1 "result variables" -> "function results that are variables". [450:20] 16.5.3.4p6, "result variables" -> "function results that are variables". [456:11] 16.6.6p1, item (15)(e), "the result variable of a function" -> "a variable that is the function result of that procedure" {Also fixes all function results becoming undefined when a single procedure is invoked!} EDITS for (2). [133:26+] Insert new constraint "C702a (R701) The shall not be a function reference that returns a procedure pointer." [170:23+] Insert new constraint "C804a (R805) The shall not be a function reference that returns a procedure pointer." [316:12+] 13.2.1 after p6, insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [30:28] After "data objects" insert "or procedure pointers". SUBMITTED BY: Malcolm Cohen HISTORY: 09-295 m190 F03/0139 submitted - Passed by J3 meeting: B answers passed 10-105 m191 Passed as amended by J3 letter ballot #20 09-307 N1816 m191 Failed WG5 ballot #7 {N1805/6} - interp updated - see 10-135r1 13-249 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- ====================================================================== 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 with in 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/0071 TITLE: Vector subscript target KEYWORDS: Pointer assignment, Vector subscript DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider PROGRAM m197006 REAL,TARGET :: x(100) = [ (i,i=1,100) ] REAL,POINTER :: p(:) TYPE t REAL,POINTER :: q(:) END TYPE TYPE(t) y p => x ! (1) y = t(x) ! (2) p => x( [ 1,4,9,25 ] ) ! (3) y = t(x( [ 1,4,9,25 ] )) ! (4) PRINT *,y%q END PROGRAM The pointer assignment statement at (1) associates P with X. The intrinsic assignment statement at (2) includes the effect of pointer assignment of X to Y%Q, but is not a pointer assignment statement. The pointer assignment statement at (3) is not standard-conforming according to 6.5.3.3.2 paragraph 2: "An array section with a vector subscript shall not be ... the in a pointer assignment statement" However, the intrinsic assignment statement at (4) is not subject to this requirement as it is not a pointer assignment statement. Note that the quoted paragraph is entirely duplicative, as in: - the first bullet item is covered by 12.5.2.4p18, - the second bullet item is covered by C724 in 7.2.2.2 (but C724 does not cover this case either), - the third bullet item is covered by C901 in 9.5.1. Editorial improvements have been made in corrigendum 1. The entire paragraph has been rewritten. Q1. Was the statement marked (4) intended to be allowed? Q2. If not, was it intended to be prohibited by a constraint like C724, or was it intended to be a simple requirement? (Editorial note: in any case surely the requirement should appear in the pointer assignment subclause.) ANSWER: A1. No, this was not intended. An edit is supplied to correct this. A2. Constraint C724 was intended to cover this case. An edit is supplied to correct this. EDIT: [158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement, C724, change ""(R737) A " to "A variable that is a pointer target", making the whole constraint read: "A variable that is a pointer target shall have either the TARGET or POINTER attribute, and shall not be an array section with a vector subscript." {Make the constraint apply to all forms of pointer assignment.} {Notice that this edit incorporates the list item concerning vector subscripts from 6.5.3.3.2p2 status quo ante corrigendum 1.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-121 m197 F08/0071 submitted 12-121r1 m197 Revised wording with same edits - passed by J3 meeting 12-165r2 m198 Failed J3 letter ballot #25 12-147 13-250 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: (1) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg integer, pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 integer, pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X, Y = 42 10 .op. x = y end program What Is the "10" in "10 .op. x = y" an operand, and therefore an argument of a reference to Binary, or is .op. a reference to Unary and "10" a statement label? (2) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. ANSWER: It was an oversight that the programs in (1) and (2) conform to the syntax and constraints in two different ways. The problem stems from the over-ambitious extension of allowing pointer function references to denote variables; this was unambiguous for syntax, but is not for operator syntax. Also, operator syntax has other restrictions on it that are intended to prevent modification of an operand, and these are subverted if the result is treated as a variable. Edits are supplied to remove the treatment of pointer-valued operators as variables. EDITS: [117:13] In 6.2, R602, change "" to "". [117:15] In 6.2, C602, change " ... has" to " shall have". [158:18+] In 7.2.2.2, R737, add new production "<> ". {Restore description of to F2003 version.} [158:20+] In 7.2.2.2, After C724, add new constraint "C724a (R737) An shall be a reference to a function that has a data pointer result." {Restore F2003 constraint (more or less).} SUBMITTED BY: Van Snyder HISTORY: 12-149 m198 F08/0075 submitted 12-149r1 m198 Revised edit 12-149r2 m198 Clarified answer, passed J3 meeting 12-196 m199 Subsumed F08/0076 and Failed J3 letter ballot #26, 12-184 12-197 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0076 TITLE: Pointer function reference in READ KEYWORDS: Pointer function reference, READ, defined operator DEFECT TYPE: Erratum STATUS: Subsumed by F08/0075 QUESTION: Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. An edit is supplied to remove the ambiguity in the current standard. ANSWER: This is another example of the same problem as F08/0075, viz syntactic ambiguity caused by the F2008 feature "operator syntax for variable denotation". Therefore this interpretation request is subsumed by F08/0075. EDITS: See F08/0075. SUBMITTED BY: Van Snyder HISTORY: 12-150 m198 F08/0076 submitted 12-150r1 m198 Revised answer and edits, passed J3 meeting 12-196 m199 Subsumed by F08/0075, J3 letter ballot #26, 12-184 Result: This is another instance of the same problem (syntactic ambiguity) caused by the same feature (operator syntax for variable denotation) as F08/0075, so needs to be answered together with F08/0075 => example will be added to F08/0075, and F08/0076 is therefore subsumed by F08/0075. 12-197 m199 F08/0075 passed by J3 meeting 13-237 m200 F08/0075 passed by J3 LB #27 13-203 N1990 m202 F08/0075 passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0083 TITLE: Type parameter default expressions allow circular dependence KEYWORDS: type parameter expressions, circular dependence DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider type :: T ( I, J ) integer, kind :: I = J + 1 integer, kind :: J = I + 1 end type T type(t) :: X(1,2) print *, x%i, x%j end 1. Is the program standard conforming? 2. What does it print? ANSWER: 1. The program is not conformant because the standard does not establish an interpretation. An edit is supplied to make it clear that the program is not comformant. 2. The standard does not establish an interpretation. EDITS: Replace item (9) in the list in 7.1.12p1 [10-007r1:152:9]: (9) "a previously declared kind type parameter of the type being defined," SUBMITTED BY: Van Snyder HISTORY: 12-172 m199 F08/0083 submitted - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed as amended by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0084 TITLE: Pointer arguments to PURE functions KEYWORDS: PURE function, POINTER, INTENT(IN) DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following subprogram: Real Pure Function F( X ) Real,Pointer :: X Real :: F f = 1.0 x = 2.0 ! (A) Nullify(x) ! (B) End Function F This subprogram does not conform to Fortran 2003, because both statements (A) and (B) violate constraint C1272 which says "C1272 In a pure subprogram any designator with a base object that ... is a dummy argument of a pure function ... shall not be used ... [in] a variable definition context ...". However, the corresponding constraint in Fortran 2008, C1283, is missing the condition that applies the constraint to a dummy argument of a pure function, except when it has INTENT(IN). Thus the statements marked (A) and (B) do not violate C1283, and therefore this subprogram appears to conform to Fortran 2008. Was this subprogram intended to be standard-conforming? ANSWER: No, this subprogram was not intended to be standard-conforming. An edit is supplied to re-insert the omitted condition. EDIT to 10-007r1: [312:31] In 12.7, constraint C1283, after "association", insert ", is a dummy argument of a pure function". SUBMITTED BY: Tobias Burnus HISTORY: 12-174 m199 F08/0084 submitted 12-174r1 m199 Revised 12-174r2 m199 Passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0085 TITLE: Problems with PARAMETERs KEYWORDS: PARAMETER DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: (1) Consider the program fragment Subroutine s Parameter (n=1) Integer :: x,n !(A) Parameter (x=3) The type declaration statement marked "!(A)", declares the entities X and N to be of type INTEGER. Furthermore, as we see by the immediately preceding and following PARAMETER statements, both X and N are named constants. Unfortunately, a constraint says C507 (R503) "An shall appear if the entity is a named constant (5.3.13)." (BTW, R503 is .) Therefore one concludes that the type declaration statement marked "!(A)" is not conforming as it violates C507 for both X and N. Is this statement intended to be conforming? (2) Firstly, consider Subroutine s2(n) Integer,Parameter :: x(n:n+1) = [ 1,2 ] Character(n),Parameter :: y = 'abc' ... The type declaration statements are not conforming because according to 5.2.2p1, X and Y are automatic data objects, and C506 says that shall not appear in that case. Now consider Subroutine s2b(n) Implicit Character(n) (a-z) Parameter (y = 'abc') Integer :: x(n:n+1) Parameter(x=[1,2]) This is not valid Fortran 2003, because 5.2 contains the requirement: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. This also applies to PROCEDURE, EXTERNAL, and INTRINSIC statements." This requirement does not appear in F2008. However, there is no indication in the Introduction of this new feature. Is this extension to Fortran 2003 deliberate? ANSWER: (1) Yes, the type declaration statement was intended to be allowed. An edit is supplied to correct this mistake. (2) No, the omission of this requirement was inadvertent. An edit is supplied to correct this mistake. EDITS: [88:14] In 5.2.1, Replace constraint "C507 (503)" completely with "C507 (R501) If the PARAMETER keyword appears, shall appear in each ." {Fix Q1.} [88:14+] In 5.2.1, immediately after constraint C507, insert new constraint: "C507a An expression that specifies a length type parameter or array bound of a named constant shall be a constant expression." {Fix Q2.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-189 m199 F08/0085 submitted 12-189r1 m199 Passed by J3 meeting 13-237 m200 Failed as amended by J3 letter ballot #27 13-203 13-239 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0086 TITLE: Implied-shape and separate PARAMETER statement KEYWORDS: Implied-shape, PARAMETER DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Consider Program test1 Character(*) a,b(*) Dimension c(*) Parameter (a='123', b=['1','2','3']) Character(*),Parameter :: c = [ '44','55','66' ] Print *,a,b,c End The definition of the assumed-length character named constant A conforms to Fortran 77 to Fortran 2008. However, the definition of the implied-shape named constant B appears not to conform to Fortran 2008, as the standard says in 5.4.11p2 "A named array constant defined by a PARAMETER statement shall have its shape specified in a prior specification statement." On the other hand, the named constant C does not have such a requirement, so its definition would appear to be conforming. This apparent requirement on the named constant B would thus appear to be inconsistent with those on the named constant C, as well as inconsistent with the way that assumed length works, and with the general principle of allowing attributes to be specified either in a single type declaration statement or with separate specification statements. Is the program intended to conform to the Fortran standard? Q2. Consider Subroutine test2(a) Real,Dimension(*) :: a,c Parameter (c = [ 45.6 ]) a(:size(c)) = c End Subroutine The in the type declaration statement is ambiguous; if it is an then the declaration of A as an assumed-size array is erroneous, but if it is an then the declaration of C as an implied-shape array is erroneous. Is this program-unit intended to be standard-conforming? ANSWER: A1. Yes, the program was intended to conform to the Fortran standard. An edit is provided to modify the requirement for prior specification so as to allow this case. A2. Yes, the program is intended to conform to the Fortran standard. An edit is provided to add syntax to permit this unambiguously. EDITS to 10-007r1: [94:10] 5.3.8.1, R515, Change "" to "". {This will be the unambiguous implied-shape syntax.} [94:10+] Insert new production "<> ". {This will be the otherwise-ambiguous syntax.} [95:32] 5.3.8.5p1 Replace sentence "An assumed-size array is declared with an ." with "A dummy argument is declared to be an assumed-size array by an or an ." {Now two ways of declaring assumed size.} [95:33] After "<>" insert ",". {The unambiguous case starts with an .} [95:37+] Insert new BNF rule and constraint "R521a <> [ : ] * C534a An object whose array bounds are specified by an shall be a dummy data object or a named constant." {The otherwise-ambiguous case. Note careful wording.} [96:24-25] 5.3.8.6p1 Replace sentence "An implied-shape array ... ." with "A named constant is declared to be an implied-shape array by an or an ." {Now two ways of declaring implied shape.} [96:26] R522, append ", [ [ : ] * ]...". {This is now the unambiguously implied-shape spec.} [107:11] 5.4.11p1 "shape" -> "rank". {In the PARAMETER statement, only require the rank to be specified in a prior specification statement.} NOTES ON THE EDITS: (1) Since "[ : ] *" now appears 4 times, it might make sense to define a BNF term for it, e.g. , and use that term in those places instead. (2) The current wording of C533 is slightly defective, as it does not clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as how that does indeed declare "the array bounds of a dummy data object". C533 should probably be reworded similarly to C534a. SUBMITTED BY: Bill Long HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm Cohen - passed by J3 meeting 13-237 m200 Failed letter ballot 13-235 m200 Revised with straw votes 13-235r1 m200 Passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0087 TITLE: Mixed-kind character assignment KEYWORDS: Mixed kind, character assignment DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: For a processor that supports both ASCII and ISO 10646 UCS-4 character kinds, assuming without loss of generality that Selected_Char_Kind('ASCII') is equal to 1 and that Selected_Char_Kind('ISO_10646') is equal to 10646, consider the following program: Module charkinds Integer,Parameter :: ascii = 1 Integer,Parameter :: ucs4 = 10646 End Module Module overload Use charkinds Interface Assignment(=) Module Procedure char_asg End Interface Contains Subroutine char_asg(a,b) Character(*,ascii),Intent(Out) :: a Character(*,ucs4),Intent(In) :: b Do i=1,Min(Len(a),Len(b)) a(i:i) = Achar(Mod(Iachar(b(i:i))+1,127)) End Do a(i:) = Repeat('*',Len(a)-Len(b)) End Subroutine End Module Program test Use overload Character(10,ascii) x x = ucs4_'Hello' Print *,'"',x,'"' End Program This program conforms to Fortran 95, which permitted user-defined assignment between all characters with different kinds. However, Fortran 2008 provides intrinsic assignment between ISO 10646 characters and ASCII characters, so user-defined assignment is not permitted (12.4.3.4.3 and Table 7.8). Thus there seems to be a contradiction between the Fortran 95 compatibility description in 1.6.3 and 12.4.3.4.3. Is the program intended to conform to Fortran 2008? And if it does, does it print "Hello " (intrinsic assignment) "Ifmmp*****" (user-defined assignment)? ANSWER: The program was not intended to conform to the standard. An edit is provided to remove the contradiction. EDITS: [24:14] 1.6.3p1, "Any" -> "Except as identified in this subclause, any". {No longer true.} [24:15] Split the sentence "The ..." introducing the list into a separate paragraph (which will be the third paragraph), and insert a new paragraph (as the second paragraph) as follows: "Fortran 95 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} [25:2+] 1.6.4, after p3, insert a new paragraph. "Fortran 90 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} SUBMITTED BY: Van Snyder HISTORY: 13-204 m200 F08/0087 submitted 13-204r1 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- NUMBER: F08/0088 TITLE: Can ALLOCATE with SOURCE= have side-effects in a PURE proc? KEYWORDS: Allocate, SOURCE=, PURE, side-effects DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: On comp.lang.fortran Ian Harvey brought up a pointer/PURE question. Given a type definition like type :: int_ptr integer, pointer :: i end type int_ptr And a PURE function like PURE function FUN (arg) type(int_ptr), intent(in) :: arg type(int_ptr), allocatable :: tmp FUN = 1 allocate (tmp, source=arg) tmp%i = 2 end function fun Is FUN standard conforming? Doesn't the use of source=arg allow the function to modify a global entity via the tmp%i = ...? There don't seem to be any constraints on what arg%i can point to, which means that the assignment to tmp%i can have side effects. Note that C1283(1) prevents usage like arg%i = 2 ANSWER: This was not intended to be standard-conforming. An edit is supplied to remedy this oversight. EDITS: [312:37] Delete "or" and add a new item "(4a) as the in a SOURCE= clause if the designator is of a derived type that has an ultimate pointer component, or" SUBMITTED BY: Dick Hendrickson HISTORY: 13-226 m200 F08/0088 submitted 13-226r1 m200 Edits added - passed by J3 meeting 13-262 m201 Passed J3 leter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ---------------------------------------------------------------------- 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/0090 TITLE: What restrictions apply to initialization and PARAMETER? KEYWORDS: PARAMETER, initialization, conformable, type conversion DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the programs Program m200c3_1 Integer :: a(10,10) Parameter (a = [ (i,i=1,100) ] ) Print *,a End Program Program m200c3_2 Parameter (b = 'ok') Print *,b End Program Program m200c3_3 Integer :: x(23) = [ 1 ] Print *,x End Program Program m200c3_4 Integer :: y = 'ok' Print *,y End Program The PARAMETER statement for the named constant A has an expression whose shape does not conform with that of A. The PARAMETER statement for the named constant B has an expression whose type does not conform to that of B. The for X is not conformable in shape. The for Y is not conformable in type. There appears to be no requirement either for shape or type conformance, in Fortran 2008 or in previous Fortran standards, except for initializing data pointers. Q1. Do any of these programs conform to Fortran 2008? Q2. If there is meant to be a requirement for the shapes to conform or for the types to be convertible, should this not be a constraint? ANSWER: A1. No, these programs do not conform to Fortran 2008, as no interpretation is established for any of them. Edits are provided to clarify this. A2. This is not a constraint. A future revision of Fortran might choose to mandate diagnosis of these errors. EDIT to 10-007r1: [88:30+] 5.2.1 Syntax, Insert new paragraph at end of subclause "If appears for a nonpointer entity, - its type and type parameters shall conform as specified for intrinsic assignment (7.2.1.2); - if the entity has implied shape, the rank of shall be the same as the rank of the entity; - if the entity does not have implied shape, shall either be scalar or have the same shape as the entity.". [107:12+] 5.4.11 PARAMETER statement, after p2, Insert new paragraph "The constant expression that corresponds to a named constant shall have type and type parameters that conform with the named constant as specified for intrinsic assignment (7.2.1.2). If the named constant has implied shape, the expression shall have the same rank as the named constant; otherwise, the expression shall either be scalar or have the same rank as the named constant.". SUBMITTED BY: Malcolm Cohen HISTORY: 13-229 m200 F08/0090 submitted - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 ------------------------------------------------------------------------ NUMBER: F08/0091 TITLE: Derived type with no components KEYWORD: Derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Program m7_1 Type empty End Type Type(empty),Target :: x Type(empty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? According to 16.5.3.2p2, item 1 is default integer etc, N/A item 2 is double precision etc, N/A item 3 is default character, N/A item 4 is C character, N/A item 5 is SEQUENCE type, N/A According to item (6), "a nonpointer scalar object of any type not specified in items (1)-(5) occupies a single unspecified storage unit that is different [from everything else]" If that analysis is correct, X occupies a single unspecified storage unit, not zero storage units, and therefore T should be printed. Q2. Consider Program m7_2 Type sempty Sequence End Type Type(sempty),Target :: x Type(sempty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? Now X falls into item 5, which makes it a "sequence of storage sequences corresponding to the sequence of its ultimate components"; there are no ultimate components, this makes it a zero-sized storage sequence and therefore F should be printed. This does not seem to be consistent with the apparent answer to Q1. Q3. Consider Program m7_3 Type numeric_empty Sequence End Type Type character_empty Sequence End Type Type(numeric_empty) a Integer b Character c Type(character_empty) d Equivalence(a,b) ! E1. Equivalence(c,d) ! E2. End Is this program conforming? According to the definitions in 4.5.2.3, NUMERIC_EMPTY is a numeric sequence type and therefore one might expect to be able to EQUIVALENCE it to an INTEGER. Similarly, CHARACTER_EMPTY is a character sequence type and therefore one might expect to be able to EQUIVALENCE it to a CHARACTER. However, NUMERIC_EMPTY is clearly also a character sequence type, and therefore statement E1 violates C592 because B is not character or character sequence. Similarly, CHARACTER_EMPTY is clearly also a numeric sequence type, and therefore statement E2 violates C591. It seems very strange to have a type that is simultaneously numeric and character sequence type. Q4. Consider Program m7_4 Type numeric_empty_2 Sequence Real c(0) End Type Type character_empty_2 Sequence Character(0) c End Type Type(numeric_empty_2) a Integer b Character c Type(character_empty_2) d Equivalence(a,b) ! E3. Equivalence(c,d) ! E4. End Does this program conform? According to the definitions in 4.5.2.3, NUMERIC_EMPTY_2 is a numeric sequence type and not a character sequence type, and conversely CHARACTER_EMPTY_2 is a character sequence type and not a numeric sequence type, and therefore the constraints for the statements at E3 and E4 are not violated. Thus this appears to be conforming, in contradiction to the example in Q3, even though the storage sequence of NUMERIC_EMPTY, NUMERIC_EMPTY_2, CHARACTER_EMPTY, and CHARACTER_EMPTY_2 are all the same. This does not look very consistent with the situation in Q3. ANSWER: A1. The program is conforming and prints T. A2. The program was not intended to conform; SEQUENCE makes no sense when there are no components. An edit is needed to correct this. A3. The program does not conform as a sequence type must have at least one component. A4. The program is conforming. The apparent design inconsistency is not an error in the standard. EDIT to 10-007r1: [62:19] 4.5.2.3, in constraint C436 After "appears," insert "the type shall have at least one component,". SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-266 F08/0091 submitted m201 13-266r1 Revised - passed by J3 meeting m202 13-313 Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0092 TITLE: Derived type parameter requirements KEYWORD: Derived type parameter DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Type t1(a,a) Integer,Kind :: a Integer,Len :: a End Type Type t2(a) Integer,Kind :: a,a,a End Type These type definition appears to valid, in that (a) there is no requirement that a type parameter appears only once in the ; (b) there is no requirement that a type parameter appears in only one , and only once. Were these intended to be valid? What is their meaning? ANSWER: These were not intended to be valid, and they are not valid because the standard does not establish an interpretation for them. Unique names for type parameters can possibly be deduced from the scoping rules. Edits are supplied to make the requirements explicit. EDITS to 10-007r1: [61:19+] In 4.5.2.1, after C427 insert new constraint "C427a (R426) The same shall not appear more than once in a ." {Require unique names for type parameters.} [64:8] In 4.5.3.1, C438, after "shall appear" insert "exactly once". {Forbid multiple declarations of a type parameter, whether in the same or more than one.} SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-267 F08/0092 submitted - passed by J3 meeting m202 13-313 Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0093 TITLE: Process exit status and error termination KEYWORD: ERROR STOP DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Many operating systems today (e.g. Posix-related ones) use a process exit status of zero to indicate successful execution, whereas nonzero indicates an error. (Occasionally nonzero values, e.g. 1, also indicate success.) Fortran STOP and ERROR STOP with an integer are recommended to use the as the exit status. The STOP statement without an integer is recommended to have an exit status of zero; this conforms to common practice since STOP initiates normal termination. The standard is silent on the effect of error termination, except in the case of an ERROR STOP (sans integer ) which is unexpectedly recommended to also return an exit status of zero. Q1. Is this intentional? Should the exit code for ERROR STOP not have been recommended to be nonzero? Q2. Should the recommendation for an ERROR STOP not also apply to error termination by other causes? ANSWER: A1. It was not intended to recommend returning "success" for error termination. An edit is supplied to correct this. A2. Yes, the recommendation for an ERROR STOP without an integer should also apply to other means of standard-defined error termination. An edit is supplied to correct this omission. EDIT to 10-007r1: [33:36+] 2.3.5, before Note 2.7, insert new note "NOTE 2.6a If the processor supports the concept of a process exit status, it is recommended that error termination initiated other than by an ERROR STOP statement supplies a processor-dependent nonzero value as the process exit status." {Recommendation for error termination other than by ERROR STOP.} [188:10+10] In 8.4, Note 8.30, Before "is of type character or does not appear" Insert "in a STOP statement". {Limit zero recommendation to STOP, not ERROR STOP.} [188:10+11+] At the end of Note 8.30, insert new paragraphs "If the in an ERROR STOP statement is of type character or does not appear, it is recommended that a processor-dependent nonzero value be supplied as the process exit status, if the processor supports that concept." {Specify nonzero exit for ERROR STOP.} [460:24+] Annex A, after "STOP or ERROR STOP" insert new bullet "the recommended process exit status when error termination is initiated other than by an ERROR STOP statement with an integer (2.3.5);" {Probably unnecessary, seeing how it is only a recommendation, but maybe a good idea anyway.} SUBMITTED BY: Bill Long/Malcolm Cohen HISTORY: m201 13-268 F08/0093 submitted - passed by J3 meeting m202 13-313 Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0094 TITLE: Procedure statement and double colon KEYWORD: PROCEDURE, Interface block DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Fortran 2003 did not permit a double colon in the in an interface block. Fortran 2008 syntax seems to allow this, but it is not mentioned in the Introduction as a new F2008 feature. Is this apparent new feature deliberate? ANSWER: Yes, this new feature was intended. An edit is provided to add mention of it to the Introduction. EDIT: [xvi] Introduction, p2, "Programs and procedures:" bullet, After "empty CONTAINS section is allowed." Insert "A PROCEDURE statement can have a double colon before the first procedure name." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-274 F08/0094 submitted - passed by J3 meeting m202 13-313 Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0095 TITLE: Is PRESENT allowed in specification and constant expressions KEYWORD: PRESENT, optional dummy argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Subroutine s1(a) Integer,Optional :: a Logical,Parameter :: x = Present(a) Print *,x End Subroutine Does this program unit conform to the standard? 7.1.12 item (4) permits "a specification inquiry where each designator or function argument is ... (b) a variable whose properties inquired about are not (i) assumed, (ii) deferred, or (iii) defined by an expression that is not a constant expression," PRESENT is a specification inquiry (because it is an intrinsic inquiry function), and the standard does not say that the "presence" of an optional dummy argument is an assumed or deferred attribute, and it does not appear to be "defined by an expression" either. On the other hand, the standard does not say anything about what kind of property the presence is. Q2. Consider Subroutine s2(a) Integer,Optional :: a Real x(Merge(2,3,Present(a))) If (Present(a)) Then x = [ 1,2,a ] Else x = [ 1,2 ] End If Print *,x End Subroutine Does this program unit conform to the standard? It appears to satisfy the rules for specification expression, similarly to how it satisfies the rules for a constant expression, but then the standard is silent as to what sort of property "presence" is... Q3. Consider Subroutine s3(a) Character(*),Optional :: a Real x(Len(a)) Print *,Size(x) End Subroutine Does this program unit conform to the standard? Using the same reasoning as Q1 and Q2, it appears to conform, but if A is absent, LEN(A) is not permitted by 12.5.2.12. ANSWER: A1. Program unit S1 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. A2. Program unit S2 was intended to conform to the standard. An edit is provided to clarify that this is valid. A3. Program unit S3 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. EDITS to 10-007r1: [150:24] 7.1.11p2, item (9)(b) after "variable" insert ",that is not an optional dummy argument, ". {Prevent specification enquiries on optional dummy arguments.} [150:27+] 7.1.11p2, after item (9) entirely, insert "(9a) a specification inquiry that is a constant expression, (9b) a reference to the intrinsic function PRESENT," {Allow inquiries on optional dummy arguments that will not violate the rules in 12.5.2.12 when the dummy is absent, and allow PRESENT to be used.} [150:37] 7.1.11p4, item (1) after "intrinsic inquiry function" insert "other than PRESENT". {Remove PRESENT from list of specification inquiries, this fixes constant expressions.} SUBMITTED BY: Malcolm Cohen/Van Snyder HISTORY: m201 13-278 F08/0095 submitted m201 13-278r1 Passed by J3 meeting m202 13-313 Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0096 TITLE: Is VALUE permitted for an array in a BIND(C) procedure? KEYWORD: array, BIND(C), VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTERFACE SUBROUTINE s(a) BIND(C) USE ISO_C_BINDING REAL(C_float),VALUE :: a(100) END END INTERFACE Q1. Does this interface conform to the Fortran standard? Q2. If so, what prototype does it interoperate with? ANSWER: A1. C does not have arrays that are passed by value, so this was not intended to conform to the Fortran standard. An edit is provided to clarify this. A2. This question is moot. EDITS to 10-007r1: [306:31] 12.6.2.2, C1255, after "(15.3.5, 15.3.6)" insert "that is not an array with the VALUE attribute," {Do not permit BIND(C) to have arrays by value.} {Note: TS 29113 replaces this same constraint.} [433:12] 15.3.7p2, item (4), after "any" insert "scalar". {Do not describe arrays by value in a prototype.} SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-284 F08/0096 submitted - passed by J3 meeting m202 13-313 Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0097 TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)? KEYWORD: TYPE, CHARACTER DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER*1, A TYPE(CHARACTER*1,) B The optional comma in the declaration of B looks ugly. Is this deliberate? ANSWER: No, this syntax was inadvertently allowed. An edit is provided to remove it. EDITS to 10-007r1: [51:26+] 4.3.1.1, after C406, insert new constraint "C406a (R403) In TYPE() the shall not end with a comma." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-285 F08/0097 submitted - passed by J3 meeting m202 13-313 Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0098 TITLE: How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? KEYWORD: LOCK DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider LOCK ( x, ACQUIRED_LOCK=n1, ACQUIRED_LOCK=n2, STAT=n3, STAT=n4 ) Is this conforming? Multiple STAT= are prohibited from a , but this is a so that does not apply. There is no constraint anywhere about how many ACQUIRED_LOCK= specifiers may appear. ANSWER: No, this was not intended to be conforming. No specifier was intended to be allowed to appear more than once. EDITS to 10-007r1: [194:2+] 8.5.6, after R864, insert new constraint "C852a No specifier shall appear more than once in a given ." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-286 F08/0098 submitted - passed by J3 meeting m202 13-313 Passed by J3 letter ballot 13-297 ----------------------------------------------------------------------