J3/12-006A Outstanding Fortran Interpretations, May 6, 2012 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 + add results of m196 J3 letter ballot #24 11-229/241 + add results of WG5 ballots 1 and 2 N1876/N1878 and N1877/N1889 + delete text of interps in F08 Corrigendum 1 + add 5 interps answers from m196 + add 23 interp answers from m197 [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 N S T number title - - - ------ ----- * P E F90/0145 Expressions in of a FUNCTION statement ------ * M I F03/0017 Dummy procedure pointers and PRESENT * M C F03/0018 Multiple identical specific procedures in type-bound generic interfaces * M E F03/0019 Multiple identical specific procedures in generic interface blocks * M E F03/0021 What kind of token is a stop code? * P E F03/0030 IEEE divide by zero * P E F03/0042 IEEE funny values and Standard real generic intrinsic procedures * M C F03/0046 Unlimited polymorphic pointers in common blocks * P E F03/0047 Polymorphic arguments to intrinsic procedures d C1 E F03/0048 Control edit descriptors in UDDTIO * P E F03/0051 Repeat specifiers and UDDTIO * M E F03/0053 The BIND attribute for C_PTR and C_FUNPTR * P E F03/0059 Structure components in namelist input * P E F03/0064 Recursive declaration of procedure interfaces * M I F03/0065 Relational equivalence * M 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 * M E F03/0096 Can a read statement change the unit value? * P E F03/0100 Error in field width for special cases of signed INFINITY output * M 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 * M I F03/0116 indistinguishable specifics for a generic interface with use association * M E F03/0118 Are lower bounds of assumed-shape arrays assumed? * M E F03/0120 When are parameterized sequence types the same type? * M C F03/0121 Precise FP semantics of the REAL intrinsic d C1 I F03/0123 Implicit typing in derived types d C1 E F03/0124 definition is poorly defined d C1 I F03/0128 Subobjects in namelist output * P 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? * M 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? * M 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 * M E F08/0031 PURE INTENT(OUT) finalization * M 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 * M C F08/0038 Are pointless restrictions on DIM arguments intended? d C1 E F08/0039 Many-one vector subscript usage * M E F08/0040 MOVE_ALLOC for coarrays * P E F08/0041 Segment ordering rules * M E F08/0042 SOURCE= questions * M 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 * M 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 * M E F08/0054 Requirements for needing an explicit interface * M E F08/0055 G editing for reals * M E F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE= * M E F08/0057 Interoperability with empty types * M E F08/0058 ENTRY point RESULT variable * M E F08/0059 Auto-targetting requirements * M E F08/0060 Procedure pointer assignment with an EXTERNAL target * M E F08/0061 Description of the CONTIGUOUS attribute misworded? * M C F08/0062 Mixing default initialization with DATA initialization * M I F08/0063 G editing to a narrow output field * M E F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE * M E F08/0065 Should certain procedures in intrinsic modules be pure? * M E F08/0066 Are certain expressions with pointer initialization constant? * M E F08/0067 Passing arrays of extended type objects * M E F08/0068 Pointer association and extended type arrays * M E F08/0069 Which part of an effective argument becomes undefined? * M E F08/0070 Finalization of INTENT(OUT) arguments * M E F08/0071 Vector subscript target * M E F08/0072 Final subroutines with corank * M E F08/0073 Polymorphic auto-targetting ====================================================================== 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/0017 TITLE: Dummy procedure pointers and PRESENT KEYWORDS: Dummy argument, procedure pointer, PRESENT DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the Fortran standard? procedure(real), pointer :: F => null() call s ( f ) contains subroutine S ( F ) procedure(real), optional, pointer :: F print *, present(f) end subroutine S end In the Fortran 2003 standard (ISO/IEC 1539-1:2004), the second paragraph of 12.4.1.3 requires that if the dummy argument does not have the POINTER attribute and the actual argument does, the actual argument shall be associated. It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute. ANSWER: The program is standard-conforming. The Fortran 2008 standard states "Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a nonoptional nonpointer dummy argument shall be pointer associated with a target." (12.5.2.3 paragraph 1). Since PRESENT is an intrinsic inquiry function, there is therefore no requirement on its actual argument that if it is a pointer it shall be associated. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 04-402 m170 F03/0017 submitted 04-402r2 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-213 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic KEYWORDS: Type-bound generic DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Q1. Does the following program unit conform to the Fortran standard? module M1 type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T type X real q contains procedure, pass(b) :: MyAdd_x => myadd generic :: operator(+) => myAdd_x end type X contains integer function MyAdd ( A, B ) class(t), intent(in) :: A class(x), intent(in) :: B myadd = a%x + b%q end function MyAdd end module Q2. Does the following program unit conform to the Fortran standard? module M2 interface operator(+) procedure MyAdd end interface type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T contains integer function MyAdd ( A, B ) class(t), intent(in) :: A real, intent(in) :: B myadd = a%x + b end function MyAdd end module Q3. If the interface block and type definition are exchanged in question 2, does the program unit conform to the Fortran standard? ANSWER: A1. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific bindings, one to myadd_t the other to myadd_x. A2. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific procedures, one being the module procedure myadd the other being the type-bound procedure myadd_t. A3. The ordering of the interface block and the type definition is immaterial. EDITS to 10-007r1: None SUBMITTED BY: Van Snyder HISTORY: 04-405 m170 F03/0018 submitted 04-405r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-214 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Module m12 Interface g1 Subroutine s End End Interface Interface g2 Procedure s End Interface End Module Program p12 Use m12 Interface g1 ! (1) Procedure s End Interface Interface g2 ! (2) Procedure s End Interface Call g1 Call g2 End Program It is clear that the interface block marked (2) is not conforming, since it violates C1209 which says "A procedure-name shall not specify a procedure that is specified previously in any procedure-stmt in any accessible interface with the same generic identifier." However, it is not clear whether the interface block marked (1) is conforming, since s was specified previously by an interface-body not a procedure-stmt, even though both (1) and (2) attempt to do the same thing, viz create a generic interface with a duplicate specific. An even more obscure example is Module mx12 Interface g3 Subroutine s End End Interface Private s End Program px12 Use mx12 Interface g3 Subroutine s End End Interface Call g3 End Program Here there is clearly no violation of C1209 but it is not obvious whether the ambiguity rules are applied or not. ANSWER: These examples were not intended to be conforming. An edit is supplied to clarify. EDITS to 10-007r1: [281:11-12] Replace C1209 entirely by "C1209 (R1201) An in a generic interface block shall not specify a procedure that is specified previously in any accessible interface with the same generic identifier." SUBMITTED BY: Van Snyder HISTORY: 04-406 m170 F03/0019 submitted 04-406r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-221 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The , when it is a string of s, does not appear to be specified by the standard to be any particular kind of token. Or indeed whether it is one token per or one per . The answer to these questions determines whether blanks are allowed, disallowed, or optional, in the middle of a STOP statement in free form. Consider the following statements: (1) STOP 123 (2) STOP123 (3) STOP 1 2 3 Which, if any, of these statements are standard-conforming? ANSWER: Fortran 2008 has revised the syntax of the STOP statement. The is now a scalar integer constant expression or a scalar default character constant expression. Therefore only statement (1) is standard-conforming in free form. EDITS to 10-007r1: None. SUBMITTED BY: Malcolm Cohen HISTORY: 04-416 m170 F03/0021 submitted - Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-212r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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 result of the operation or conversion, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. 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 result of the division, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. 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 F03/0030 Cohen comment: Van's comment on 13.7.1 also being wrong is well taken, but refers to an issue that is separate from that considered by the interpretation. In my opinion 13.7.1 should be fixed in a separate interp, e.g. F08/0008 which actually does ask about intrinsic functions. Corbett NO vote The proposed interpretation and edits make no sense unless one assumes that the intent is to redefine and repurpose the function IEEE_SUPPORT_DATATYPE. If that is the intent, the interpretation and edits should address the issue directly instead of modifying seemingly unrelated text. Reid NO vote I agree with Bob Corbett that it is inappropriate to refer to IEEE_SUPPORT_DATATYPE since 14.9 makes it clear that support requires: "for at least one rounding mode, the intrinsic operations of addition, subtraction and multiplication shall conform whenever the operands and result specified by IEC 60559:1989 are normal numbers". To avoid a conflict with IEC 60559:1989, I suggest that the words in the first two bullets points of 14.3 be changed to apply only to cases where the operands are normal numbers. Snyder NO vote Edits could be construed to introduce a contradiction between 13.7.1 and 14.3. My vote would be yes if the penultimate sentence of 13.7.1p2 began "If support is provided and an infinite result...." ---------------------------------------------------------------------- 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/0046 TITLE: Unlimited polymorphic pointers in common blocks KEYWORDS: Unlimited polymorphic pointer, common block DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the Fortran 2008 standard? PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM ANSWER: No. C5100 in Fortran 2008 prohibits unlimited polymorphic pointers in common. EDITS to 10-007r1: None. SUBMITTED BY: Rob James HISTORY: 05-137 m171 F03/0046 submitted - passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-216 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: Answer 1: Yes. Answer 2: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 3: (a) Yes. (b) Yes. (c) The requirements apply to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 5: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 6: Yes. Answer 7: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 8: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 9: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 10: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 11: (a) Yes. (b) No. (c) N/A. Answer 12: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 14: No. EDITS: [292:18+] Insert a new subclause 13.2 and re-number subsequent subclauses: 13.2 Polymorphic intrinsic function arguments and results Table 13.1 specifies the intrinsic functions that are allowed to have polymorphic arguments, and the arguments that are allowed to be polymorphic. Table 13.1: Polymorphic intrinsic function arguments --------------------------------------------------------------- | Function name | Arguments permitted to be polymorphic | =============================================================== | ALLOCATED | ARRAY, SCALAR | | ASSOCIATED | POINTER, TARGET | | CSHIFT | ARRAY | | EOSHIFT | ARRAY, BOUNDARY | | EXTENDS_TYPE_OF | A, MOLD | | LBOUND | ARRAY | | MERGE | TSOURCE, FSOURCE | | MOVE_ALLOC | FROM, TO | | PACK | ARRAY, VECTOR | | RESHAPE | SOURCE, PAD | | SAME_TYPE_AS | A, B | | SHAPE | SOURCE | | SIZE | ARRAY | | SPREAD | SOURCE | | TRANSFER | SOURCE | | TRANSPOSE | MATRIX | | UBOUND | ARRAY | | UNPACK | VECTOR, FIELD | =============================================================== The intrinsic functions shown in table 13.2 have a polymorphic result if and only if the specified argument is polymorphic. Where the result is specified to have the same type and type parameters as the argument specified in table 13.2, the result has the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic the result is unlimited polymorphic; otherwise it has the same declared type as the specified argument. If another argument is required to have the same type as the specified argument, it shall be polymorphic if and only if the specified argument is polymorphic, and have the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic, the other argument shall also be unlimited polymorphic; otherwise, it shall have the same declared type as the specified argument. Table 13.2: Polymorphic intrinsic function results ------------------------------------------------ | Function name | Argument that determines | | | result characteristics | ------------------------------------------------ | CSHIFT | ARRAY | | EOSHIFT | ARRAY | | MERGE | TSOURCE | | PACK | ARRAY | | RESHAPE | SOURCE | | SPREAD | SOURCE | | TRANSPOSE | MATRIX | | UNPACK | VECTOR | ================================================ 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 Malcolm Cohen NO vote on F03/0047 Many of the answers seem to be incorrect or unjustified, and the edits are deficient and in poor style. Answer 4(c) is, I believe, incorrect. It is certainly inconsistent with the philosophy of the type extension facility in Fortran 2003. 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? Answer 4: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. - This answer would imply that the EXTENDS_TYPE_OF intrinsic is unsafe to use on unlimited polymorphic arguments, because it could give type errors at runtime. This is something that we have strenuously tried to avoid in the type extension facility (as shown by the provision of such things as the SELECT TYPE construct). - Furthermore, the requirements CANNOT be satisfied by a disassociated or unallocated unlimited polymorphic, because such an entity has NO DYNAMIC TYPE. (The Result Value clause makes it clear that support for these was intended.) Therefore the requirements are, in fact, faulty. The answer should be (c) The requirements refer to the declared type, but are faulty in that they do not take unlimited polymorphic pointers into account. Edit: [316:16,17] Change "an object of extensible type" to "an object that is unlimited polymorphic or of extensible declared type". Answer 5(b) is not justified by the current text in the standard, and I see no reason to create such a requirement. 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? Answer 5: (a) Yes. (b) Yes. - There is no justification, and no need, for this unnecessary restriction. Not only is it unnecessary, it inhibits use of MERGE when some variables are polymorphic. If the requirements refer to both the declared type and the dynamic type, that is sufficient to make MERGE useful. (c) The requirements refer to both the declared type and the dynamic type. - I agree that this should be the case. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. - And this answer should be that if BOTH arguments are polymorphic, the result is polymorphic. If only one is polymorphic, the result need not be as the declared and dynamic type are known to be one and the same. Similar considerations lead me to question answer 7(b) and 7(d), 8(b) and 8(d), 13(b) and 13(d). Answer 9(c) is deficient and contradicted by the (currently faulty!) text of the standard, in the same way that answer 4(c) is: 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? Answer 9: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. - The requirements CANNOT refer to the dynamic type because a disassociated unlimited polymorphic does not have one. - The standard does not mention unlimited polymorphics in this subclause; that is because the result for a disassociated unlimited polymorphic is rather obvious (follows directly from the existing text) and does not need to be a special case. - The requirement "of extensible type" is faulty and should be repaired in the same way as EXTENDS_TYPE_OF. Answer 11(b) is not justified by existing text in the standard, and violates TRANSFER requirements. Question 11: (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? Answer 11: (b) No. - This contradicts [356:30-33] which requires, e.g. that (given suitable types and sizes) "... the value of TRANSFER(TRANSFER(E,D),E) shall be the value of E". Re the EDITS. I strongly object to the addition of these two tables to the standard. They are ad hoc and help no-one to decide whether a function that is not in these tables (e.g. the many vendor-extension intrinsics) should accept polymorphic arguments or not. Instead, the rules which underlie these tables must be exposed. For example, "An actual argument to an intrinsic function may be polymorphic only if the corresponding dummy argument accepts values of any type." and one could follow it up with something like: "If the result of an intrinsic function is specified to have the same type as that of one of its arguments, the result is polymorphic if and only if that argument is polymorphic, and is unlimited polymorphic if and only if that argument is unlimited polymorphic. In both cases the dynamic type of the result is that of the actual argument." Furthermore, I even more strongly object to arbitrary additional conditions on the dummy arguments of some functions being placed separately from the description of those functions. This just means the reader has to jump around inside the document quite unnecessarily. If clarifying text is required (as it doubtless is) in specific cases when it is not clear which of the dynamic and declared types is being referenced, I think there are two reasonable choices: (1) specify a rule like the above which allows the reader to deduce the answer, and which is extensible to new intrinsic functions, or (2) clarify the text in the function in question Or possibly even both if that is warranted. Addition of an ad hoc list of functions and arguments is unsatisfactory in this regard. ---------------------------------------------------------------------- NUMBER: F03/0051 TITLE: Repeat specifiers and UDDTIO KEYWORDS: repeat specifier, POS=, UDDTIO DEFECT TYPE: Erratum 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 not specify the behavior of a processor when a list directed input record contains a r*c constant, and that entire set of input values is not completely consumed by one list directed input statement. In particular, the file position for such an input file when the processor is in the middle of consuming an r*c value, and a child input statement is invoked, is not defined. This was an oversight. Edits are supplied to prohibit r*c constants in this case. The above program is not standard conforming. EDITS: [239:18-] Insert this paragraph just after note 10.28: "When the first value of an constant is transferred to a list item by a list-directed input statement, that input statement shall transfer all values of that constant to list items before causing any child input statement to be invoked. If that list-directed input statement is itself a child input statement, it shall transfer all values of that constant to list items before terminating." 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 Jim Xia's NO vote on F03/0051: While I agree with the spirit of the interp, the edit seems to have a problem. Consider the text in the edit marked between *** below: "When the first value of an constant is transferred to a list item by a list-directed input statement, that input statement shall transfer all values of that constant ***to list items*** before causing any child input statement to be invoked. If that list-directed input statement is itself a child input statement, it shall transfer all values of that constant ***to list items*** before terminating." There may not be enough list items to transfer all values to. I think the input statement should transfer as many (up to ) values as are available list items and then ignore (throw away) the rest. For example, for the program in the interp document: The first child input statement encounters 2*3. It will transfer a number 3 to dtv%i. There are no more list items to transfer the second 3 to, so I believe it should skip the second number 3. Here is another example, this time with the parent statement: PROGRAM foo USE m TYPE(t) :: a INTEGER :: i OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted') WRITE(10, '(A)') '2*3 5 6' REWIND(10) READ(10, *) i, a !<-- parent READ encounters 2*3 PRINT *, i, a%i, a%j, ipos END PROGRAM The parent statement is the first statement to encounter 2*3. It transfers 3 to i, but cannot transfer the second constant to a list item. At the beginning of the user-defined procedure, the file should be positioned just before the number 5 (i.e. the rest of the 2*3 is ignored). Otherwise, the problem with file position reappears. ---------------------------------------------------------------------- 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 J3 letter 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(C) attribute. 15.3.3 does not specify that they have the BIND(C) 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(C) 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(C) would not necessarily have allowed them in COMMON anyway. 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. EDITS to 10-007r1: [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)". [10-007r1:4.5.7.1p1 77:3] Insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," after "A derived type". 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 ---------------------------------------------------------------------- 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: J3 consideration in progress QUESTION: Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1212 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? ANSWER: No, this program is not standard-conforming. The interface name in a procedure declaration statement should not be permitted to be declared in a later interface body. An edit is supplied to correct this oversight. DISCUSSION: The edit changes C1212 to read: C1212 ... If is declared by a or it shall be previously declared." Example 1: MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE This is clearly invalid, since the declaration of "s" in the PROCEDURE statement is still in progress (until END SUBROUTINE) and therefore "s" which is being declared by an interface body is *NOT* previously declared. Example 2: MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE This is invalid because the interface body for S1 does not have access to S2. Furthermore, adding an IMPORT statement is ineffective because of the requirement "An entity that is imported ... and is defined in the host scoping unit shall be explicitly declared prior to the interface body." EDITS: All edits refer to 04-007. [264:22] Before "it shall", insert "or ". 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 Malcolm Cohen COMMENT for F03/0064 YES vote: The entire DISCUSSION section should be deleted as it is wrong. The answer does not address Rob James examples; these appear to continue to be problematic. Also consider MODULE m3 PROCEDURE(s),POINTER :: sptr CONTAINS SUBROUTINE s(p) PROCEDURE(sptr) :: p END SUBROUTINE END MODULE In the normal course of events one would like to allow PROCEDURE(module-procedure-name),POINTER :: mpptr since it is natural to want to provide a procedure pointer that matches a module procedure, so we should not just take away the ability to use a (later-defined) module procedure here. Rob James' suggestion of "The characteristics of a dummy procedure shall not depend on the characteristics of the procedure or interface body in which it is declared." would seem to catch all these examples. Unfortunately it breaks REAL(KIND=3) FUNCTION F(G) RESULT(R) REAL(KIND(R)),EXTERNAL :: G In any case, the dummy argument case is different (it's certainly trickier) and especially since there is not an obvious fix I would prefer us to fix the original problem as described in F03/0064 using the edit there, and discuss and debate how to solve the dummy procedure case separately. I thought about "The shall be previously declared or be the name of an accessible module procedure; if it is the name of a module procedure either the module procedure shall be previously defined or the PROCEDURE statement shall appear in the specification part of the module." which seems to fix Rob's examples but unfortunately not mine. The DISCUSSION section plus my additional example should be used to form a new interp request. Bill Long Comment for F03/0064: The text following Example 1 in the Discussion says "which is being declared by an interface body is *NOT* previously declared". But there is no interface body in Example 1. Similarly, Example 2 also has no interface bodies. The examples do not seem relevant to the topic of the ANSWER section. Maybe both examples should be deleted. Jim Xia NO comment on F03/0064: The edits do not apply to example 1 and 2 in the extended discussion. In both examples, module procedures are used. The term is not applicable to them as indicated by Note 12.3 on page 258 "An interface body cannot be used to describe the interface of an internal procedure, a module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit." Furthermore the discussion on example 2 is more confusing than useful because it refers to IMPORT statement. I can not see how the IMPORT statement is relevant to this example. ---------------------------------------------------------------------- NUMBER: F03/0065 TITLE: Relational equivalence KEYWORDS: Relational equivalence DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Given REAL X X = ... some value ... may IF( X+3.0 .EQ. 3.0 )... be transformed into IF( X .EQ. 0.0 )... by the processor? In Fortran 2003, 7.1.8.5 Evaluation of relational intrinsic operations says "Two relational intrinsic operations are relationally equivalent if their logical values are equal for all possible values of their primaries." On a machine where addition of 3.0 to a small value is not exact, the logical values for X+3.0==3.0 are not the same as X==0.0 for all possible values of X, therefore it would seem that this transformation would not be possible. However, Note 7.22 in Fortran 2003 shows this transformation as being acceptable. ANSWER: No, the transformation is not permitted unless it gives the same answer for all possible values (of X and X+3.0). The erroneous example has been removed in Fortran 2008. EDITS to 10-007r1: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-192 m173 F03/0065 submitted 09-150 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 11-222 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0084 TITLE: IEEE_SET_ROUNDING_MODE in a subroutine KEYWORDS: IEEE_ARITHMETIC DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 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 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it allowed to change the value of a variable which supplies the unit number to a read statement? 10-007 [243:3-5] says the value of any input/output specifier shall not depend on any input-item. UNIT= is a specifier in a READ statement. Note 9.40 on page 221 gives the example READ(N) N, X(N) and discusses how the changes to N work. ANSWER: Yes, the example was intended to be allowed as long as N is not an internal unit. Edits will limit the restriction to "output items" in the specifier list and the Format. EDITS to 10-007r1: In 9.12, paragraph 5, [243:3-4] Delete "on any , , or", Making that sentence read: "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." [243:5] Append new sentence to paragraph "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier shall not depend on the values of any or in the same statement." SUBMITTED BY: Dick Hendrickson HISTORY: 07-266 m181 F03/0096 submitted 07-266r1 m181 Draft answer - withdrawn, no reason, no vote 10-246 m193 Draft answer for F2008 10-246r1 m193 Revised edit - Passed by 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 11-257 m196 Revised edit 11-257r1 m196 Revised edit 11-257r2 m196 Revised edit 12-135 m197 Revised edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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? 228:36-37 describes the output for an IEEE infinity and special cases field widths of 3 and 8. But, the special casing doesn't consider the possibility of a plus or minus sign in the field. A signed infinity should be special cased for field widths of 9 and 4. 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: [228:36-37] In the paragraph beginning "For an internal value that is an IEEE infinity." in 10.6.1.2.1 "F editing" replace the final sentence 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 zero or is less than the minimum required but large enough to produce the form 'Inf', the form 'Inf' is output." [229:2] In the paragraph in 10.6.1.2.1 "F editing" covering the output of NaN values, replace the last sentence "If ... asterisks." 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 balot #5 N1722-N1726 F03/0100 summary of Jim Xia's issues: 1. The standard puts similar but somewhat different sentences in three places, which is inconsistent. Only one sentence (in E editing) is complete while the other two (one for integer editing, and one for F editing) are both incomplete. 2. As to the restriction on output being "NaN" for F editing when w == 0, I'm still not convinced it is to the best benefit to Fortran users given the fact that the majority of the processors today distinguish qNaNs vs. sNaNs. ---------------------------------------------------------------------- NUMBER: F03/0103 TITLE: Restrictions on dummy arguments not present for polymorphic type or parameterized derived type KEYWORDS: dummy argument, present, polymorphic, parameterized derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Type t Real x End Type ... Subroutine s(x) Class(t),Optional :: x If (.Not.Present(x)) Call s2(x) End Subroutine Subroutine s2(y) Type(t),Optional :: y If (Present(y)) Print *,y End Subroutine Q1. Is the reference to s2, passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy, standard conforming? Consider Type pdt(n) Integer,Len :: n Real x(n) End Type ... Subroutine s3(y) Type(pdt(*)),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Type(pdt(10)),Optional :: z If (Present(z)) Print *,z%x End Subroutine Q2. Is the reference to s4, passing an optional dummy argument with an assumed type parameter to an optional dummy argument with a non- assumed type parameter, standard conforming? Note that 12.5.2.4 paragraph 3 requires the length type parameter values to be the same (with no mention of argument presence). One might conjecture that these should not be conforming because the argument passing conventions between s and s2, and between s3 and s4, might be different (descriptor vs. reference). DISCUSSION: This does not seem to be limited to derived types, for example: Subroutine s3(y) Character(*),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Character(10),Optional :: z If (Present(z)) Print *,z End Subroutine ? ANSWER: These were all intended to be standard-conforming. An edit is supplied to correct the type parameter matching requirements. EDITS to 10-007r1: [293:6] 12.5.2.4, beginning of paragraph 3, insert new sentence "The kind type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument." and change "The type parameter values of the actual argument" to "The length type parameter values of a present actual argument". [293:10] 12.5.2.4, paragraph 4, before "scalar" insert "present". SUBMITTED BY: Jim Xia HISTORY: 07-298r1 m182 F03/0103 submitted 07-298r2 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 11-223 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0116 TITLE: indistinguishable specifics for a generic interface with use association KEYWORDS: GENERIC RESOLUTION USE ASSOCIATION DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot Consider the following program MODULE M1 INTERFACE SUBR MODULE PROCEDURE SUBR1 END INTERFACE CONTAINS SUBROUTINE SUBR1 END SUBROUTINE END MODULE M2 INTERFACE SUBR MODULE PROCEDURE SUBR2 END INTERFACE CONTAINS SUBROUTINE SUBR2 END SUBROUTINE END PROGRAM MAIN USE M1 CALL S CONTAINS SUBROUTINE S USE M2 CALL SUBR END SUBROUTINE END Is this program standard conforming? ANSWER: Subclause 12.4.3.4.5 of the Fortran 2008 standard forbids the presence of such conflicting interfaces. The rules in subclause 12.5.5.2 would be able to resolve the reference to SUBR in the example, but this fact does not negate the prohibition in subclause 12.4.3.4.5. EDITS to 10-007r1: None. SUBMITTED BY: Robert Corbett and Michael Ingrassia HISTORY: 08-169 m184 F03/0116 submitted 11-219r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 ---------------------------------------------------------------------- NUMBER: F03/0118 TITLE: Are lower bounds of assumed-shape arrays assumed? KEYWORDS: LBOUND, assumed-shape array, constant expression DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the 2008 Fortran standard? subroutine S ( A ) integer :: A(:,3:) integer, parameter :: R = size(lbound(A)) end subroutine S Processors disagree. If the lower bounds of an assumed-shape array are assumed, LBOUND(A) is not a constant expression according to item (4)(b)(i) in subclause 7.1.12. If the lower bounds of an assumed-shape array are not assumed, LBOUND(A) is a constant expression in this case, but might be a specification expression in other cases. ANSWER: This program conforms to the 2008 Fortran standard. The lower bounds of an assumed-shape array are not assumed. If a lower bound is not specified, it has the value 1 -- see the final sentence of the final paragraph of subclause 5.3.8.3. If a lower bound is specified, it must be specified either by a constant expression or a specification expression. In the example in the question, the lower bound of the first dimension is omitted, and therefore has the value 1, while the lower bound of the second dimension is given by a constant expression. Therefore, the reference to LBOUND is a constant expression, and thus the reference to SIZE is a constant expression. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 08-200r1 m185 F03/0118 submitted 11-215 m195 Revised for F08 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 --------------------------------------------------------------------- NUMBER: F03/0120 TITLE: When are parameterized sequence types the same type? KEYWORDS: type parameter, sequence type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: (1) What does 4.5.2.4 mean by the phrase "have type parameters and components that agree in order, name, and attributes?" Does REAL A(2*N) "agree" with REAL A(N+N) ? Does REAL A(N*N) "agree" with REAL A(N**2) ? (2) How complicated can the expressions a processor must determine are equal or different be? DISCUSSION: The Fortran 2008 standard allows sequence types to have type parameters (4.5.2, 4.5.2.3). The Fortran 2008 standard also gives rules for deciding when two entities declared with reference to derived-type definitions have the same type (4.5.2.4). Those rules break down for parameterized sequence types. Although the Fortran 2008 standard does not explicitly say it, the standard assumes that two attributes that include one or more expressions agree only if the values of those expressions are the same. Previous standards used attributes with expressions that could not be evaluated statically only in contexts where the processor was not required to determine if those attributes agreed. The inclusion of parameterized sequence types has created situations where it is necessary for the processor to determine if such attributes agree. QUESTION: (3) Consider the modules MODULE M1 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(4)) :: X END MODULE M2 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(4)) :: Y END Are the variables X and Y in this example of the same type? (4) What if the two instances of the type parameter N in the previous example were not kind type parameters? (5) Consider the modules MODULE M1 INTERFACE S SUBROUTINE S1(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(2)) :: X END MODULE M2 INTERFACE S SUBROUTINE S2(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(2)) :: X END If these two modules are used in the same scoping unit and there is a CALL of the generic subroutine S in that scoping unit, does the Fortran 2008 standard require a conforming processor to detect and report the conflict with the rules given in 12.4.3.4.5? It seems it might or might not depending on one's interpretation of item (6) in 1.5. DISCUSSION: Some have suggested that two attributes that include expressions should be said to agree if and only if the corresponding expressions are equivalent. One problem with that notion is that in general the question of whether two expressions are equivalent is undecidable. That problem could be circumvented by restricting the forms of expressions allowed. For example, the expressions might be restricted to be polynomials of one or more variables. In that case, the problem of determining equivalence is merely intractable, not impossible. Some have suggested that the notion of requiring only that the values agree should be maintained. One consequence of that would be that some constraint violations that are can currently be detected statically could only be detected dynamically. For example, consider the program MODULE M1 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N+N) END TYPE END MODULE M2 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N*N) END TYPE END SUBROUTINE S(N) USE M1, T1=>T USE M2, T2=>T TYPE(T1(N)) :: X TYPE(T2(N)) :: Y Y%A = 0.0 X = Y END PROGRAM MAIN READ *, N CALL S(N) END Under the interpretation requiring equal values, the question of whether the processor must detect and report a constraint violation in the assignment X = Y cannot be determined until the value of N is known. Another suggestion was that attributes that include expressions agree if and only if they are textually equivalent. That opens up the question of what it means to say that two expressions are textually equivalent. Does whitespace count? Is "2" textually equivalent to "02"? It "2" textually equivalent to a named constant "TWO" whose value is two? Another suggestion was that two entities declared with reference to derived-type definitions in different scoping units should be considered to be of different if either or both of the derived-type definitions include type parameters. At least that solution is easy to specify. Parameterized sequence types add so little value to the Fortran language that they cannot be worth the trouble they cause for the language specification, for implementors, and, if there are any users, for users. Therefore, I suggest banning parameterized sequence types from the language. Implementations that currently support parameterized sequence types can continue to support them due to the permissive nature of the Fortran standard. ANSWER: It was not intended that parameterized derived types participate in the algorithm for determining when two types are the same, as given in section 4.5.2.4. Therefore the answers to the questions are: Not Applicable, Not Applicable, No, Still No, and No. To make this effective, edits are supplied which ban parameterized sequence types from the language. EDITS to 10-007r1: [24:11+] Append new paragraph to 1.6.2 Fortran 2003 compatibility "Fortran 2003 permitted a sequence type to have type parameters; that is not permitted by this part of ISO/IEC 1539." [62:19] 4.5.2.3 Sequence type, Replace constraint C436 with "C436 (R425) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type or of a sequence type, the derived type shall not have type parameters, and a shall not appear." [63:9] 4.5.2.4 Determination of derived types, paragraph 2, delete the phrase "type parameters and". SUBMITTED BY: Robert Corbett HISTORY: 08-261 m185 F03/0120 submitted 11-224 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-255 m196 Revised answer 11-255r1 m196 Passed by J3 meeting 12-132 m197 Revised edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Must the intrinsic function REAL with KIND 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 ---------------------------------------------------------------------- NUMBER: F03/0139 TITLE: Functions returning procedure pointers KEYWORDS: procedure pointer DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: (1b) 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. (2b) 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 (1b): [12:16] Change "The variable that ... the result variable" to "The entity that ... the function result". [75:13] After "function result" delete "variable". [93:16] After "of the result" delete "variable". [115:7] After "function result" delete "variable". [280:18-19] After "name of the result" delete "variable". [280:22] After "name of the result" delete "variable". [280:31] After "name of the result" delete "variable". [280:33] After "not specified, the" Change "result variable" to "name of the result". [280:34] After "references to the result" delete "variable". [280:34-35] Delete "The characteristics ... the result variable.". [280:36] After "that of its result" change "variable" to "entity". [280:36] Change "is a pointer" to "is a data pointer", [280:37] After "shape of the result" delete "variable". [280:38] Change "result variable" to "function result". [280:39] After "with the result" delete "variable". [280:40+] In Note 12.37, Change "variable" to "entity" four times. [283:20] After "name of its result" delete "variable". [283:22] Change "result variable" to "result name". [283:25] Change "result variables identify the same variable" to "result names identify the same entity" and delete ", although their names need not be the same". [287:17] After "The result" delete "variable". [400:7] "result variable is a scalar"->"result is a scalar object". [407:8] After "identify the result" delete "variable". [407:12-13] After "identify the result" delete "variable". [407:21-22] "result variable" -> "named result entity which is either a variable or a procedure pointer". [407:22-23] Change "variable" to "entity" twice. [415:40] Change "result variables" to "function results that are variables". [417:18] Change "of the result variables" to "of the result entities if they are variables". [423:14] "The result variable of a function" ->"The result of a function that returns a data object". [430:13] "data object"->"entity". [434:10] Delete whole line. EDITS for (2b). [117:27+] Insert new constraint "C703 (R701) The shall not be a function reference that returns a procedure pointer." [160:17+] Insert new constraint "C809a (R819) The shall not be a function reference that returns a procedure pointer." [292:8+] Insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [12:19] 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 Malcolm's comment after N1816: The reason for failure is that the term (not a defined term) "function result" already has a different meaning that the interp didn't take into account. The following edits were in 10-135r1 for F2008 09-007r3: [04-007:12:16] Change "The variable that ... the result variable" to "The entity that ... the function result". becomes [09-007r3:10:25+] after 1.3.68 <> "1.3.68.1 <> entity that returns the value of a function" [09-007r3:15:22-24] Delete 1.3.112 <>. [04-007:75:13] After "function result" delete "variable". is not needed (already done at [09-007r3:51:35]) [04-007:93:16] After "of the result" delete "variable". becomes [09-007r3:109:29] After "of the result" delete "variable". [04-007:115:7] After "function result" delete "variable". becomes [09-007r3:130:26] After "function result" delete "variable". [04-007:280:18-19] After "name of the result" delete "variable". becomes [09-007r3:307:20] After "name of the result" delete "variable". [04-007:280:22] After "name of the result" delete "variable". becomes [09-007r3:307:24] After "name of the result" delete "variable". [04-007:280:31] After "name of the result" delete "variable". becomes [09-007r3:307:27] After "name of the result" delete "variable". [04-007:280:33] After "not specified, the" Change "result variable" to "name of the result". becomes [09-007r3:307:29] After "name of the result" delete "variable". [04-007:280:34] After "references to the result" delete "variable". becomes [09-007r3:307:30] After "references to the result" delete "variable". [04-007:280:34-35] Delete "The characteristics ... the result variable.". becomes [09-007r3:307:30-31] Delete "The characteristics ... the result variable.". [04-007:280:36] After "that of its result" change "variable" to "entity". becomes [09-007r3:307:31-32] After "that of its result" change "variable" to "entity". [04-007:280:36] Change "is a pointer" to "is a data pointer", becomes [09-007r3:307:32] Change "is a pointer" to "is a data pointer", [04-007:280:37] After "shape of the result" delete "variable". becomes [09-007r3:307:33] After "shape of the result" delete "variable". [04-007:280:38] Change "result variable" to "function result". becomes [09-007r3:307:33] Change "If the result variable" to "If the function result". [04-007:280:39] After "with the result" delete "variable". becomes [09-007r3:307:35] After "of the result" replace "variable" by "entity". [04-007:280:40+] In Note 12.37, Change "variable" to "entity" four times. becomes [09-007r3:307:35+] In Note 12.43, Change "variable" to "entity" four times. [04-007:283:20] After "name of its result" delete "variable". becomes [09-007r3:310:18] After "name of its result" delete "variable". [04-007:283:22] Change "result variable" to "result name". becomes [09-007r3:310:19] Change "result variable" to "result name". [04-007:283:25] Change "result variables identify the same variable" to "result names identify the same entity" and delete ", although their names need not be the same". becomes [09-007r3:310:21-22] Change "result variables identify the same variable" to "result names identify the same entity" and delete ", although their names need not be the same". [04-007:287:17] After "The result" delete "variable". becomes [09-007r3:314:9] After "The result" delete "variable". [04-007:400:7] "result variable is a scalar"->"result is a scalar object". becomes [09-007r3:435:8] "result variable is a scalar"->"result is a scalar object". [04-007:407:8] After "identify the result" delete "variable". becomes [09-007r3:443:7,10] After "identify the result" delete "variable" twice. [04-007:407:12-13] After "identify the result" delete "variable". becomes [09-007r3:443:10] After "identify the result" delete "variable". [04-007:407:21-22] "result variable" -> "named result entity which is either a variable or a procedure pointer". [09-007r3:443:18] "result variable" -> "named result entity which is either a variable or a procedure pointer". [04-007:407:22-23] Change "variable" to "entity" twice. becomes [09-007r3:443:19-20] Change "variable" to "entity" twice. [04-007:415:40] Change "result variables" to "function results that are variables". [09-007r3:451:8-9] Change "result variables" to "function results that are variables". [04-007:417:18] Change "of the result variables" to "of the result entities if they are variables". [09-007r3:452:26] Change "of the result variables" to "of the result entities if they are variables". [04-007:423:14] "The result variable of a function" ->"The result of a function that returns a data object". becomes [09-007r3:458:17] "The result variable of a function" ->"The result of a function that returns a data object". [04-007:430:13] "data object"->"entity". is not needed in 09-007r3 (this is the glossary). [04-007:434:10] Delete whole line. is not needed in 09-007r3 (this is the glossary). EDITS for (2b). [04-007:117:27+] Insert new constraint "C703 (R701) The shall not be a function reference that returns a procedure pointer." is not needed in 09-007r3 (we allow left-hand functions now). [04-007:160:17+] Insert new constraint "C809a (R819) The shall not be a function reference that returns a procedure pointer." becomes [09-007r3:170:17+] Insert new constraint "C802a (R805) The shall not be a function reference that returns a procedure pointer." [04-007:292:8+] Insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." becomes [09-007r3:318:7+] Insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [04-007:12:19] After "data objects" insert "or procedure pointers". becomes [09-007r3:30:31] After "data objects" insert "or procedure pointers". ---------------------------------------------------------------------- ====================================================================== Part 4: Active Fortran 2008 Interpretation Requests ====================================================================== ---------------------------------------------------------------------- NUMBER: F08/0004 TITLE: Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following conforming, and if so what does it print? program TARGET_Arg integer, pointer :: Pointer integer, pointer :: Target => NULL() integer, target :: AnotherTarget pointer => anotherTarget print *, Associated(pointer,target) end program TARGET_Arg DISCUSSION: Subclause 13.7 stipulates that descriptions of arguments of intrinsic procedures apply to actual arguments. This leaves open the question whether the TARGET dummy argument of ASSOCIATED is a pointer or not. If not a pointer, being optional, it is considered by subclause 12.5.2.12 to be absent if the corresponding actual argument is disassociated. Thereby, the result value of ASSOCIATED (by Case(i) of the result value clause) is true. If the TARGET dummy argument is a pointer, the result value of ASSOCIATED (by Case (iv) of the result value clause) is false. ANSWER: The Result Value paragraph of 13.7.16 ASSOCIATED only makes sense if the references to TARGET are talking about the actual argument. Therefore the program is standard conforming and prints F. An edit is supplied to remind the reader. NOTE: This subsumes interp F08/0005 (10-152). EDITS to 10-007r1: [330:36+] Insert new Note "NOTE 13.8a The references to TARGET in the above cases are referring to properties that might be possessed by the actual argument, so the case of TARGET being a disassociated pointer will be covered by case (iii), (vi), or (vii).". SUBMITTED BY: Van Snyder HISTORY: 10-149 m192 F08/0004 submitted 10-149r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m197 Failed WG5 ballot 1 N1876 12-138 m197 Revised edits - passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F08/0008 TITLE: IEEE exceptions for intrinsic functions KEYWORDS: IEEE_INVALID, SQRT DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTIONS: Section 13.7.1, page 325, lines 10-12 states If an infinite result is returned, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal; if a NaN result is returned, the flag IEEE_INVALID shall signal. Question (1): The Fortran 2008 standard does not require a standard-conforming processor to support IEEE_INVALID [14.3p8, 404:15]. If a processor does not support IEEE_INVALID, is it required to signal IEEE_INVALID when a NaN result is returned? Question (2): IEC 60559 requires the result of SQRT(+inf) to be +inf without overflow being signaled. IEC 60559 requires SQRT(qNaN), where qNaN is a quiet NaN, not to signal an invalid operand exception. Does Fortran 2008 require SQRT(QNaN) to signal IEEE_INVALID? ANSWERS: A1. No, if the processor does not support IEEE_INVALID, it cannot signal IEEE_INVALID. An edit is provided to clarify this. A2. No, the standard does not specify the behavior of SQRT on qNaN. EDITS to 10-007r1: [325:7] Change "is prohibited from invoking" to "shall not invoke". {Simpler wording is easier to understand.} [325:7-8] "returned in" -> "assigned to". {Correct wording instead of nonsense.} [325:8] After "or" insert "returned as a". {Continue correcting grammar.} [325:8-12] Replace "outside ... invoked" with "not representable by objects of the specified type and type parameters". [325:12+] Insert new paragraph "If an IEEE infinity is assigned or returned, the intrinsic module IEEE_ARITHMETIC is accessible, and the actual arguments were finite numbers, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal. If an IEEE NaN is assigned or returned, the actual arguments were finite numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. If no IEEE infinity or NaN is assigned or returned, these flags shall have the same status as when the intrinsic procedure was invoked." SUBMITTED BY: Robert Corbett HISTORY: 10-155 m192 F08/0008 submitted 10-155r1 m192 Fix title 10-155r2 m192 Draft answer 10-155r3 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 N1878 m197 Failed WG5 ballot 1 N1876 12-144 m197 Attempt to fix 13.7.1 12-144r1 m187 Passed by J3 meeting ------------------------------------------------------------------------ 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/0031 TITLE: PURE INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider MODULE m TYPE t ... CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x ... fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE zap(x) ! (1) TYPE(t),INTENT(OUT) :: x END SUBROUTINE PURE SUBROUTINE bad(y) TYPE(t),INTENT(INOUT) :: y CALL zap(y) ! (2) END SUBROUTINE END MODULE Clearly, even though subroutine zap is pure, invoking it causes impure final subroutine f to be called and so therefore it cannot be invoked in any context that requires it to be pure. Thus the call marked (2) is invalid. The question is whether the subroutine definition itself (marked (1)) is standard-conforming. If finalization of INTENT(OUT) arguments is considered to be done by the called procedure, then the subroutine definition is not standard-conforming. If finalization of INTENT(OUT) arguments is done by the caller, the subroutine definition might be standard-conforming. It would certainly seem a bit strange to be able to define a PURE procedure that cannot be invoked anywhere purity is required. DISCUSSION: Although the phrase "When a procedure is invoked" sounds like finalization occurs in the caller of a procedure and not in the called procedure, being PURE or having a finalizable INTENT(OUT) dummy argument are not grounds for an explicit interface to be required. This would appear to require, as a matter of practicality, that the processor performs the finalization of the actual argument on entry to the called procedure. I.e., that the impure final subroutine will in actuality be called from the pure procedure. ANSWER: Allowing a PURE procedure to cause invocation of impure final procedures in this way was inadvertant. An edit is supplied to clarify that any INTENT(OUT) dummy arguments of a PURE procedure must not have a relevant impure FINAL procedure. EDITS to 10-007r1: [312:21+] In 12.7 after C1277, insert new constraint "C1277a An INTENT(OUT) argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure." {In some other constraints we use "procedure that is not pure", but "impure procedure" is a simpler way of saying the same thing.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-181 m192 F08/0031 submitted 10-181r1 m192 Revised - 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 m197 Failed WG5 ballot 2 N1877 12-142 m197 Removed J3 note, no other changes - passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F08/0032 TITLE: PURE FUNCTION result finalization KEYWORDS: PURE FUNCTION FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider MODULE m TYPE t REAL c CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x x%c = 0 fcount = fcount + 1 END SUBROUTINE PURE TYPE(t) FUNCTION g(a) REAL,INTENT(IN) :: a g%c = a END FUNCTION END MODULE Even though this function is PURE, invoking it will inevitably result in the execution of the impure FINAL subroutine f. Thus, it cannot be used within another PURE procedure or from within a DO CONCURRENT loop, though it can be used from within a FORALL (because the finalizations only get done on termination of the outermost FORALL). Some other cases of impure finalization are prohibited by C1284, but not this because it does not occur "in" the procedure. Should an impurely-finalizable function result be allowed for a pure function? ANSWER: No, this should not be allowed. An edit is supplied to correct this oversight in the requirements for pure procedures. EDITS to 10-007r1 (as modified by corrigendum 1): [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be a polymorphic allocatable variable, or to be finalizable by an impure final subroutine. These are not permitted by this part of ISO/IEC 1539." [312:19+] In 12.7 after C1276, insert new constraints "C1276a The result variable of a pure function shall not be such that finalization of a reference to the function would reference an impure procedure. C1276b A pure function shall not have a polymorphic allocatable result variable." SUBMITTED BY: Malcolm Cohen HISTORY: 10-182 m192 F08/0032 Submitted 10-182r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-134 m197 Revised edits - passed byJ3 meeting ------------------------------------------------------------------------ NUMBER: F08/0038 TITLE: Are pointless restrictions on DIM arguments intended? KEYWORDS: DIM argument, optional, intrinsic reduction function DEFECT TYPE: Clarification STATUS: Passed by J3 meeting DISCUSSION: Some of the reduction functions have two forms, one with a DIM argument and one without; the DIM argument is not optional. IALL is an example. Other reduction functions have a DIM argument that is optional. COUNT is an example. The actual argument corresponding to the DIM actual argument is prohibited from being an optional dummy argument in both cases. The reason in the case of an optional DIM argument is so that the processor can determine the rank of the result. In the case of those with two forms, there is no problem for the processor to determine the rank, so the prohibition against the corresponding actual argument being an optional dummy argument is pointless. There is already a prohibition against it being an absent optional dummy argument in 12.5.2.12p3(4) [299]. Consider, for example subroutine S ( ARRAY, DIM ) integer, intent(in) :: ARRAY(:,:) integer, intent(in), optional :: DIM if ( present(dim) ) then print *, iall(array,dim) else print *, iall(array) end if end subroutine S This subroutine clearly does not conform, but a processor would have no difficulty determining the rank of the result of IALL(ARRAY,DIM). QUESTION: (1) Was the pointless restriction intentional, or was it an oversight that it did not get removed in the two-form case when MAXLOC etc. were added? (2) Is it necessary to continue the pointless restriction? ANSWER: (1) Yes, this was intentional. These could have been removed in Fortran 95, Fortran 2003, or Fortran 2008, but there was no request for removal. (2) No, but it is inappropriate to provide a new feature that would need many edits via the defect processing system. If this feature is desired it can be added in a future revision of the language. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 10-187r1 m192 F08/0038 submitted 10-187r2 m192 Revised edit - 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 m197 Failed WG5 ballot 2 N1877 12-133 m197 Revised answer - passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: Yes. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray, therefore MOVE_ALLOC needs to be an image control statement. Also, the corank of FROM and TO needs to be the same. Edits are supplied to correct this. EDITS to 10-007r1: [188:23+] In 8.5.1 Image control statements, paragraph 2, insert new bullet point before the STOP statement one, "- a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC with coarray arguments;" [372:19] In 13.7.118p3 MOVE_ALLOC, TO argument, After "same rank" insert "and corank". SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-139 m197 Revised answer - passed J3 meeting ---------------------------------------------------------------------- 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/0042 TITLE: SOURCE= questions KEYWORDS: ALLOCATE, SOURCE= DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program PROGRAM example1 REAL,ALLOCATABLE :: x(:),y(:) ALLOCATE(x(10),y(10),SOURCE=3.14159265) PRINT *,x,y END This program does not conform to Fortran 2003 due to constraint C631 which stated "If SOURCE= appears, ... shall contain only one ...". The corresponding constraint in Fortran 2008, C638 [127], is missing this requirement, so apparently the program is now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention this as a new feature. Furthermore, 6.7.1.1 paragraph 4 [127] begins "If is a coarray, shall not have a dynamic type of ..." which implies that there is only one for a (at least when the is a coarray). Similarly, the wording of constraint C639 implies a one-to-one correspondence between and . Q1. Is the omission of the single allocation requirement of Fortran 2003 an oversight? (i.e. is example1 non-conforming?). Also, consider the program PROGRAM example2 REAL,ALLOCATABLE :: x[:] ALLOCATE(x[*]) x = 3 END The ALLOCATE statement appears not to conform to Fortran 2008 because of 6.7.1.1 paragraph 4; since does not appear, it cannot satisfy any condition about its dynamic type. Q2. Is an ALLOCATE statement for a coarray required to have SOURCE=? (i.e. is example2 non-conforming?). Also, if multiple allocations with SOURCE= are permitted, consider the program PROGRAM example3 INTEGER,ALLOCATABLE :: x,y ALLOCATE(x,y,SOURCE=f()) PRINT *,x,y CONTAINS INTEGER FUNCTION f() INTEGER,SAVE :: n = 1 f = n n = n + 1 END FUNCTION END PROGRAM The execution semantics of SOURCE= in 6.7.1.2 paragraph 7 do not state whether the is evaluated once per statement or once per allocation. If the processor evaluates per statement execution, something like " 1 1" will be printed, but if it evaluates it per allocation, something like " 1 2" could be printed. Q3. How many times may be evaluated in an ALLOCATE statement with multiple allocations? Also, consider the program PROGRAM example4 REAL,ALLOCATABLE :: x(:) ALLOCATE(x,SOURCE=[0.5,1.5]) PRINT *,x END PROGRAM The Introduction implies that this program should be standard- conforming, but it violates constraint C633, which begins "(R631) If is an array either shall appear or shall appear ..." The requirements of C633 are not satisfied because R631 is and does not appear in R631. Q4. Is example4 intended to be standard-conforming? ANSWER: The answer to question 1 is No. This feature was deliberately added to the Fortran 2008 standard. Edits are supplied to correct its exposition. The answer to question 2 is No. An edit is supplied to correct paragraph 4 of 6.7.1.1. The answer to question 3 is once. An edit is supplied to clarify paragraph 7 of 6.7.1.2. The answer to question 4 is Yes. An edit is supplied to correct constraint C633. EDITS to 10-007r1: [xv] Introduction, bullet "Data usage and computation", Before "MOLD=" Insert "Multiple allocations are permitted in a single ALLOCATE statement with SOURCE=." {(Q1) Add new feature to the feature list.} [126:31-33] Replace C633 entirely with the constraints "C633 (R626) If an is an array, either shall appear in its , or shall appear in the ALLOCATE statement and have the same rank as the . C633a (R631) If is scalar, shall not appear." {(Q4) Fix broken constraint.} [127:5] Constraint C639, replace entirely with "C639 (R626) If appears, the kind type parameters of each shall have the same values as the corresponding type parameters of ." {(Q1) Fix singular implication. Avoid introducing any implication that each has the same set of kind type parameters or that any has the same set of kind type parameters as the - the relationship is a subset.} [127:18] 6.7.1.1 paragraph 4, replace entirely with "If has a dynamic type of C_PTR, C_FUNPTR, LOCK_TYPE, or has a subcomponent whose dynamic type is LOCK_TYPE, no in that statement is permitted to be a coarray." {(Q2) Fix implied requirement of SOURCE= appearance for coarrays.} [128:26] 6.7.1.2 paragraph 7, append new sentence "The is evaluated exactly once for each execution of an ALLOCATE statement." {(Q3) Clarify number of evaluations.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-211 m193 F08/0042 submitted - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-140 m197 Revised Q2 and edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: module m type :: foo integer :: i = 0 contains procedure, pass :: op end type contains subroutine op(this, i) class(foo) :: this this%i = i end subroutine end module m program p use m class(foo), allocatable :: o_foo[:] integer :: me allocate(foo :: o_foo[*]) me = this_image() if (me == 1) then call o_foo[2]%op(1) ! Type-bound call. end if sync all if (me == 2) write(*,*) o_foo%i end program p This program is not standard-conforming, as it violates one of the requirements of 12.5.2.4p2 [293], viz "If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic." However, if the type-bound call were replaced by SELECT TYPE(o_foo) TYPE IS (foo) CALL o_foo[2]%op(1) END SELECT appears to be standard-conforming. The example program appears to be harmless, so the requirement appears to be unnecessary. It is conjectured that the requirement is misworded and should instead be "If the actual argument is a polymorphic subobject of a coindexed object, the dummy argument shall not be polymorphic."? Q1. Is this requirement intentional? Furthermore, constraint C1229 says of a that is the object for a type-bound procedure reference, that it "shall not be a polymorphic subobject of a coindexed object"; however, C617 already prohibits any from being a polymorphic subobject of a coindexed object except as the subject of a type parameter inquiry or as the actual argument in an intrinsic inquiry function reference, so C1229 appears to be completely redundant. Q2. Is constraint C1229 redundant? ANSWER: A1. The requirement is intentional. A2. Yes, constraint C1229 is redundant. An edit is supplied to remove this unnecessary redundancy. EDITS to 10-007: [289:24] In 12.5.1, delete C1229. SUBMITTED BY: R. Bader HISTORY: 10-208 m193 F08/0043 submitted 10-208r1 m193 Revised - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed Wg5 ballot 2 N1877 12-143 m197 Removed attempt to explain the rationale - passed by J3 meeting ---------------------------------------------------------------------- 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/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was the text in 12.5.2.8: "If the dummy argument is an array coarray that has the CONTIGUOUS attribute or is not of assumed shape, the corresponding actual argument shall be simply contiguous." intended to disallow sequence association for coarrays, as illustrated by the example interface subroutine sub (x) real x(10)[*] end subroutine end interface ... real :: x(100)[*] ... call sub (x(10)) ANSWER: No. This restriction contradicts 12.5.2.4 paragraph 13, which allows the example program. An edit is supplied to correct this. EDIT: In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:5], add "or an element of a simply contiguous array". SUBMITTED BY: John Reid HISTORY: 10-226 m193 F08/0048 submitted 10-226r1 m193 Revised answer 10-226r2 m193 Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 12-124 m197 Changed answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1 (after corrigendum 1): [24:11+] 1.6.2 Compatibility, at the end, insert new paragraph "Fortran 2003 only required an explicit interface for a procedure that was actually referenced in the scope, not merely passed as an actual argument. This part of ISO/IEC 1539 requires an explicit interface for a procedure under the conditions listed in 12.4.2.2, regardless of whether the procedure is referenced in the scope." [279:19] In 12.4.2.2p1, replace "A procedure ... and" with "Within the scope of a procedure identifier, the procedure shall have an explicit interface if \obs{it is not a statement function and}" SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 m197 Failed WG5 ballot 2 N1877 12-141 m197 Revised edits 12-141r1 m197 Revised edits - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0055 TITLE: G editing for reals KEYWORDS: format, G editing DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Q1. Gw.d editing for a real value that is in the range (0.1,10**d) and is not near an integer power of 10 uses F editing to produce exactly a value with d significant digits. For values in this range that are near an integer power of 10, is it intended that F editing be used to produce a value with d significant digits? The rules in 10.7.5.2.2 usually have this effect, but the following examples illustrate exceptions for rounding UP and to ZERO. print "(ru,g11.2)", -9.95 print "(rz,g11.2)", -9.95 When rounded to two significant digits these are both equal to -9.9, however following through the rules in the standard it says to use F7.0 format which will give the result -9. (only one significant digit). For positive values, rounding DOWN and to ZERO print "(rd,g11.2)", 9.95 print "(rz,g11.2)", 9.95 both give the result 9.9 according to the rules in the standard. Q2. Is Gw.d editing intended to use F editing when that produces d significant digits? It usually achieves this, but for print "(ru,0p,g11.2)", -99.5 the standard requires 0PE11.2 editing to be used, which gives -0.99E+02 even though F7.2 editing can represent it as -99. Similarly for print "(ru,0p,g11.2)", 99. the standard requires 0PE11.2 editing to be used, which gives 0.99E+02, even though it is representable in F7.2 format as 99. Q3. COMPATIBLE and NEAREST modes of rounding differ only when the two nearest representable values are equidistant from the given value. The similarity appears not to be represented in the second table. What is meant by "if the higher value is even"? If by "even" we mean the last digit is even, then since we are talking about a mantissa which is close to 10, COMPATIBLE and NEAREST would have the same effect. Q4. The table has no entry for PROCESSOR_DEFINED rounding; since there is no value specified for r, it is impossible to interpret the table, which seems to indicate that it would not be standard conforming to use G editing with PROCESSOR_DEFINED. How does the PROCESSOR_DEFINED I/O rounding mode affect G editing? Q5. According to 10.7.2.3.7 paragraphs 3 and 4, the effect of NEAREST is processor dependent unless IEEE rounding on conversions is supported. How does this affect G editing? Q6. Consider PRINT '(5(1X,1PG9.0))', 0.0, 0.04, 0.06, 0.4, 0.6 noting that these values are strictly monotonic increasing. The standard appears to say that the output should be 0.E+00 4.E-02 0. 0. 6.E-01 which is decidedly not monotonic increasing. Is this intentional? ANSWER: A1. Yes, it is intended to produce output with d significant digits. The algorithm for choosing the output form for some I/O rounding modes is defective. An edit is provided to replace this algorithm. A2. Yes. This is solved by the same edit. A3. This question is rendered moot by the same edit. A4. This question is rendered moot by the same edit. A5. This question is rendered moot by the same edit. A6. No. An edit is supplied to fix this. EDITS to 10-007r1: [24:11+] In 1.6.2, insert new paragraph following paragraph 1: "The form produced by the G edit descriptor for some values and some I/O rounding modes differs from that specified by Fortran 2003." [24:27+] In 1.6.3, append new bullet item "- The form produced by the G edit descriptor with d==0 differs from that specified by Fortran 95 for some values.". [25:6] In 1.6.4, replace the last full stop with semicolon and insert new bullet item "- the G edit descriptor with d==0 for some values.". [258:14-] Insert new paragraph "If \si{d} is zero, \si{k}PE\si{w}.0 or \si{k}PE\si{w}.0E\si{e} editing is used for G\si{w}.0 editing or G\si{w}.0E\si{e} editing respectively." {Without the italics markup, this is "If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively."} [258:15-19] Replace the second and subsequent sentences of paragraph 4 including the two internal pseudo-tables by "If the internal value is a zero value, let $s$ be one. If the internal value is a number other than zero, let \it{N} be the decimal value that is the result of converting the internal value to \si{d} significant digits according to the I/O rounding mode and let $s$ be the integer such that $10^{s-1}$ <= \it{N} < $10^s$. If 0<=$s$<=\si{d}, F(\si{w}-\it{n}).(\si{d}-$s$),n('b') editing is used where \it{b} is a blank and \it{n} is 4 for G\si{w}.\si{d} editing and \si{e}+2 for G\si{w}.\si{d}E\si{e} editing. If $s$<0 or $s$>\si{d}, \si{k}PE\si{w}.\si{d} or \si{k}PE\si{w}.\si{d}E\si{e} editing is used for G\si{w}.\si{d} editing or G\si{w}.\si{d}E\si{e} editing respectively." {Note: \it{something} is something in italics, \si{something} is a syntax term (in italics), and $something$ is LaTeX math notation. Without the italics markup, this is "If the internal value is a zero value, let s be one. If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the I/O rounding mode and let s be the integer such that 10^(s-1) <= N < 10^s. If 0<=s<=d, F(w-n).(d-s),n('b') editing is used where b is a blank and n is 4 for Gw.d editing and e+2 for Gw.dEe editing. If s<0 or s>d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively."} SUBMITTED BY: John Reid and Thomas Henlich HISTORY: 11-174 m195 F08/0055 submitted 11-174r2 m195 Revised answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0056 TITLE: Non-polymorphic ALLOCATE with polymorphic SOURCE= KEYWORDS: ALLOCATE, polymorphic, SOURCE=. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m195_m1 Type t Real c End Type Type,Extends(t) :: t2 Real d End Type Class(t),Allocatable :: x Type(t),Allocatable :: y Allocate(x,Source=t2(1.5,-1.5)) Allocate(y,Source=x) ! (*) ... End Program Is the second ALLOCATE statement (marked *) standard-conforming? The only requirement is that Y be type-compatible with X; they both have the same declared type so this is true. However, the very similar Allocate(y,Source=t2(1.2,-1.5)) would not be conforming because Y is not type-compatible with the structure constructor, and y = x would also not be conforming (the dynamic types being different). However, the standard says that "the value of [y] becomes that of [x]" which is clearly impossible. Since the standard fails to establish an interpretation one might conclude that the example is not conforming. However, the similar situation with the dynamic types being the same but with non-deferred length type parameters being different is explicitly stated to be conforming (and to raise an error condition), perhaps this was also intended to raise an error condition. It is also possible that the intent was to use the value of the declared type part in this case, as happens for pointer assignment. What is the interpretation of this ALLOCATE statement? ANSWER: The statement was intended to be conforming and to use the declared type part of the source-expr only. An edit is supplied to clarify. EDIT: [128:24] In 6.7.1.2p7, before "On successful", insert "If an is not polymorphic and the is polymorphic with a dynamic type that differs from its declared type, the value provided for that is the ancestor component of the that has the type of the ; otherwise, the value provided is the value of the ." [128:25-26] Replace "that of " with "the value provided", twice. SUBMITTED BY: Malcolm Cohen HISTORY: 11-194 m195 Submitted 11-194r1 m195 Revised answer = passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0057 TITLE: Interoperability with empty types. KEYWORDS: Interoperability, derived type. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider TYPE,BIND(C) :: t END TYPE This is apparently standard-conforming, and interoperates with struct t { }; However, the latter is not valid syntax according to the C standard. How can a type be interoperable with a syntax error? ANSWER: The type definition was not intended to be standard-conforming. An edit is supplied to correct this error. EDIT: [431:12+] In 15.3.4, insert new constraint after C1505 "C1505a (R425) A derived type with the BIND attribute shall have at least one component." SUBMITTED BY: Malcolm Cohen HISTORY: 11-195 m195 F08/0057 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0058 TITLE: ENTRY point RESULT variable KEYWORDS: ENTRY, RESULT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: MODULE m REAL x CONTAINS FUNCTION f() f = 1 x = 2 RETURN ENTRY e() RESULT(x) x = 3 END FUNCTION END MODULE Is this standard-conforming? If so, what is the result of referencing f() and e(), and what effect does that have on the module variable x? Note that the standard prohibits dummy arguments of an entry point from appearing in executable statements ahead of the ENTRY statement (unless they are also dummy arguments of an earlier ENTRY statement or the FUNCTION statement), but makes no similar requirement on the RESULT name. ANSWER: This program was not meant to be conforming. An edit is provided to correct this mistake in the standard. EDITS to 10-007r1: Append new statement to 12.6.2.6p8 [310:20], "A name that appears as a in an ENTRY statement shall not appear in any executable statement that precedes the first RESULT clause with that name." Append new statement to 12.6.2.6p9 [310:23] "A name that appears as a in an ENTRY statement shall not appear in the expression of a statement function that precedes the first RESULT clause with that name unless the name is also a dummy argument of that statement function." SUBMITTED BY: Malcolm Cohen HISTORY: 11-196 m195 F08/0058 submitted 11-196r1 m195 Revised edits - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0059 TITLE: Auto-targetting requirements KEYWORDS: POINTER, TARGET, argument association DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider PROGRAM one REAL,TARGET :: x = 0 CLASS(*),POINTER :: p p => x ! (0). CALL s(p) ! (1). CALL s(x) ! (2). PRINT *,x CONTAINS SUBROUTINE s(q) CLASS(*),INTENT(IN),POINTER :: q IF (ASSOCIATED(q)) THEN SELECT TYPE (q) TYPE IS (REAL) q = q + 1 END SELECT END IF END SUBROUTINE END PROGRAM Clearly everything except statement (2) is standard-conforming. The statement marked (2) violates the requirement in 12.5.2.5 paragraph 2 for the actual argument to be polymorphic when the dummy argument is a polymorphic pointer. However, apart from that requirement, statement (2) is functionally equivalent to the sequence (0) then (1), so the "auto-targetting" feature does not need this requirement. Was this imposition of this requirement (which is needed when both the actual and the dummy are pointers) an oversight in this case? Note that similar considerations apply to CHARACTER(100),TARGET :: actual CHARACTER(:),POINTER,INTENT(IN) :: dummy in that the pointer assignment would be valid, but the requirements in 12.5.2.5 paragraph 5 are not met. ANSWER: Yes, the imposition of these requirements to the auto-targetting feature was an oversight. An edit is supplied to correct this. EDITS to 10-007r1: [295:16-17] In 12.5.2.5, Replace paragraph with "The requirements in this subclause apply to an actual argument with the ALLOCATABLE or POINTER attribute and that corresponds to a dummy argument with the same attribute." {Except for paragraph 4, all these requirements are unnecessary when auto-targetting is happening. Note that 12.5.2.5p6 is moot because a coindexed object is not permitted in auto-targetting as it is not a valid target in a pointer assignment (C725).} [296:4-5] Delete paragraph 12.5.2.5p4 and reinsert twice, once at [296:12+] as a new paragraph after 12.5.2.6p3, and once at [296:35] as a new sentence at the end of 12.5.2.7p3. {Duplicate the bit about assumed type parameters.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-197 m195 F08/0059 submitted 11-197r1 m195 Revised editing instructions - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0060 TITLE: Procedure pointer assignment with an EXTERNAL target. KEYWORDS: Procedure pointer, pointer assignment, EXTERNAL attribute. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m5 Print *,f() Call s Contains Subroutine s Procedure(Real),Pointer :: p Print *,g() p => f ! (1) Print *,p() p => g ! (2) Print *,p() End Subroutine End Program Function f() f = 1 End Function Function g() g = 2 End Function is this program standard-conforming? On the face of it, both (1) and (2) violate constraint C729, which only allows an external procedure "that is accessed by use or host association and is referenced in the scoping unit as a procedure or that has the EXTERNAL attribute". The function f is accessed by host association but is not referenced in the scoping unit as a procedure, whereas the function g is referenced in the scoping unit as a procedure but is not accessed by use or host association. Furthermore, consider Program m5a Real,External :: f,p Pointer p p => f ! (3) Print *,p() End Program ! function f as above. Is this conforming? The constraint has a single clause for external procedures with no commas but with a disjunction and a conjunction, therefore it is ambiguous whether it means "accessed by use or host association" AND ("is referenced in the scoping unit as a procedure" OR "has the external attribute") or whether it means ("accessed by use or host association" AND "is referenced in the scoping unit as a procedure") OR "has the external attribute") Since the standard does not unambiguously give an interpretation of this program it seems that statement (3) is also not conforming. Which of these three procedure pointer assignment statements were intended to be conforming? DISCUSSION: The wording of this constraint was determined by Interp F03/0138, which intended to change it to "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." but a last-minute "editorial" change at the WG5 ballot stage made it "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." instead, and the comma got lost in between there and Fortran 2008. Despite supposedly being an editorial change, the WG5 wording has different technical results. According to the original wording of the interp, all three examples above were intended to be allowed. ANSWER: All three pointer assignment statements were intended to be valid. An edit is supplied to correct the error in the standard. EDITS to 10-007r1: [158:33-159:2] In 7.2.2.2, C729, replace "an external ... bullet ($\bullet$)" with "a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute". {NB: $\bullet$ is the LaTeX command that produces a bullet.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-198 m195 F08/0060 submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0061 TITLE: Description of the CONTIGUOUS attribute misworded? KEYWORDS: CONTIGUOUS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider the following code: module mod_cont contains subroutine fcont(x) real, contiguous :: x(:) integer :: i x = (/ (real(i),i=1,size(x)) /) end subroutine fcont end module mod_cont program cont use mod_cont implicit none real :: x(45) call fcont(x(1::3)) end program Is this program standard conforming? 5.3.7 paragraph 1 says: "The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated with a contiguous effective argument, or that an array pointer can only be pointer associated with a contiguous target." ANSWER: Yes. The effect of the CONTIGUOUS attribute is misstated. An edit is supplied to correct this. EDITS for 10-007r1: [93:7-8] In 5.3.7p1, Change "can only be argument associated with a contiguous effective argument" to "is contiguous". ADDITIONAL SUGGESTED EDIT FOR A FUTURE REVISION: [93:30+] In 5.3.7 after Note 5.10, insert additional note "NOTE 5.10a If an actual argument is not simply contiguous and the corresponding dummy argument is an assumed-shape array with the CONTIGUOUS attribute, the processor might use the so-called copy-in/copy-out argument passing mechanism to assure the contiguity of the dummy argument." SUBMITTED BY: Reinhold Bader HISTORY: 11-199r1 m195 F08/0061 submitted 11-199r1 m195 Revised edits 11-199r2 m195 Revised edits - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0062 TITLE: Mixing default initialization with DATA initialization KEYWORDS: DATA, default initialization, explicit initalization DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: In the following program, one component has a default initialization and the other is initialized in a DATA statement. Is the program valid? module oad_active implicit none type active integer :: v integer :: d = 42 end type end module module tots_c use oad_active implicit none type(active), save :: trlkold data trlkold%v /100/ end module program foo use tots_c implicit none if (trlkold%d /= 42) stop 'ERROR d /= 42' if (trlkold%v /= 100) stop 'ERROR v /= 100' end program foo WG5/N1830 has [p104, 5.4.7, parag. 2] If a nonpointer object has default initialization, it shall not appear in a . and [p89, 5.2.3, parag. 1] Explicit initialization alternatively may be specified in a DATA statement unless the variable is of a derived type for which default initialization is specified. [...] A variable, or part of a variable, shall not be explicitly initialized more than once in a program. and [p70, 4.5.4.6, parag. 6] Explicit initialization in a type declaration statement (5.2) overrides default initialization ANSWER: It was intended that the data statement not be conforming. 5.4.7p2 was carefully worded to use "shall not appear" rather than "shall not be the ". The intention was that an object be initialized entirely in a type declaration statement, or that only those parts of it having default initialization be initialized. It was considered to be a burden on processors to be required to initialize some parts of a structure using default initialization, and other parts of it explicitly. EDITS to 10-007r1: None. SUBMITTED BY: Tobias Burnus HISTORY: 11-201 m195 F08/0062 submitted 11-201r1 m195 Draft answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0063 TITLE: G editing to a narrow output field KEYWORDS: G edit descriptor, narrow field, asterisks DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What will be the output for the following program: PROGRAM MAIN PRINT '(G6.5)', 1.0 END Will it print six asterisks ("*****") or 2 followed by four blanks ("** ")? According to subclause 10.7.5.2.2, because 0.1-0.5E-6 <= 1.0 < 1E5 - 0.5 this will do F editing, and according to the table that means F2.4,4(' ') ANSWER: 10.7.2.3.2 says "the field occupies w positions, the fractional part of which consists of d digits" and this does not make sense if w "a polymorphic dummy" Insert after "that target" "and a nonpolymorphic dummy argument becomes argument associated with the declared type part of that target". Making the whole paragraph read: "If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that is pointer associated with a target, a polymorphic dummy argument becomes argument associated with that target and a nonpolymorphic dummy argument becomes argument associated with the declared type part of that target". [292:18] p3 Change "it" to ", a polymorphic dummy argument", Insert after "that actual argument" "and a nonpolymorphic dummy argument becomes argument associated with the declared type part of that actual argument". Making the whole paragraph read: "If a present nonpointer dummy argument without the VALUE attribute corresponds to a nonpointer actual argument, a polymorphic dummy argument becomes argument associated with that actual argument and a nonpolymorphic dummy argument becomes argument associated with the declared type part of that actual argument". SUBMITTED BY: Robert Corbett HISTORY: 12-116 m197 F08/0068 submitted 12-116r1 m197 Revised - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0069 TITLE: Which part of an effective argument becomes undefined? KEYWORDS: INTENT(OUT), extended type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The last sentence of paragraph 17 of Clause 12.5.2.4 [294:42-295:2] states If the dummy argument is not polymorphic and the type of the effective argument is an extension of the type of the dummy argument, only the part of the effective argument that is of the same type as the dummy argument becomes undefined. The effective argument might have several parts that are of the same type as the dummy argument. Should the sentence say that only the ancestor component of the effective argument that has the same type as the dummy argument becomes undefined? A possible edit is to replace the last sentence of paragraph 17 of Clause 12.5.2.4 with If the dummy argument is not polymorphic and the type of the dummy argument is the type of an ancestor component (4.5.7.2) of the effective argument, only that component of the effective argument becomes undefined. ANSWER: A nonpolymorphic dummy argument should not be able to be argument associated with an effective argument that has a different dynamic type. That mistake was corrected by interpretation F08/0068. The quoted text from the standard is therefore a mistake; an edit is supplied to correct it. EDITS to 10-007r1: [294:40] 12.5.2.4p17, after "has INTENT (OUT)," change "the actual argument" to "the effective argument". {It is the effective argument that we intended to become undefined, not the whole actual argument in the case of polymorphism.} [294:42-295:2] Delete last sentence "If ... undefined." {No longer possible.} SUBMITTED BY: Robert Corbett HISTORY: 12-117 m197 F08/0069 submitted 12-117r1 m197 Draft answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0070 TITLE: Finalization of INTENT(OUT) arguments KEYWORDS: finalization INTENT(OUT) DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: The following questions assume the new text for paragraph 8 of Clause 4.5.6.3 provided in Corrigendum 1. The new text states When a procedure is invoked, an object that becomes argument associated with a nonpointer, nonallocatable INTENT(OUT) dummy argument of that procedure is finalized. The finalization caused by INTENT(OUT) is considered to occur within the invoked procedure; so for elemental procedures, an INTENT(OUT) argument will be finalized only if a scalar or elemental final subroutine is available, regardless of the rank of the actual argument. Question 1: Suppose an explicit-shape dummy array is argument associated with an array that has more elements than the dummy array. Are all of the elements of the effective argument of the dummy array finalized or are only those elements associated with elements of the dummy array finalized? Question 2: The last sentence of paragraph 17 of Clause 12.5.2.4 states If the dummy argument is not polymorphic and the type of the effective argument is an extension of the type of the dummy argument, only the part of the effective argument that is of the same type as the dummy argument becomes undefined. In such a case, is the entire effective argument finalized or is only the part of the effective argument that becomes undefined finalized? Question 3: Is the argument finalized before it becomes undefined? Question 4: If so, can its value be used in a specification expression? ANSWERS: A1. Only the part properly associated with the dummy argument was intended to be finalized; an edit is supplied to clarify this. A2. This is answered by interpretations F08/0068 and F08/0069; the quoted text has been deleted. A3. Yes. This is clarified by the same edit as for question 1. A4. No, because it becomes undefined on procedure invocation. EDITS: Delete, in the quoted text, "an object that becomes argument associated with" and after "is finalized" insert "before it becomes undefined" Making the whole paragraph read "When a procedure is invoked, a nonpointer, nonallocatable INTENT(OUT) dummy argument of that procedure is finalized before it becomes undefined. The finalization caused by INTENT(OUT) is considered to occur within the invoked procedure; so for elemental procedures, an INTENT(OUT) argument will be finalized only if a scalar or elemental final subroutine is available, regardless of the rank of the actual argument." SUBMITTED BY: Robert Corbett HISTORY: 12-118 m197 F08/0070 submitted 12-118r1 m197 Draft answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0071 TITLE: Vector subscript target KEYWORDS: Pointer assignment, Vector subscript DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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. Some editorial improvements could be made. 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: [124:6] 6.5.3.3.2 Vector subscript, paragraph 2, second bullet item, Change "the in a pointer assignment statement" to "the target in pointer assignment (C724)". [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.} EDITORIAL (for next revision): Additional edits are suggested: [124:4] Change "An" to "Note that an", change "shall not be" to "is not permitted to be". [124:5] After "redefined" insert "(12.5.2.4)". [124:7] After "file" insert "(C901)". SUBMITTED BY: Malcolm Cohen HISTORY: 12-121 m197 F08/0071 submitted 12-121r1 m197 Revised wording with same edits - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0072 TITLE: Final subroutines with corank KEYWORDS: FINAL subroutine, finalization, coarrays, codimension, corank DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it intentional that final subroutines with coarray dummy arguments are allowed? ANSWER: No. An edit is supplied to correct this. EDITS to 10-007r1: In C480 [4.5.6.1 10-007r1:75:10] in the second sentence, add "noncoarray," before "nonpointer". SUBMITTED BY: Tobias Burnus HISTORY: 12-125 m197 F08/0072 submitted 12-125r1 m197 Revised, same answer with 10-007r1 references - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0073 TITLE: Polymorphic auto-targetting KEYWORDS: polymorphic, pointer, dummy DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m013 Type t Real c End Type Type(t),Target :: x Call s(x) Print *,x%c Contains Subroutine s(p) Class(t),Pointer,Intent(In) :: p p%c = 3 End Subroutine End Program Is the invocation of S standard-conforming? According to 12.5.2.5p2, because dummy P is polymorphic, the actual argument is required to be polymorphic, even though the dummy argument is not associated with the actual argument. ANSWER: The invocation of S was intended to be standard-conforming; the polymorphism-matching requirement in 12.5.2.5 was intended to apply only when both the actual and dummy arguments were pointers (or allocatables). An edit is supplied to correct this mistake. EDITS to 10-007r1: [295:18] 12.5.2.5p2, change "The" to "Except in the case where the dummy argument is a pointer and the actual argument is not a pointer, the" SUBMITTED BY: Malcolm Cohen HISTORY: 12-131 m197 F08/0073 submitted - passed by J3 meeting ----------------------------------------------------------------------