J3/11-006A Outstanding Fortran Interpretations, February 17, 2011 Stan Whitlock for /interp > 05-015 == closed F95 interps > 05-016 == 05-006T1 (m173) interps (N1640) F03 Corr #1 (N1636) > 08-017 == 06-006T2r1 (m177) interps (N1666) F03 Corr #2 (N1664) > 08-021 == 08-006AT3 (m185) interps (N1730) F03 Corr #3 (N1727) > 09-022 == 09-006AT4 (m187) interps (N1764+) F03 Corr #4 (N1771) > == 10-006T5 (m192) interps (N1805) F03 Corr #5 (N1815) > N1823 - combined TCs 1-5 > remove interps placed in F03 Corr #5 (N1815) not published > add F2008 09-007r3 edits from 10-135r1 to F03/0139 > add F08 interps passed by J3 LB #21 10-199/10-202r1 > remove F03/0083 and F03/115 text since withdrawn: no further action + add 10 new interps & 22 interp answers from m193 and LB #22 10-254/11-129 [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 N S T number title - - - ------ ----- * P E F90/0145 Expressions in of a FUNCTION statement ------ * P E F03/0017 Dummy procedure pointers and PRESENT * P C F03/0018 Multiple identical specific procedures in type-bound generic interfaces * P I F03/0019 Multiple identical specific procedures in generic interface blocks * P E F03/0021 What kind of token is a stop code? * B E F03/0030 IEEE divide by zero * P E F03/0042 IEEE funny values and Standard real generic ntrinsic procedures * P E F03/0046 Unlimited polymorphic pointers in common blocks * P E F03/0047 Polymorphic arguments to intrinsic procedures * B E F03/0048 Control edit descriptors in UDDTIO * P E F03/0051 Repeat specifiers and UDDTIO * P 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 * P I F03/0065 Relational equivalence * P I F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine * B I F03/0085 Finalizing targets of pointer or allocatable * B I F03/0091 Array components cannot depend on length type parameters * B 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 * P E F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type * B I F03/0105 SIZE= specifier and UDDTIO * B I F03/0110 Restoring dropped restriction on ENTRY * P E F03/0116 indistinguishable specifics for a generic interface with use association * P E F03/0118 Are lower bounds of assumed-shape arrays assumed? * P E F03/0120 When are parameterized sequence types the same type? * B C F03/0121 Precise FP semantics of the REAL intrinsic * B I F03/0123 Implicit typing in derived types * B I F03/0124 definition is poorly defined * B E F03/0128 Subobjects in namelist output * P E F03/0139 Functions returning procedure pointers ------ * B E F08/0001 Generic resolution with pointer dummy arguments * B E F08/0002 Are assumed- or deferred-shape objects allowed in namelist? * B E F08/0003 Is a disassociated pointer allowed as an actual DIM argument? * B E F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? * B E F08/0005* optional arguments and ASSOCIATED - subsumed by F08/0004 * B E F08/0006 generic resolution with banned argument combinations * B I F08/0007 Can zero have more than one bit sequence representation? * B I F08/0008 IEEE exceptions for intrinsic functions * B I F08/0009 Is ABS ever required to be the optional IEC 60559 abs? * B E F08/0010 deallocating objects that are associated with other objects * B E F08/0011 How many times are constructed values finalized? * B E F08/0012* Are constants finalized? - subsumed by F08/0011 * B E F08/0013 How does finalization interact with allocatable assignment? * B E F08/0014 Finalizing assignment to vector-subscripted object * B E F08/0015 IMPLICIT * B E F08/0016 Can a vector-subscripted argument become undefined? * B E F08/0017 Elemental subroutine restrictions * B E F08/0018 Impure elemental restrictions * B E F08/0019 Transformational Bessel functions * B E F08/0020 FINDLOC and logical arguments * B E F08/0021 STORAGE_SIZE and unlimited polymorphic * B E F08/0022 DO CONCURRENT and file i/o * B E F08/0023 DO CONCURRENT and POINTER * B E F08/0024 Dummy arguments of impure elemental procedures * B E F08/0025 DO CONCURRENT and ALLOCATABLE * B E F08/0026 DO CONCURRENT and output interleaving * B E F08/0027 ATOMIC_REF example * B E F08/0028 Does a procedure reference cause loop termination? * B E F08/0029 G0 edit descriptor and floating-point output * B E F08/0030 Unlimited format repeat effects * B E F08/0031 PURE INTENT(OUT) finalization * B E F08/0032 PURE FUNCTION result finalization * B E F08/0033 PURE polymorphic finalization * B E F08/0034 ELEMENTAL INTENT(OUT) finalization * B E F08/0035 Maximum value for SHIFT argument to SHIFTL and SHIFTR * B E F08/0036 NORM2 example in Annex C * B E F08/0037 PROCEDURE POINTER vs PROTECTED * B E F08/0038 Are pointless restrictions on DIM arguments intended? * B E F08/0039 Many-one vector subscript usage * B E F08/0040 MOVE_ALLOC for coarrays * P E F08/0041 Segment ordering rules * B E F08/0042 SOURCE= questions * B E F08/0043 Executing a type-bound procedure on a coindexed object * B I F08/0044 Resolving the type of a coarray or coindexed object * P E F08/0045 constraints on entities of type LOCK_TYPE * B E F08/0046 VALUE attribute restrictions * B I F08/0047 public generic with same name as private type * P E F08/0048 Sequence association for coarrays * B E F08-0049 ELEMENTAL functions with nonconstant type parameters ====================================================================== 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 procedure pointers, PRESENT DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Does the following program conform to the 2003 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 ANALYSIS: 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 conforms to the 2003 standard. An edit is supplied to remove any possibility of a contradictory reading of the relation between 12.4.1.3 and 13.7.91. EDITS: In the second paragraph of 12.4.1.3 [271:16] replace "an associated" by "a". At the end of that paragraph, insert a new sentence: "Except in references to intrinsic inquiry functions, if the actual argument is a pointer it shall be associated." 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 Michael Ingrassia's NO comment for F03/0017: The statement "It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute" seems to me to be wrong. In the fragment subroutine S(I) integer, optional :: I if (present(I)) then the argument of present does not have the POINTER attribute, but in the fragment subroutine S(I) integer, pointer, optional :: I if (present(I)) then it does, and the language of 13.7.91 is clear enough "[the argument to PRESENT] may be a pointer". Delete the statement ("It is not clear..."). Since that removes justification for the edits submitted, change the answer to read "The program does not conform to the 2003 standard. This is because the pointer F is not associated in subroutine S, which is not one of the possibilities permitted by 12.4.1.3 [271:16]." ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic interfaces KEYWORDS: Type-bound generics DEFECT TYPE: Clarification STATUS: J3 consideration in progress QUESTION 1: Does the following program unit conform to the 2003 standard? module M type T contains procedure MyAdd generic :: operator(+) => myAdd end type T type X contains procedure, pass(b) :: MyAdd generic :: operator(+) => myAdd end type X contains integer function MyAdd ( A, B ) type(t), intent(in) :: A type(x), intent(in) :: B end function MyAdd end module M QUESTION 2: Does the following program unit conform to the 2003 standard? module M interface operator(+) procedure MyAdd end interface type T contains procedure MyAdd generic :: operator(+) => myAdd end type T contains integer function MyAdd ( A, B ) type(t), intent(in) :: A real, intent(in) :: B end function MyAdd end module M QUESTION 3: If the interface block and type definition are exchanged in QUESTION 2, does the program unit conform to the 2003 standard? ANALYSIS: The OPERATOR(+) bindings to the types T and X construct a single generic OPERATOR(+) interface that is a local entity of module M. They do not construct separate OPERATOR(+) generic interfaces that are separate local entities of the types. 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is clear that if different functions with identical interfaces were bound to the types that they would be a "pair of specific procedures" and the resulting OPERATOR(+) interface would therefore be prohibited by 16.2.3. It is not clear whether the generic bindings bind separate specific procedures to the OPERATOR(+) generic, or only redundantly bind the same procedure. If the former, the program units are not standard conforming because they violate the provisions of 16.2.3. If the latter, they appear to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is nothing obviously equivalent in 4.5.4, nor anything that specifies that C1209 applies to generic bindings to types. It also does not apply between a generic interface block and a generic interface previously specified by a generic binding to a type (question 3), since the latter specific binding is accomplished by a conspiracy of a and a , not by a . ANSWER: The program units conform to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using a in a type definition or by a type definition and a generic interface block do not bind a "pair of specific procedures" to the generic interface. Indeed, the following type definition is legal: type Z contains procedure :: MyAdd generic :: operator(+) => myAdd, operator(+) => myAdd end type Z EDITS: 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 Malcolm Cohen F03/0018: NO. I disagree completely with practically everything said in ANALYSIS. It's hard to know where to begin. (a) Why assert there is an OPERATOR(+) in the module and not in the types? This is wrong - there is no OPERATOR(+) in the module; we know this, because ****WE CAN BLOCK IMPORTING IT BY DOING "use,only::x"***. It is accessible in the module, but that is a horse of a different colour. (b) Q1 is not valid Fortran: Error: junk3.f90, line 17: Passed-object dummy argument A of type-bound procedure MYADD of T is not polymorphic (in actual procedure MYADD) Error: junk3.f90, line 17: Passed-object dummy argument B of type-bound procedure MYADD of X is not polymorphic (in actual procedure MYADD) (c) Q2 is not valid Fortran: Error: junk4.f90, line 15: Passed-object dummy argument A of type-bound procedure MYADD of T is not polymorphic (in actual procedure MYADD) (d) Multiple occurrences of a single specific in a generic have not been allowed before. If we are going to consider the example in the ANSWER section, I'd think we'd expect it to be invalid. Certainly, there is no (good or otherwise) reason for it to be valid. (e) Furthermore, the example in the ANSWER section has nothing to do with the question asked. ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION 1: Does the following program conform to the 2003 standard? program P interface X subroutine S ( A ) integer :: A end subroutine S procedure S end interface X end program P ANALYSIS: 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is not clear whether the interface body and the procedure statement bind separate specific procedures to the generic identifier, or only redundantly bind the same procedure. If the former, the program is not standard conforming because it violates the provisions of 16.2.3. If the latter, it appears to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is a general rule that nothing shall be declared more than once. It appears that a procedure statement within an interface block is not a declaration: 5.1.2.6 (External attribute) specifies that the external attribute may be specified by an EXTERNAL statement, a or an interface body that is not in an abstract interface block. A procedure statement in an interface block apparently does not specify the external attribute. The procedure specified by the PROCEDURE statement in the above example is clearly an external procedure with an explicit interface, so it satisfies the requirements of C1207. ANSWER: The program conforms to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using an interface body and a procedure statement do not bind a "pair of specific procedures" to the generic interface. Enforcing C1209 is more bother for processors than simply allowing multiple bindings of a particular specific procedure to a generic interface. It is unhelpful to users, and can be hurtful if the multiple bindings are specified by independent generic interfaces and brought into a scoping unit by use association from different modules. There was no equivalent constraint in Fortran 90, although something like it was added by interp F90/000007. The constraint added there applied only to a single specification part. It's not clear whether that meant "declared in the same specification part" or "accessible in the same specification part." When it was put into Fortran 95, it clearly applied to all accessible generic interfaces with a particular . Given the multitude of new ways to bring specific procedures into a generic interface in Fortran 2003, and that many of those ways allow a specific procedure to be bound to a generic identifier more than once, this conspicuously lonely constraint should be removed. Edits are supplied to correct this oversight. EDITS: Remove C1209 from 12.3.2.1. 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 Malcolm Cohen F03/0019: NO. This ANSWER is defectively worded, since the example is demonstrably NOT compliant with the standard. Nor do I believe for one microsecond that we intended it to be that way. The rationale for this NEW FEATURE is just that, rationale for a new feature. The interp process is absolutely NOT SUITABLE for adding new features to the standard. There is no ambiguity here. Do not do this. ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: Only statement (1) was intended to be standard-conforming. Edits are supplied to clarify the situation. EDITS: [170:23] Replace with "<> " [170:24+] Insert new constraint "C834a (R850) The shall not have a and shall not have more than 5 s." [170:27] After "significant" insert "and all stop codes are permissible even if not representable in the default integer type" SUBMITTED BY: Malcolm Cohen HISTORY: 04-416 m170 F03/0021 submitted - Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 Rob James'NO comment for F03/0021: The last edit does not make sense for an that does not have a . [36:37-38] explicitly states that such an is of type default integer. The last edit, however, says that the value of this constant does not have to be representable in the default integer type. How can a default integer not contain a value representable in the default integer type? ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS: Page and line numbers refer to 10-007. [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] 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+] 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 ---------------------------------------------------------------------- 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: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM SUBROUTINE sub COMMON /blk1/ x CLASS(*), POINTER :: x END SUBROUTINE There appears to be nothing prohibiting an unlimited polymorphic pointer from appearing in a common block, but the following appears in Fortran 2003 at [100:10]: A data pointer shall be storage associated only with data pointers of the same type and rank. And at [75:23-25]: An object declared with the CLASS(*) specifier is an unlimited polymorphic object. An unlimited polymorphic entity is not declared to have a type. It is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity. It appears that it is not standard conforming to have an unlimited polymorphic pointer that is storage associated with anything else, including another unlimited polymorphic pointer. So, while it is apparently standard-conforming to have an unlimited polymorphic pointer in a common block, a common block with the same name cannot be accessed in any other scoping unit. This interpretation also seems to be supported by parts of section 16 of the standard. At [416:7-24]: In a storage association context ... (8) A pointer occupies a single unspecified storage unit that is different from that of any nonpointer object and is different for each combination of type, type parameters, and rank. At [417:12-13]: All scoping units that access named common blocks with the same name shall specify an identical sequence of storage units. And at [417:14-17]: For any two blank common blocks, the initial sequence of storage units of the longer blank common block shall be identical to the sequence of storage units of the shorter common block. If two blank common blocks are the same length, they shall have the same sequence of storage units. Was it intended that an unlimited polymorphic pointer should be allowed in a common block? If yes, then was it intended that such a common block should be accessible in more than one scoping unit? ANSWER: No. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [98:20] Before "an allocatable variable", insert "a polymorphic pointer,". 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 Malcolm Cohen NO vote on F03/0046. There is no rationale given for rejecting ultimate polymorphic pointers in common blocks. Perhaps the thought was that they MIGHT point to objects of non-SEQUENCE non-BIND non-default-intrinsic type, and that since such a pointer with that declared type would be disallowed, so should ultimate polymorphic pointers. This reasoning is inconsistent with the answer given in F03/0053, where (currently-disallowed) TYPE(C_PTR) pointers were added to the list of things allowed in common. However, a TYPE(C_PTR) might also point to an object of non-SEQUENCE non-BIND non-default-intrinsic type. ---------------------------------------------------------------------- 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/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i = 0 CONTAINS PROCEDURE, PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE CONTAINS RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, '(i1, /)') dtv%i WRITE(unit, '(t1, a2)') 'AB' END SUBROUTINE pwf END MODULE PROGRAM foo USE m IMPLICIT NONE TYPE(t) :: a a%i = 3 PRINT *, 'xyz', a end program 9.6.4.8p26 [227:17] states A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. The term "record position" is used, but it doesn't appear to be defined anywhere. Depending on the interpretation, the above program might be standard-conforming, or it might not be. If "record position" is taken to mean "the position within the current record", regardless of which record is the current record, then the record position at the beginning of the UDDTIO procedure is before the fourth character of the record. The first child data transfer statement begins a new record, and the second child data transfer statement writes to the first character of the new record. This would be before the "record position" at the time the UDDTIO procedure was invoked, and the program would not be standard-conforming. If "record position" is taken to mean a combination of the record and the position within that record (essentially making it mean the same thing as "file position"), then the above program is standard- conforming, since the control edit descriptor doesn't cause the file to be positioned before the record position when the UDDTIO procedure was invoked. What is the meaning of "record position", and is the above program standard-conforming? ANSWER: The term "record position" is not well defined. The intent of 9.6.4.8 was to prohibit a child data transfer statement from possibility overwriting or re-reading any characters in the current record that an active parent I/O statement had previously written or read. 9.6.4.8 should have used the term "file position" instead of "record position". Therefore, the program is standard-conforming, and prints xyz.3 AB where the first record starts with a space and the "." represents a value separator. Edits are supplied to clarify the intent of 9.6.4.8 and remove the phrases "record position" and "record positioning" from the standard. EDITS: In 10-007 [227:15] In section 9.6.4.8p25, in the paragraph that begins with "Because a child data transfer statement does not position the file prior to data transfer," replace "effective item or record positioning edit descriptor" with "effective item or edit descriptor" [227:17] In section 9.6.4.8p26, replace the phrase "A record positioning edit descriptor, such as TL and TR," with "The edit descriptors T and TL" [227:18] Change "record position" to "file position" twice. [487:28] In section C.6.2p1, delete "record positioning" SUBMITTED BY: Rob James HISTORY: 05-139 m171 F03/0048 submitted 05-139r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-167 06-366r2 m178 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 10-241 m193 Draft answer for F2008 10-241r1 m193 Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- 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: J3 consideration in progress 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. C589, p. 98 states "If a common-block-object is of a derived type, it shall be a sequence type (4.5.1) or a type with the BIND attribute and it shall have no default initialization." It also affects whether the types are extensible. 4.5.6 states "A nonsequence derived type that does not have the BIND attribute is an extensible type." 2. 15.2.2 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. Yes, it was intended that these types have the BIND attribute. An edit makes this clear. 2. A user-defined derived type with the BIND attribute is permitted to have private components. DISCUSSION: 1. It was intended that the behaviour of these types be similar to that of user-declared derived types in all respects except that they interoperate with C pointer types rather than C struct types. As well as the two cases cited in the question, there are special conditions in a pointer assignment statement (7.4.2) if either the pointer or the target has the BIND attribute. Also, there is a restriction on types with the BIND attribute in a SELECT TYPE statement (8.1.5). 2. The rules for the interoperability of a C struct type with a Fortran derived type are less restrictive than the rules in 4.5.1.3 that determine whether two separately declared Fortran types, both with the BIND attribute, are the same. For the types to be the same, the names of corresponding components must agree and all components must be public. It follows that two types may be different although they both interoperate with the same C struct type. EDITS: Page and line numbers refer to 04-007. [397:3] Subclause 15.2.2. At the end of the first paragraph add "Each has the BIND attribute but is not interoperable with any C struct 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 Malcolm Cohen NO vote on F03/0053 The answer to this interp is inconsistent with the answer to F03/0046, as explained in my comment on the latter. The discussion states: 1. It was intended that the behaviour of these types be similar to that of user-declared derived types in all respects except that they interoperate with C pointer types rather than C struct types. That would appear to be the case whether they have the BIND attribute or not, so this does not help to explain the U-turn. User-defined types are permitted not to have the BIND attribute. As well as the two cases cited in the question, there are special conditions in a pointer assignment statement (7.4.2) if either the pointer or the target has the BIND attribute. This does not seem to cause a problem whether these types have the BIND attribute or not. Also, there is a restriction on types with the BIND attribute in a SELECT TYPE statement (8.1.5). This is not a "new" point at all, merely a consequence of whether or not these types are extensible. There is no technical reason for these types not to be extensible - unlike SEQUENCE and BIND(C) types these types are in fact unique and therefore suited for extensibility. In summary, there appears to no technical justification and several non-sequiturs in the rationale. We should not reverse one of the provisions of the standard without good cause. ---------------------------------------------------------------------- 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: transformation, relational equivalence, mathematical value DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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? References are to J3/04-007. 7.1.8.3 Evaluation of numeric intrinsic operations has a discussion of "mathematically equivalent", "mathematical value" and "computational results". 7.1.8.5 Evaluation of relational intrinsic operations has "Two relational intrinsic operations are relationally equivalent if their logical values are equal for all possible values of their primaries." "values" in that context is ambiguous to me. Is it the infinite set of mathematical values or is it the finite set of hardware representable (computational) values? My brief scan of F2003 finds that "values" without any adjectives means what the hardware can represent. Assuming "values" in 7.1.8.5 means what the hardware can represent, then I conclude that the transformation cannot be done. However, Note 7.22 shows "I > J" transformed into "J-I < 0"; which is not true for the finite set of hardware values (due to undefined behavior of overflow), but is true for the infinite set of mathematical values. I believe that "possible values" should be changed to either: possible mathematical values or possible computational values ANSWER: Since it can be undecidable whether expressions are mathematically equivalent, it is clear that the permission to evaluate mathematically equivalent expressions means "if an expression can be determined to be mathematically equivalent it can be used instead." Even in cases where it is easy to determine that expressions are mathematically equivalent, it can be formidably expensive to determine that they are equivalent for the finite but sometimes very large set of "all possible computational values of their primaries." The term "different computational results" includes the case that one expression does not produce overflow when evaluated computationally for some set of computational values of its primaries, while a mathematically equivalent expression does produce overflow when evaluated computationally for some members of that set of values of its primaries. One can imagine a processor that cannot evaluate I > J, but it can evaluate I - J and then examine the sign. This transformation thus has to be allowed for all values, not just for those computational values for which no overflow results. Therefore, the term "all possible values" refers to mathematical values. EDITS: 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 Malcolm Cohen REASON for F03/0065 NO vote: I agree with Bob Corbett that "mathematical" treatment of relationals is inappropriate and unfriendly. We should require the right answer. Processors with deficient hardware that cannot compare numbers without subtraction are notably thin on the ground these days; pandering to them serves no useful purpose. Also, the "mathematical" answer is the wrong answer for IEEE NaNs. Michael Ingrassia reason for F03/0065 NO vote: The value of A < B should require the computation of A and B as coded and the comparison of their computed values. Saying that "all possible values" refers to mathematical values permits unnecessary mathematical rewriting which destroys carefully coded floating point computations. That isn't the interpretation we want. ---------------------------------------------------------------------- NUMBER: F03/0084 TITLE: IEEE_SET_ROUNDING_MODE in a subroutine KEYWORDS: IEEE_ARITHMETIC DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Section 7.1.8.1 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) :: Z 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) No, for a high quality implementation. Given that the processor supports execution with both rounding modes IEEE_NEAREST and IEEE_UP, this subprogram might be executed in either rounding mode (since the rounding mode is inherited from the caller, see [367:20-22]), and the value zero is a bad approximation in the latter case. No edits are necessary. (2) Yes. In this case "X*Y" is an initialization expression, whose value does not change from one appearance to the next. EDITS: Note 14.6 should note additionally that the value of an initialization expression is not affected by changes in the rounding mode. SUBMITTED BY: Michael Ingrassia HISTORY: 06-372 m178 F03/0084 submitted ---------------------------------------------------------------------- NUMBER: F03/0085 TITLE: Finalizing targets of pointer or allocatable actual arguments KEYWORDS: Finalization, pointer actual argument, allocatable actual argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program program Finalize type :: T ... contains final :: ... end type T type(t), pointer :: TV allocate ( TV ) call sub ( TV ) contains sub ( A ) type(t), intent(out) :: A end sub A end program Finalize The eighth paragraph of 10-007, section 4.5.6.3 [76:30-31], says "When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument corresponding to an INTENT(OUT) dummy argument is finalized.'' Q1. Is the target of TV finalized when SUB is invoked? Q2. If TV were allocatable instead of a pointer, would it be finalized? ANSWER: A1. Yes A2. Yes It was intended that an allocatable actual argument or the target of a pointer actual argument that is associated with an INTENT(OUT) dummy argument be finalized when the procedure is invoked. Edits are provided to correct the error. EDITS: In 10-007 Replace the eighth paragraph of 4.5.6.3 [76:30-31] with: "When a procedure is invoked, an object that becomes argument associated with a nonpointer, nonallocatable INTENT(OUT) dummy argument of that procedure is finalized." SUBMITTED BY: Van Snyder HISTORY: 06-374 m178 F03/0085 submitted 10-242 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t(n) INTEGER,LEN :: n REAL v(n) END TYPE END Is the example intended to be standard-conforming? ANSWER: Yes, the example is standard-conforming in F2008. C531 in section 5.3.8.2 [94:15-16] of 10-007 says: "C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, BLOCK construct, or interface body." EDITS: None SUBMITTED BY: Van Snyder HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen) 10-243 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is it allowed to change the value of a variable which supplies the unit number to an 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: In 10-007 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 any or ." 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 ---------------------------------------------------------------------- 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: J3 consideration in progress DISCUSSION: In 12.4.1.6, rules underlying items (7) and (8) (at [04-007:273:7-10]) say that if a POINTER/ALLOCATABLE optional dummy argument is not present then it can not be supplied as an actual argument corresponding to an optional nonpointer/non- allocatable dummy argument. QUESTION: Should the reasons underlying items (7) and (8) also apply to the following two situations: 1.) a polymorphic optional dummy argument that is not present is supplied as an actual argument corresponding to an optional non-polymorphic dummy argument; 2.) a non-present optional dummy argument of derived type with an assumed type parameter is supplied as an actual argument corresponding to an optional dummy argument that does not have the same assumed type parameter One of the reasons that these rules should apply is that the non-present dummy argument might be supplied as the actual argument to a procedure using a different calling convention (pass-by-descriptor to pass- by-address). It appears that the current standard overlooked these two cases. An edit is supplied to correct this oversight. ANSWER: It is intended that these two situations are allowed. In the first case, the actual and dummy arguments are required to have the same declared type, regardless of whether the dummy argument is optional (first paragraph of subclause 12.4.1.2). In the second case, the second paragraph of subclause 12.4.1.2 (at [04-007:269:1-4]) requires the value of the assumed type parameter of the (absent) actual argument to have the same value as the non-assumed type parameter of the (absent) dummy argument. This shouldn't be required. An edit is provided to correct this oversight. EDITS: Replace the second paragraph of 12.4.1.2 (at [04-007:269:1-4]): "The type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument that are not assumed or deferred unless o the dummy argument is not present (12.4.1.6), or o the actual argument is of type default character and the dummy argument is not assumed shape." 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 NO Comment for F03/0103 from Malcolm Cohen: The DISCUSSION is completely irrelevant unless we are talking about POINTER/ALLOCATABLE, which we are not. I probably disagree with the assertion that these two situations "is" or were intended to be allowed. The question needs some example code we can say is right or wrong. (With some example code maybe I could say whether or not I actually agree or disagree with the bold assertion in the ANSWER!) The edit makes the following code fragment legal: Subroutine one(x) Double Precision,Optional :: x Call two(x) End Subroutine two(y) Real,Optional :: y ... I can categorically state that we definitely did NOT intend this to be legal! ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot DISCUSSION: 9.6.2.15p1 [216:32-36] says that when SIZE= specifier is used in a formatted input statement with explicit format specifications, the variable specified in the SIZE= specifier is determined by the data edit descriptors during the input statement. These rules, however, did not take into account the following situation where a parent READ statement with a DT edit descriptor invokes a user-defined DTIO formatted read subroutine that reads input data using a list-directed or namelist READ statement. Consider the following example: module example type A integer x(10) contains procedure :: readArray generic :: read(formatted) => readArray end type contains subroutine readArray (dtv, unit, iotype, v_list, iostat, iomsg) class(A), 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, fmt=*, iostat=iostat, iomsg=iomsg) dtv%x end subroutine end module program test use example type(A) :: v integer countChar open (1, file='example.input', form='formatted') read (1, fmt='(DT)', advance='no', size=countChar) v end program test Note that there is no data edit descriptor in the UDDTIO subroutine, readArray, to count the total number of characters transferred during the child read. QUESTION: Is this example intended to be standard conforming? ANSWER: Yes, the example is standard-conforming. The definition of SIZE= in [10-007 216:31] section 9.6.2.15 does not restrict SIZE= if a child I/O is present. The description of how SIZE= works in [219:25] section 9.6.4.1p22 item (9) clearly indicates that SIZE= should be set even if child I/O occurs (items (5) and (6)). EDITS: None SUBMITTED BY: Jim Xia HISTORY: 07-302 m182 F03/0105 submitted 07-302r1 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 10-247 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: It appears that a hard restriction found in ANSI X3.9-1978 was dropped when we published Fortran 90. The restriction on page 15-13 of the FORTRAN 77 standard says >In a function subprogram, a variable name that is the same >as an entry name must not appear in any statement that >precedes the appearance of the entry name in an ENTRY >statement, except in a type-statement. so FUNCTION S() T = 13.0 ENTRY T() END is not standard-conforming. The restriction appears to be missing from Fortran 90, 95, 2003. Should it still be in force ? ANSWER: No, for whatever reason, the restriction was dropped a long time ago and is not in F2008. The above program does not violate the standard with the placement of the assignment to T. [10-007 310:5-8] Section 12.6.2.6 specifies that the results S and T in the above example share the same memory so S() returns 13.0. As is, the example is not standard-conforming since no return value is set for T(). EDITS: None SUBMITTED BY: Michael Ingrassia HISTORY: 07-341 m182 F03/0110 submitted 10-248 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0116 TITLE: indistinguishable specifics for a generic interface with use association KEYWORDS: GENERIC RESOLUTION USE ASSOCIATION DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: Section 16.2.3 of the Fortran 2003 standard appears to forbid the presence of such conflicting interfaces. Section 12.4.4 clearly is written to allow for such conflicting interfaces, but there is nothing in that section that modifies the sense of Section 16.3.2. The question then becomes, do the rules of 16.3.2 apply only to explicitly declared procedures and to procedures made accessible through use association, or also to those accessible through host association? The committee concludes that the rules of 16.3.2 apply also to procedures accessible through host association. An edit is proposed to make this clear. Although some of the language in 12.4.4.1 could therefore be simplified, it is still useful for processors which extend the standard by relaxing some of the rules in 16.3.2 and there is no reason why it should not remain normative. A NOTE could be added to this section. EDITS: At [04-007.pdf:407:25-26] change "This subclause contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit" to "This subclause contains the rules that shall be satisfied within a scoping unit by every pair of specific procedures that have the same generic identifier, whether the specific procedures are intrinsic or are defined in the scoping unit itself, in the host, or in a module used by the scoping unit." At [04-007.pdf:278:5+] add NOTE: In a standard conforming processor which has not extended (i.e. relaxed) the rules laid out in Section 16.3.2 for pairs of specific procedures, the above rules can be effectively replaced by the somewhat simpler rule ----------------------------------------------------------- (*) Consider the set of specific interfaces of a generic interface that has that name and is in the unit in which the reference appears together with specific interfaces of a generic interface made accessible by a USE statement in the scoping unit. If the scoping unit has a host scoping unit and the name is established to be generic in that host scoping unit, then additionally include in the considered set the specific interfaces of the generic interface in the host scoping unit (regardless of whether the name is accessible in the scoping unit). If the scoping unit contains an INTRINSIC attribute specification for that name or a USE statement that makes that name accessible from a module in which the corresponding name is specified to have the INTRINSIC attribute, then additionally include in the considered set the interfaces of this intrinsic procedure. Then if the reference is consistent with a nonelemental reference to one of the procedures in the set, the reference is to that specific procedure. Failing that, if the reference is consistent with an elemental reference to one of the procedures in the set, the reference is to that specific procedure. In each case the rules in 16.2.3 ensure that at most one such specific procedure is specified. ------------------------------------------------------------ SUBMITTED BY: Robert Corbett and Michael Ingrassia HISTORY: 08-169 m184 F03/0116 submitted ---------------------------------------------------------------------- NUMBER: F03/0118 TITLE: Are lower bounds of assumed-shape arrays assumed? KEYWORDS: LBOUND, assumed-shape array, initialization expression DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Does the following program conform to the 2003 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 an initialization expression according to item (8)(b)(i) in subclause 7.1.7. If the lower bounds of an assumed-shape array are not assumed, LBOUND(A) is an initialization expression in this case, but might be a specification expression in other cases. ANSWER: This program conforms to the 2003 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.1.2.5.2. If a lower bound is specified, it must be specified either by an initialization 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 an initialization expression. Therefore, the reference to LBOUND is an initialization expression, and the reference to SIZE is therefore an initialization expression. EDITS: Before the last sentence of the final paragraph of 5.1.2.5.2, insert a sentence: "The lower bounds of an assumed-shape array are not assumed." or Insert a note after the final paragraph of 5.1.2.5.2: "The lower bounds of an assumed-shape array are not assumed." or None. SUBMITTED BY: Van Snyder HISTORY: 08-200r1 m185 F03/0118 submitted ---------------------------------------------------------------------- NUMBER: F03/0120 TITLE: When are parameterized sequence types the same type? KEYWORDS: type parameter, sequence type DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) What does 4.5.1.3 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 2003 standard allows sequence types to have type parameters (4.5.1, 4.5.1.2). The Fortran 2003 standard also gives rules for deciding when two entities declared with reference to derived-type definitions have the same type (4.5.1.3). Those rules break down for parameterized sequence types. Although the Fortran 2003 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 :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER :: 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 :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER :: 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 2003 standard require a conforming processor to detect and report the conflict with the rules given in 16.2.3? 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) :: N SEQUENCE REAL A(N+N) END TYPE END MODULE M2 TYPE T(N) INTEGER(KIND=4) :: N SEQUENCE REAL A(N*N) END TYPE END SUBROUTINE S(N) USE M1, T1=>T USE M2, T2=>T TYPE(T(N)) :: X TYPE(T(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.1.3. 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 04-007: Replace constraint C433 on line 15 of page 46 with with C433 (R429) If SEQUENCE appears, the derived-type shall not have type parameters and the type-bound-procedure-part shall not appear. Delete the phrase "type parameters and" from line 8 of page 47. SUBMITTED BY: Robert Corbett HISTORY: 08-261 m185 F03/0120 submitted ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot 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, the result of the intrinsic function REAL with KIND argument wp returns a value that is of type REAL(KIND=wp). However, the description of REAL says that in this case "the result is equal to a processor-dependent approximation to A". Furthermore, 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 using assignment to a VOLATILE variable. EDIT: 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 ---------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Consider the program PROGRAM MAIN TYPE T INTEGER :: I = BIT_SIZE(J) END TYPE ! J = 0 CALL SUBR1 CONTAINS SUBROUTINE SUBR1 J = 1 CALL SUBR2 PRINT *, J END SUBROUTINE SUBROUTINE SUBR2 J = 2 END SUBROUTINE END Q1. Is this program standard-conforming? (In particular, is it permitted to have the first, or only, appearance of a local variable name appear within a type definition. The definition of implicit typing says that J is explicitly declared within T.) Q2. (a) If not, is it standard-conforming if the comment "! J = 0" is turned into the assignment statement "J = 0"? (b) If it is standard-conforming, what does it print? (If J is a local variable of MAIN, it should print 2.) ANSWER: A1. Yes, the program is standard-conforming. The definition of implicit typing is erroneous - J is a local entity of MAIN. An edit is supplied to correct this error. A2. (a) Not applicable. (b) The program will print the value 2. EDITS to 10-007: [109:22-23] In 5.5p4, After "The data entity is treated as if it were declared in an explicit type declaration" replace "in" with "; if", then after "the outermost inclusive scope in which it appears" insert "is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". Note: This makes the whole sentence read "The data entity is treated as if it were declared in an explicit type declaration; if the outermost inclusive scope in which it appears is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-268 m185 F03/0123 submitted 10-244 m193 Revised answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: definition is poorly defined KEYWORDS: definition DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the program: PROGRAM MAIN TYPE T1 SEQUENCE INTEGER I, J END TYPE TYPE T2 SEQUENCE INTEGER I, J END TYPE TYPE(T1) X TYPE(T2) Y EQUIVALENCE (X, Y) X%I = 1 X%J = 2 PRINT *, X, Y END Is this program standard-conforming, and if so, what does it print? According to items (1) and (12) of 16.6.5, the assignment to X%I causes both X%I and Y%I to become defined. Similarly, the assignment to X%J causes both X%J and Y%J to become defined. Then, according to item (15) of 16.6.5, both X and Y become defined. However, according to 4.5.2.4, X and Y are types with different names, and therefore are of different type, thus according to 16.6.6 item (1) when X becomes defined Y becomes undefined, and vice versa. This appears to be a contradiction. ANSWER: The program was intended to be standard-conforming. An edit is supplied to remove the apparent contradiction. The program should print something like " 1 2 1 2". EDITS: [455:14+] In 16.6.6 item (1), insert new sub-list item "(c) When all components of a structure of a numeric sequence type or character sequence type become defined as a result of partially associated objects becoming defined, an associated variable of a different type does not become undefined." SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted 10-245 m193 Draft answer - Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 ** start negative comments Robert Corbett's No vote on F03/0124: I agree with Malcolm Cohen that the new text is a big improvement over the existing text. However, I also take Van Snyder's point that there is further room for improvement. I think with a bit more work in Section 16.6 of 10-007, an interpretation that covers all the cases that should be allowed could be achieved. Van Snyder's No vote on F03/0124: The answer implied by the edits is too restrictive. It should be something like "When a component of a structure of numeric sequence type or character sequence type becomes defined as a result of partially associated objects becoming defined, associated components of the same type that are components of an object of different type do not become undefined." (This is ugly and will need some polishing, but you get the idea.) Malcolm replied to Van: The answer is less restrictive than the text currently in the standard, in that it adds another exception to the blanket requirement. It would help if you supplied an example you think remains non-conforming after this change but that you think should be conforming. Reading your proposed replacement text I am at a loss to see how the effect of it differs from that in the interp. (If there is a difference, I'm sure I could work it out eventually, but you must have something in mind already, right?) Van replied to Malcolm: I had in mind the case of common block declarations resulting in partial and overlapping storage associations of numeric sequence type objects in such a way that their ultimate storage-associated components have the same types and kinds. That is, defining any component wouldn't undefine anything. Suppose for example that in one scoping unit there is a common block with two numeric sequence type objects, each having two default integer components. In another there is the same common block with a default integer, a sequence type object with two default integer components, and another default integer. Assigning to any of the numeric sequence objects shouldn't undefine anything. result of ballot on F03/0124: /interp will take this back for more work to solve the closely-related problem raised by Van. We probably hwill be editing the same text to solve Van's extra problem => F03/0124 fails. ** end negative comments ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended to disallow vendors to provide namelist output that includes a subobject designator followed by a value? ANSWER: Yes. The processor is required to produce output in the form specified by 10.11.4.3 "Namelist output records". 10.11.4.3 paragraph 2 states "The name of each namelist group object list item is placed in the output record followed by an equals and a list of values of the namelist group object list item." This unambiguously states that each namelist group object list item (these are the ones listed in NAMELIST statements) have their names placed in the output record followed by an equals sign and the list of their values. Subobject designators do not appear in NAMELIST statements. EDIT: None. SUBMITTED BY: John Reid HISTORY: 09-115 m187 F03/0128 submitted 09-115r1 m187 Passed by J3 meeting + F2008 fix {pulled} 09-187r2 m188 Failed J3 letter ballot #18 09-155: accept edit line number change, F2008 fix from m187 does not appear in 09-007r1; 10-239 m193 Revised answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- 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/0001 TITLE: Generic resolution with pointer dummy arguments KEYWORDS: Generic, Pointer, Allocatable DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTERFACE gen SUBROUTINE suba(a) REAL,ALLOCATABLE :: a(:) END SUBROUTINE SUBROUTINE subp(p) REAL,POINTER,INTENT(IN) :: p(:) END SUBROUTINE END INTERFACE REAL,ALLOCATABLE,TARGET :: x(:) ALLOCATE(x(100)) CALL gen(x) The call to gen(x) is compatible both with suba, since x is allocatable, and with subp, since x and p satisfy the requirements in 12.5.2.7 paragraph 2 (p is an INTENT(IN) pointer, x is an allowable target for p). Is this program fragment standard-conforming, and if so, which actual procedure is called? ANSWER: This program was not intended to be standard-conforming. An edit is supplied to add a sufficient requirement. EDITS to 10-007: [286:4] In 12.4.3.4.5p3, after "the other has the POINTER attribute", Insert "and not the INTENT(IN) attribute". SUBMITTED BY: Bill Long HISTORY: 10-145 m192 F08/001 submitted 10-145r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0002 TITLE: Are assumed- or deferred-shape objects allowed in namelist? KEYWORDS: assumed-shape, deferred-shape, namelist DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: At [10-007:111:19-23 5.6p5] it says A namelist group object shall either be accessed by use or host association or shall have its type, type parameters, and shape specified by previous specification statements or the procedure heading in the same scoping unit or by the implicit typing rules in effect for the scoping unit. Because "type parameters, and shape" appears, is the following conforming? real, allocatable :: A(:) real, pointer :: B(:) character(len=:), allocatable :: C namelist /N/ A, B, C DISCUSSION: The wording of 5.6p5 is a result of not completely finishing the replacement of the constraint at [97-007r2:66:1-4 5.4]: A shall not be an array dummy argument with nonconstant bound, a variable with nonconstant character length, an automatic object, a pointer, a variable of a type that has an ultimate component that is a pointer, or an allocatable array. by [04-007:95:10 5.4 C574] which became [09-007r3:111:10 5.6 C585]: C585 (R564) A shall not be an assumed-size array. ANSWER: It was intended that the above conform. Edits are supplied to clarify this. EDITS to 10-007: In the first sentence of [111:19 5.6p5], replace "type parameters, and shape" by "kind type parameters, and rank". SUBMITTED BY: Van Snyder on behalf of Tobias Burnus HISTORY: 10-146 m192 F08/0002 Submitted 10-146r1 m192 Proposed answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0003 TITLE: Is a disassociated pointer allowed as an actual DIM argument? KEYWORDS: DIM argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Several intrinsic functions, such as ANY, have a DIM argument, with the rank of the result depending upon whether it is present. There is a prohibition against the actual argument being an optional dummy argument, but not against it being a disassociated pointer or deallocated allocatable. Is the following program standard conforming, and if so what does it print? program DIM_Arg integer, pointer :: Dim => NULL() logical :: Mask(2,2) = & & reshape( (/ .true., .false, .false, .true. /), (/ 2, 2 /) ) print *, shape( any(mask,dim) ) end program DIM_Arg The description worked until we allowed a disassociated pointer or unallocated allocatable variable that is associated with a nonpointer nonallocatable optional argument to be interpreted not to be present. ANSWER: It was intended that this program not conform. It was an oversight that disassociated pointer and unallocated allocatable actual arguments were not prohibited to correspond to DIM dummy arguments for these intrinsic functions. Edits are provided to clarify this. These functions were intended to behave similarly to MAXLOC et al, where this issue does not arise. Edits are provided to change the descriptions accordingly. EDITS to 10-007: [13.2.4p1 316:24-25] Replace "an optional" by "a" and replace ", if present, specifies" by "can specify". [13.5 Table 13.1 319] Replace "ALL ( MASK [, DIM ])" by "ALL ( MASK ) or ALL ( MASK, DIM )". Replace "ANY ( MASK [, DIM ])" by "ANY ( MASK ) or ANY ( MASK, DIM )". [13.5 Table 13.1 322] Replace "NORM2 ( X [, DIM ])" by "NORM2 ( X ) or NORM2 ( X, DIM )". Replace "PARITY ( MASK [, DIM ])" by "PARITY ( MASK ) or PARITY ( MASK, DIM )". [13.5 Table 13.1 323] Replace "THIS_IMAGE (COARRAY[, DIM])" by "THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.10 328:2] Replace the subclause heading by "ALL ( MASK, DIM ) or ALL ( MASK )" [13.7.10p3 328:7] In the description of the DIM argument, delete "(optional)". [13.7.10p4 328:10] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.13 329:6] Replace the subclause heading by "ANY ( MASK, DIM ) or ANY ( MASK )" [13.7.13p3 329:11] In the description of the DIM argument, delete "(optional)". [13.7.13p4 329:14] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.41p3 338:31] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.90p3 360:4] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.91p3 360:25] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.123 374:24] Replace the subclause heading by "NORM2 ( X, DIM ) or NORM2 ( X )" [13.7.123p3 374:29] In the description of the DIM argument, delete "(optional)". [13.7.123p4 374:31] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.128 377:20] Replace the subclause heading by "PARITY ( MASK, DIM ) or PARITY ( MASK )" [13.7.128p3 377:25] In the description of the DIM argument, delete "(optional)". [13.7.128p4 377:28] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.165 392:6] Replace "or THIS_IMAGE (COARRAY[, DIM]) by ", THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.165p3 392:11] In the description of the DIM argument, delete "(optional)". [13.7.171p3 394:27] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.172p3 395:11] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". SUBMITTED BY: Van Snyder HISTORY: 10-148 m192 F08/0003 submitted 10-148r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- 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 letter ballot 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: It is intended that the program is conforming and prints F. Edits are provided to clarify this. NOTE: This subsumes interp F08/0005 (10-152). EDITS to 10-007: [330:8] Fix the description to read "Query pointer association status". Change the description of the interface to state explicitly that the TARGET dummy argument has the POINTER and INTENT(IN) attributes. A nonpointer actual argument is now permitted by 12.5.2.7p2 to correspond to an INTENT(IN) pointer dummy argument, whereupon the dummy argument becomes pointer associated with the actual argument. The result is that a disassociated TARGET actual argument cannot be considered to be absent. [13.7.16p3 330:14] Before "If TARGET" insert "The dummy argument TARGET has the POINTER and INTENT(IN) attributes." Replace "TARGET" by "the actual argument". [13.7.16p3 330:15+] Insert a note: "NOTE 13.8a This requires the actual argument for TARGET to have the POINTER or TARGET attribute. If the actual argument is not a pointer, the dummy argument TARGET is associated with the actual argument (12.5.2.7)." [13.7.16p5 Cases (iv) and (v) 330:23-29] Delete Cases (iv) and (v) because they will be subsumed be the revisions of cases (vi) and (vii). [13.7.16p5 Case (vi) 330:30] Replace "a scalar pointer" by "scalar". [13.7.16p5 Case (vii) 330:33] Delete "pointer". 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 ------------------------------------------------------------------------ NUMBER: F08/0005 TITLE: optional arguments and ASSOCIATED KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Subsumed by F08/0004 QUESTION: If the actual argument associated with the dummy argument TARGET of the intrinsic function ASSOCIATED is a disassociated pointer, is the dummy argument TARGET to be treated as an optional argument that is not present or as an argument that is present? ANSWER: The dummy argument TARGET should be treated as an argument that is present. DISCUSSION: This problem was created by the Fortran 2008 extension that declares that a dummy argument is not present if it corresponds to an actual argument that is a disassociated pointer [12.5.2.12p1, 299:15-17]. Among the solutions that have been suggested are (1) removing the extension, (2) restricting the extension to apply only to user-defined functions, (3) adding an exception to the extension for the intrinsic function ASSOCIATED, (4) changing the specification of ASSOCIATED in [17.7.16, 330:7-42] to specify two signatures. As attractive as the first two solutions are, I initially favored solution (3) as it caused the least change to the language as defined in recent drafts. I proposed to add text to Section 12.5.2.12 specifying the exception. Over time, I changed my mind; I now favor solution (4). I initially favored solution (3) over solution (4) because solution (4) does not treat the dummy argument TARGET as not present when the corresponding actual argument is an optional argument that is not present. That functionality is in Fortran 2003, and I did not think it should be removed. The more I thought about the issue, the more I was convinced that that functionality is useless except for programs written for test suites. I am now convinced that removing that functionality improves the language by making it possible for a processor to treat use of that functionality as the error it almost certainly is. EDITS to 10-007: [13.7.16, 330:7] Replace "ASSOCIATED (POINTER [,TARGET])" with "ASSOCIATED (POINTER) or ASSOCIATED(POINTER, TARGET)". [13.7.16, 330:18] Replace "is absence" with "does not appear". [13.7.16, 330:19] Replace "is present" with "appears". [13.7.16, 330:23] Replace "is present" with "appears". [13.7.16, 330:26] Replace "is present" with "appears". [13.7.16, 330:30] Replace "is present" with "appears". [13.7.16, 330:33] Replace "is present" with "appears". SUBMITTED BY: Robert Corbett HISTORY: 10-152 m192 F08/0005 submitted - subsumed by F08/0004 10-202 m192 Confirmed as amended by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0006 TITLE: Generic resolution, intrinsic procedures, and host association KEYWORDS: intrinsic, generic, host association DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The specifications of some intrinsic functions and subroutines explicitly ban certain combinations of arguments, even though those combinations are included in the title and the argument portion of the specification of the function or subroutine. Examples include CMPLX and RANDOM_SEED. Other requirements include being a valid KIND type parameter value (e.g. INT) or having having character length 1 (e.g. ICHAR). Consider the program fragment PROGRAM p INTERFACE cmplx LOGICAL FUNCTION mycmplx(a,b) COMPLEX a REAL b END END INTERFACE INTERFACE random_seed SUBROUTINE my_random_seed(get,put,size) INTEGER,OPTIONAL :: get(:),put(:),size END SUBROUTINE END INTERFACE INTERFACE int INTEGER FUNCTION myint(i,j) END END INTERFACE COMPLEX :: z = (1,2) REAL :: r = 3 CALL check CONTAINS SUBROUTINE check INTRINSIC int,cmplx,random_seed PRINT *,cmplx(z,r) ! Reference (1). CALL random_seed(GET=a,PUT=b) ! Reference (2). PRINT *,int(3,17) ! Reference (3). END SUBROUTINE END PROGRAM Are the procedure references (1), (2), and (3) invalid references to the intrinsic procedures CMPLX, RANDOM_SEED, and INT, or are they valid references to the user procedures mycmplx, my_random_seed, and myint respectively? ANSWER: Reference (1) is a valid reference to the user procedure. Both references (2) and (3) are invalid references to the intrinsic procedures; however, no constraints are violated so a standard- conforming processor may do anything, including treating them as references to the user procedures. DISCUSSION: 12.5.5.2 paragraph 4 explains that the reference is to the intrinsic procedure if it is "consistent with the interface of that intrinsic procedure". The interface to an intrinsic procedure consists of its name, characteristics, and dummy argument names. The characteristics of a procedure as defined by 12.4.1 do not include arbitrary restrictions such as those for RANDOM_SEED which are on argument presence (an execution time concept). Nor are requirements such as an actual argument being required to be a constant expression part of an interface. In the case of CMPLX however, there is no specific version whose interface has an X argument of type COMPLEX and any Y argument. 13.7.36 describes this by "If X is of type complex, no actual argument shall correspond to Y". Therefore the reference to CMPLX with such arguments is not consistent with the intrinsic. EDITS to 10-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-153 m192 F08/0006 submitted 10-153r1 m192 Draft answer 10-153r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Amended by J3 letter ballot 10-199; failed J3 letter ballot 10-199 10-236 m193 Revised answer for F2008 10-236r1 m193 Revised example - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ------------------------------------------------------------------------ NUMBER: F08/0007 TITLE: Can zero have more than one bit sequence representation? KEYWORDS: zero, bits DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Question (1): Some processors provide two internal representations for the integer value zero. The ones' complement representation of signed integers and the signed-magnitude representation of signed integers both provide two representations for zero. Must a processor for such a machine use a bit sequence consisting of all zero bits to represent zero, regardless of the internal representation of zero? Question (2): The Fortran 2008 standard [13.3.1, 317:9] states The interpretation of a negative integer as a sequence of bits is processor dependent. Could a standard-conforming processor interpret all negative integers as a sequence of all zero bits? ANSWERS: Answer to question (1): Yes. The standard does not allow for more than one bit representation of zero. Answer to question (2): No. The standard specifies that the integer value of a string of all zero bits is zero. The standard does not specify the integer values for bit strings when the leftmost bit is one. A processor could interpret all negative integers as a sequence of a one followed by all zero bits. It would not be a useful bit representation but it is not disallowed. EDITS to 10-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-154 m192 F08/0007 submitted 10-154r1 m192 Draft answer 10-154r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0008 TITLE: IEEE exceptions for intrinsic functions KEYWORDS: IEEE_INVALID, SQRT DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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: Question (1): No. If the processor does not support IEEE_INVALID, it cannot signal IEEE_INVALID. Question (2): No. The standard does not specify the behavior of SQRT on qNaN. EDITS to 10-007: None. 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 ------------------------------------------------------------------------ NUMBER: F08/0009 TITLE: Is ABS ever required to be the optional IEC 60559 abs? KEYWORDS: ABS, IEEE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Are there any circumstances where the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in the optional portion of IEC 60559? DISCUSSION: Chapter 14 of F2008 does not define an IEEE_ABS intrinsic as a separate IEEE version of ABS and the example given in Section 14.11.3p7 [409:26] requires that ABS comply with the function abs specified in the optional portion of IEC 60559. We infer that the standard intended for the ABS intrinsic to be compliant with the IEC 60559 definition. ANSWER: Yes, the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in IEC 60559. An edit is provided to make that explicit. EDITS to 10-007: In 14.9p1 [406:15+] add a bullet after the second bullet of the list: "the IEEE function abs shall be provided by the intrinsic function ABS," SUBMITTED BY: Robert Corbett HISTORY: 10-156 m192 F08/0009 submitted 10-156r1 m192 Draft answer 10-156r2 m192 Revised answer 10-156r3 m192 Revised again - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0010 TITLE: deallocating objects that are associated with other objects KEYWORDS: DEALLOCATE associated DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1: Consider the program SUBROUTINE SUBR(A) REAL A(*) REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q DEALLOCATE (P) END PROGRAM MAIN REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q ALLOCATE(P(100)) P = 1.0 Q => P CALL SUBR(Q(1:100:11)) END The subroutine SUBR deallocates the object containing the subobject associated with the nonpointer argument A. Is it intended that a pointer may be deallocated while its target is associated with a nonpointer entity? Q2: Consider the code fragment ASSOCIATE (X=>A(3)) DEALLOCATE (A) X = 0.0 where A is an allocatable array that is allocated at the start of the code fragment. Is it intended that an allocatable variable may be deallocated while it is associated with an associate name? ANSWER: A1: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. A2: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. EDITS to 10-007: [6.7.3.2p1, 130:23] Add the following sentence to the end of the paragraph "An allocatable variable shall not be deallocated if it or any subobject of it is argument associated with a dummy argument or construct associated with an associate name." [6.7.3.3p1, 131:27] Add the following sentence to the end of the paragraph "A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name." SUBMITTED BY: Robert Corbett HISTORY: 10-157 m192 F08/0010 submitted 10-157r1 m192 Draft answer 10-157r2 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0011 TITLE: How many times are constructed values finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f10,f11 End Type Type,Extends(t1) :: t2 Real d Contains Final :: f20,f21 End Type Contains Subroutine f10(x) Type(t1),Intent(InOut) :: x Print *,'f10 called' End Subroutine Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine Subroutine f20(x) Type(t2),Intent(InOut) :: x Print *,'f20 called' End Subroutine Subroutine f21(x) Type(t2),Intent(InOut) :: x(:) Print *,'f21 called' End Subroutine End Module Program q Call sub(1.5,2.5) End Program Subroutine sub(x,y) Use m Type(t1),Parameter :: p1 = t1(2.5) Type(t2),Parameter :: p2 = t2(3.5,-3.5) Call s10(t1(x)) Call s11([p1]) ! (a) Call s11([t1(x)]) ! (b) Call s11([ [ [ p1,p1 ] ] ]) ! (c) Call s20(t2(x,y)) Call s21([p2]) ! (d) Call s21([t2(y,y)]) ! (e) Call s21([t2(t1=p1,y)]) ! (f) Call s21([t2(t1=t1(x),y)]) ! (g) Call s21([(p2,t2(x,y),i=1,10**7)]) ! (h) End Subroutine The topic is how many times each final procedure is called on return from each subroutine? For s10, clearly f10 is called once. For s11(a), clearly f11 is called once, and f10 is not called. For s11(b), the standard (4.5.6.3 para 5) seems to indicate that f10 is called. That would not make much sense - the value of the structure constructor is part of the value of the array constructor, so calling f10 would mean that that array element would be finalized twice (once by f11, once by f10, in no set order). For s11(c), the standard standard appears to say that f11 is called three times, once for each (nested) array constructor. Seeing as how nesting array constructors is a syntactic thing that makes zero difference to the value - the value of [[anything]] is identical in every respect to the value of [anything] - this does not seem to make sense. For s20, clearly f20 is called once, and f10 is called afterwards to finalize the parent component. For s21(d), clearly f21 is called once, followed by f11 to finalize the parent components. f20 and f10 are not called. For s21(e), f21 and f11 are called as in s21(d); the standard implies that f20 and then f10 are called, but that does not make sense, the same as case s11(b). For s21(f), the situation seems to be the same as s21(e); the wanted f21 and f11, and (unordered) the unwanted f20 and f10. For s21(g), f21 and f11 are called as in s21(d); the standard implies that f10 is called to finalize t1(3) and also that f20 and then f10 are called to finalize t2(t1=t1(3),4). This makes even less sense than before, since the t1 part of the array constructor element is going to be finalized 3 times just because of the syntax we used. For s21(h), f21 and f11 are called as in s21(d) to finalize the whole array constructor value; the standard also implies that f20 and then f10 are called on all of the 5000000 even-numbered elements. Requiring the processor to keep track of all those elements to be finalized on return from s21 seems rather severe. Furthermore, an object that has been finalized is not permitted to be referenced or defined. That makes the multiple finalization interpretation even more hard to understand. Philosophically, finalization should finalize objects exactly once. There seem to be three possibilities here. (1) The finalizers are called multiple times, but on the separate entities created by the constructors. For example s21(g), that is t1(3) is created as object X, when t2(...) is evaluated a new separate object Y is created and that value is copied into it, and when [...] is evaluated a third object Z is created with the value of Y copied into it; afterwards, we effectively have call f10(X); call f20(Y); call f21(Z); call f11(Z%t1) For s21(h) that burden is going to be extreme because the standard says these are "finalized after execution of the innermost executable construct containing the reference" (and it is possible to detect this in a conforming program); changing that to "finalized after the value has been used" would be better if slightly vague. (2) These entities are indeed finalized multiple times, just as the standard implies. (3) Constructors that are merely providing part of the value of a bigger constructor are not finalized. (4) Constructors should never be finalized in themselves, this was just a design error that inevitably leads to multiple or unwanted finalization. Which is the correct approach? ANSWER: Approach 4. Constructors don't do anything that needs finalization. Edits are provided to correct the mistake. NOTE: This answer subsumes interp F08/0012 (10-159r1). EDITS to 10-007: [24:9] Change the first word of 1.6.2 "This" -> "Except as identified in this subclause, this". [24:11+] Insert new paragraph. "Fortran 2003 specified that array constructors and structure constructors of finalizable type are finalized. This part of ISO/IEC 1539 specifies that these constructors are not finalized.". [76:24-25,28-29] Delete paragraphs 5 and 7 of 4.5.6.3 (When finalization occurs). SUBMITTED BY: Malcolm Cohen HISTORY: 10-158 m192 F08/0011 submitted 10-158r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0012 TITLE: Are constants finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Subsumed by F08/0011 QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f10,f11 End Type Type,Extends(t1) :: t2 Real d Contains Final :: f20,f21 End Type Contains Subroutine f10(x) Type(t1),Intent(InOut) :: x Print *,'f10 called' End Subroutine Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine Subroutine f20(x) Type(t2),Intent(InOut) :: x Print *,'f20 called' End Subroutine Subroutine f21(x) Type(t2),Intent(InOut) :: x(:) Print *,'f21 called' End Subroutine End Module Program q Use m Type(t1),Parameter :: p1 = t1(1.5) Type(t2),Parameter :: p2 = t2(2.5,-3.5) Type(t1),Parameter :: ap1 = [ p1 ] Type(t2),Parameter :: ap2 = [ p2 ] Call sub1(p1) Call sub1(t1(1.5)) ! (*) Call sub2(p2) Call sub2(t2(2.5,-3.5)) ! (*) Call sub1a(ap1) Call sub1a([p1]) ! (*) Call sub2a(ap2) Call sub2a([p2]) ! (*) End Program The topic is how many times each final procedure is called on return from each subroutine? Clearly, the final procedures are not called on return from the calls not marked with an asterisk. For the ones marked with an asterisk, the situation is less clear. The standard says that a structure constructor or array constructor is finalized "[if] an executable construct references [it]" (4.5.6.3p5). However, the term "reference" is not defined for these entities; the closest would seem to be "appearance of a data object designator in a context requiring its value at that point during execution" which would appear on the face of it to mean that these entities are finalized since the constructor appears in a context requiring its value. Possible interpretations might be (a) Yes, the entities are required to be finalized (so the relevant final procedure is executed). (b) The text in 4.5.6.3p5 was not intended to be applied to constants (the standard is defective). (c) The processor can optionally evaluate an alternative expression with the same value, viz an named constant, so it is processor dependent whether the finalizer is called. Option (a) seems inconsistent with named constants otherwise being equivalent to their constant expression. Option (c) argument could be equally applied to nonconstant constructors, so this would make all finalization of constructed values optional. That would seem inconsistent with the purpose of finalization. Which is the correct approach? ANSWER: Subsumed by F08/0011. EDITS: N/A. SUBMITTED BY: Malcolm Cohen HISTORY: 10-159 m192 F08/0012 submitted 10-159r1 m192 Revised - subsumed by F08/0011 10-202 m192 Confirmed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0013 TITLE: How does finalization interact with allocatable assignment? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine End Module Program q Use m Type(t1),Parameter :: ap1(1) = [ t1(1.5) ] Type(t1),Parameter :: ap2(3) = [ t1(2.5),t1(3.5),t1(4.5) ] Type(t1),Parameter :: ap3(3) = t1(0.5) Type(t1),Allocatable :: x(:) x = ap1 ! (*1) x = ap2 ! (*2) x = ap3 ! (*3) End Program The topic is how 4.5.6.3 paragraphs 1 and 9 interact. The relevant texts are, respectively: "When an allocatable entity is deallocated, it is finalized." "When an intrinsic assignment statement is executed, the variable is finalized after evaluation of and before the definition of the variable." In the assignment marked (*1), paragraph 9 says that the variable (X) is finalized, i.e. CALL F11(X) is executed. However, this would be invalid, because an unallocated allocatable would be associated with a nonallocatable nonoptional dummy argument. In the assignment marked (*2), paragraph 9 again says that the variable is finalized - after evaluation of but before the definition of the variable. However, because the shapes of the variable and the expression differ, definition of the variable involves deallocating the variable (and allocating it with the correct shape). Paragraph 1 says that deallocating the variable finalizes it, so that means that F11 should be called twice for the variable. This is problematic since a finalized entity is not permitted to be referenced or defined by a final subroutine. In the assignment marked (*3), the variable and expression have the same shape so the variable will not be deallocated, so according to paragraph 9 it should be finalized once. Q1. Are all the assignment statements standard-conforming? Q2. How many times is the variable finalized (i.e. how many times is the final subroutine called) in each standard-conforming case? ANSWER: A1. Yes, all the assignment statements are intended to be standard conforming. Edits are supplied to correct the problem in (*1). A2. The variable is finalized exactly once, except when it was unallocated (and then it is not finalized). Edits are supplied to correct the problem in (*2). EDITS to 10-007: [76:17] In 4.5.6.3 When finalization occurs, paragraph 1, After "it is finalized" Insert "unless it is the variable in an intrinsic assignment (7.2.1.3) or a component thereof". [76:32] In 4.5.6.3 When finalization occurs, paragraph 9, change "the variable" to "if the variable is not an unallocated allocatable variable, it", [76:33] append new sentence to paragraph: "If the variable is an allocated allocatable that would be deallocated by intrinsic assignment, the finalization occurs before the deallocation.". Then, move the revised [76:32-33] (4.5.6.3p9) to precede the existing paragraph 1, i.e. [76:17-]. SUBMITTED BY: Malcolm Cohen HISTORY: 10-160 m192 F08/0013 submitted 10-160r1 m192 Revised 10-160r2 m192 Revised edit - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0014 TITLE: Finalizing assignment to vector-subscripted object KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' x%c = 0 ! (*) End Subroutine End Module Program q Use m Type(t1) :: x(10) = t1(0) x( [1,4,9] ) = t1(1.5) Print *,x End Program According to 6.5.3.2.2 Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." Therefore the program above is not standard-conforming; however it seems that deleting the assignment statement marked (*) would make the program standard-conforming. This seems to make final subroutines not useful when vector subscripts are involved; either the finalization doesn't do anything to the object in which case the vector subscript is allowed, or it does do something (like deallocation) in which case the vector subscript is disallowed. Also, since passing vector-subscripted objects as actual arguments is almost certainly going to pass a copy (and what's more a copy that won't be copied back), this results in something other than the actual entity being finalized - and this is possibly visible if pointers and targets are involved. Finally, these apparent violations of the standard are probably not going to be detected on many processors, resulting in silent wrong answers. At least if vector subscripted sections being finalized were rejected at compile time the user would stand a chance of avoiding these problems. Q. Is this analysis correct, and is this situation deliberate? ANSWER: A. The analysis is correct. This should have been alleviated by allowing elemental procedures to modify vector-subscripted arguments. An edit is supplied. EDITS to 10-007: [124:7+] Insert new paragraph "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine." [295:8] In 12.5.2.4p18, After "If" insert "the procedure is nonelemental and". SUBMITTED BY: Malcolm Cohen HISTORY: 10-161 m192 F08/0014 Submitted 10-161r1 m192 Revised answers and edits. 10-161r2 m192 Selected alternative answer, revised edits - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0015 TITLE: IMPLICIT KEYWORDS: IMPLICIT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 5.5 IMPLICIT statement contains the permission-giving statement: "The mapping may be to a derived type that is inaccessible in the local scope if the derived type is accessible to the host scope." But what if the derived type is not accessible to the host scope? Consider the module: module m implicit type(t) (a-z) type t real x end type contains subroutine s(x) type t character(10) c end type call inner(x) contains subroutine inner(y) a = x b = y print *,a%x,b%x end subroutine end subroutine end module In inner, the mapping is not to a derived type that is accessible to the host scope. Is this module standard-conforming? ANSWER: Yes. The statement apparently giving permission is in error: no permission needs to be given here, it simply follows from the other scoping rules. An edit is provided to clarify the standard. EDITS to 10-007: [109:21-22] (5.5p4) Delete the confusing sentence "The mapping may ... scoping unit.". SUBMITTED BY: Malcolm Cohen HISTORY: 10-162 m192 F08/0015 submitted 10-162r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0016 TITLE: Can a vector-subscripted argument become undefined? KEYWORDS: Vector subscript, actual argument, undefined. DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: According to 6.5.3.3.2 [124] Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." How can we predict the future? And even if we could, it implies that it would be ok for the dummy array to be undefined (because it only forbids becoming defined). As it happens, 12.5.2.4p18 [295:8-9] already says it is not definable, so already covers being defined and redefined - and also becoming undefined, and also prevents not just INTENT(OUT) or INOUT but also ASYNCHRONOUS and VOLATILE. What is the point to this future-predicting confusing redundancy? ANSWER: This paragraph is completely redundant as well as incomplete. C724 [158:19-20] covers in a pointer assignment statement. 9.4p2 [203:6-7] copvers internal files. An edit is supplied to correct this situation. EDITS to 10-007: [124:4-7] Delete 6.5.3.3.2 paragraph 2. SUBMITTED BY: Malcolm Cohen HISTORY: 10-163 m192 F08/0016 submitted 10-163r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0017 TITLE: Elemental subroutine restrictions KEYWORDS: ELEMENTAL, SUBROUTINE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following elemental subroutine ELEMENTAL SUBROUTINE test_add(a,b) REAL,INTENT(IN) :: a,b REAL c c = a+b END SUBROUTINE and the following reference: REAL x(10),y LOGICAL toobig ... CALL IEEE_SET_FLAG(IEEE_OVERFLOW,.FALSE.) CALL test_add(x,y) CALL IEEE_GET_FLAG(IEEE_OVERFLOW,toobig) The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow. Is this program fragment standard-conforming? 12.8.3 says "In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments corresponding to INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them." Obviously, it is not the case that all actual arguments are scalar. However, there not being any actual arguments corresponding to INTENT(OUT) or INTENT(INOUT) dummy arguments, it is not possible for the remaining actual arguments (x and y) to be conformable with them. Is this an oversight? (If not, it seems a very clumsy way of requiring elemental subroutines to have an INTENT(OUT) or INTENT(INOUT) argument, and one that doesn't work if they are only referenced with scalar arguments.) ANSWER: Yes, the program fragment is intended to be standard-conforming. An edit is supplied to correct the oversight in the standard. EDITS to 10-007: [314:16-19] In 12.8.3, replace the second sentence "In ... them." by "In a reference to an elemental subroutine, if any argument is an array, all actual arguments that correspond to INTENT (OUT) or INTENT (INOUT) dummy arguments shall be arrays. All actual arguments shall be conformable." NOTE: This edit is potentially subsumed by the edit in the interp F08/0018 (10-168r1) "Impure elemental restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-167 m192 F08/0017 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0018 TITLE: Impure elemental restrictions KEYWORDS: IMPURE, ELEMENTAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: With the following two impure elemental procedures, which perform essentially the same calculations, IMPURE ELEMENTAL SUBROUTINE one(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x END SUBROUTINE IMPURE ELEMENTAL REAL FUNCTION two(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x two = y - z END FUNCTION consider these references: REAL a(10),b,c ... CALL one(b,a) ! (i) ok, equivalent to CALL one([(b,i=1,10)],a) CALL one(a,b) ! (ii) not ok, prohibited by 12.8.3p1, sentence 2. c = two(b,a) ! (iii) ok, like (i) d = two(a,b) ! (iv) NOT prohibited!?! Was allowing case (iv) an oversight? ANSWER: Yes, this was an oversight: after adding impure elementals, the elemental subroutine argument restrictions need to apply to elemental functions as well. EDITS to 10-007: [314:7+] Insert new paragraph as follows. "In a reference to an elemental procedure, if any argument is an array, all actual arguments that correspond to INTENT (OUT) or INTENT (INOUT) dummy arguments shall be arrays. All actual arguments shall be conformable." [314:11-12] In 12.8.2, delete the third sentence; that sentence reads "For those ... conformable.". {Redundant with new paragraph.} [314:16-19] In 12.8.3, delete the second sentence; that sentence reads "In a reference ... conformable with them.". {Redundant with new paragraph.} NOTE: These edits subsume the one in the interp F08/0017 (10-167r1) "Elemental subroutine restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-168 m192 F08/0018 submitted 10-168r1 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0019 TITLE: Transformational Bessel functions KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTEGER :: n1(10) = 1,n2(2,3,4,5) = 2 ... PRINT *,BESSEL_JN(n1,n2,[1.0,2.0]) The description of BESSEL_JN, transformational version, merely states that N1 and N2 "shall be of type integer and nonnegative", and for X merely states that it "shall be of type real". There is no requirement on rank or conformability. Is this conforming, and if so, what value(s) should it print? A similar question applies to BESSEL_YN. ANSWER: This was not intended to be conforming. The N1 and N2 arguments should have been required to be scalar, as should the X argument for the transformational version of the function. Edits are supplied to correct this oversight. A similar answer pertains to the similar question for BESSEL_YN, and similar edits are supplied. EDITS to 10-007: [333:12,13] In 13.7.24p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [333:14] In 13.7.24p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". [334:12,13] In 13.7.27p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [334:14] In 13.7.27p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". SUBMITTED BY: Malcolm Cohen HISTORY: 10-169 m192 F08/0019 submitted 10-169r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0020 TITLE: FINDLOC and logical arguments KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider REAL :: array(1000),value COMPLEX :: carray(1000),cvalue LOGICAL :: ilarray(1000),ilvalue ... PRINT *,FINDLOC(array,value) PRINT *,FINDLOC(carray,cvalue) PRINT *,FINDLOC(ilarray,ilvalue) Are any of the references to FINDLOC standard-conforming? 13.7.61 requires of the VALUE argument that it "shall be ... in type conformance with ARRAY, as specified in Table 7.2 for relational intrinsic operations 7.1.5.5.2).". Yes, there is an unpaired parenthesis. More to the point: (a) Table 7.2 is in 7.1.5.1 not in 7.1.5.5.2; (b) there is no table about type conformance in 7.1.5.5.2, (c) for type logical, the comparison is allegedly done by .EQV., but that is not a relational operator. It could be argued that the reference to 7.1.5.5.2 is just misleading, and reading the rest of the sentence we should indeed use Table 7.2, with the conformance as specified for the relational operators. That would make the first reference to FINDLOC conforming. The second reference to FINDLOC is more problematic, because some relational operators permit complex arguments (e.g. .EQ.) and some do not (.LE.). This makes it ambiguous as to whether or not it is conforming. The third reference to FINDLOC is the most problematic, because no relational operators permit logical arguments. Later on, FINDLOC says it uses .EQV. for logical comparison, but .EQV. is a logical operator not a relational operator, so in any case VALUE cannot satisfy the rules in Table 7.2. ANSWER: These were all intended to be standard-conforming. Edits are supplied to correct the requirement. EDITS to 10-007: [347:31-32] In 13.7.61p3, VALUE argument, replace "for ... )" by "for the operator == or the operator .EQV.". {NB: Use the same operators as specified in 13.7.61p6. Use disjunction to avoid misinterpreting it as requiring both at once.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-170 m192 F08/0020 submitted 10-170r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0021 TITLE: STORAGE_SIZE and unlimited polymorphic KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CLASS(*),POINTER :: p NULLIFY(p) PRINT *,STORAGE_SIZE(p) Note that p does not have any deferred type parameters, so is not prohibited from being a disassociated pointer in a reference to STORAGE_SIZE. Was this intended to be standard-conforming? If so, what value would be printed? Zero? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to insert the missing prohibition. EDITS to 10-007: [390:6] In 13.7.160p3, argument A, before "has any deferred" insert "is unlimited polymorphic or", and after "type parameters" insert ",". {Comma to make the sentence easier to read, not strictly necessary.} That makes the whole sentence read: "If it is unlimited polymorphic or has any deferred type parameters, it shall not be an unallocated allocatable variable or a disassociated or undefined pointer." SUBMITTED BY: Malcolm Cohen HISTORY: 10-171 m192 F08/0021 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0022 TITLE: DO CONCURRENT and file i/o KEYWORDS: DO CONCURRENT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The standard states [178:15-16] that "An input/output statement shall not write data to a file record or position in one iteration and read from the same record or position in a different iteration." In the loop DO CONCURRENT (i=1:2) IF (i==1) READ(17,REC=100) x ! (a) IF (i==2) WRITE(17,REC=100) y ! (b) END DO The input/output statement at (a) only reads data from the file, it does not write it, and thus does not fall foul of this restriction. Similar reasoning shows that the input/output statement at (b) also obeys this restriction. Is this fragment intended to be standard-conforming? ANSWER: No, the example is not intended to be standard-conforming. An edit is supplied to make the requirement less ambiguous. EDITS to 10-007: [178:15-16] In 8.1.6.7p1, penultimate bullet point, replace the whole sentence "An input/output ... iteration." with "If data are written to a file record or position in one iteration, that record or position in that file shall not be read from or written to in a different iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-172 m192 F08/0022 submitted 10-172r1 m192 Draft answer 10-172r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0023 TITLE: DO CONCURRENT and POINTER KEYWORDS: DO CONCURRENT, POINTER DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) THEN ALLOCATE(x(i)) x = 3 ! Note: defines x, does not reference x. ELSE y(i) = SUM(x) ! (*) Note: references x. DEALLOCATE(x) END IF END DO This is clearly not conforming, as it violates the requirement in [178:8-9 8.1.6.7p1 second bullet]: "A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration." However, consider example 2, identical except for replacing the (*) statement with: y(i) = SIZE(x) ! (*) Note: SIZE does not reference x. That statement does not reference x (see definition of reference at 1.3.120) and so does not violate the requirement. An even simpler example which does not violate the requirement but which appears problematic is POINTER p NULLIFY(p) DO CONCURRENT(i=1:2) IF (i==1) ALLOCATE(p) IF (i==2) PRINT *,ASSOCIATED(p) END DO A third example which does not violate the requirement but again appears to be problematic is PROCEDURE(),POINTER :: p,q EXTERNAL a,b p => a DO CONCURRENT(i=1:2) IF (i==1) p => b IF (i==2) q => p ! (*1) END DO CALL q ! (*2) Note that (*1) does not reference p, but (*2) does reference q. The pointer q is only set by one iteration, so no problem there. Were these examples intended to be standard-conforming? ANSWER: No, the examples were not intended to be standard-conforming. An edit is supplied to correct the requirement. Comment: We don't need to require "pointer associated" for "reference", that is always required for references. What we need to require is for the pointer association status to be established. EDITS to 10-007: [178:8-9] Replace the sentence "A pointer that is referenced ... any iteration." with the following sentence: "A pointer that is used in an iteration other than as the pointer in pointer assignment, allocation, or nullification, either shall be previously pointer-assigned, allocated, or nullified in that iteration or shall not have its pointer association changed during any iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-173 m192 F08/0023 submitted 10-173r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0024 TITLE: Dummy arguments of impure elemental procedures KEYWORDS: IMPURE, ELEMENTAL, INTENT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider IMPURE ELEMENTAL SUBROUTINE swap1(a,b) REAL,INTENT(INOUT) :: a,b c = a a = b b = c END SUBROUTINE IMPURE ELEMENTAL SUBROUTINE swap2(a,b) REAL :: a,b c = a a = b b = c END SUBROUTINE ... REAL x,y(10) ... CALL swap1(x,y) ! (a) CALL swap2(x,y) ! (b) The rules for arguments of elemental subroutines means that CALL (a) is not standard-conforming. However, since there are no rules requiring declaration of INTENT (that being for PURE only), CALL (b) is apparently standard-conforming. Was this intended to be standard-conforming, and what should the effect be? ANSWER: This was not intended to be standard-conforming. Omission of the requirement for INTENT specification was inadvertent. An edit is supplied to correct this oversight. EDITS to 10-007: [314:7] Insert new constraint at the end of 12.8.1 "C1290a The of an elemental subprogram shall specify the intents of all of its dummy arguments that do not have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 10-174 m192 F08/0024 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0025 TITLE: DO CONCURRENT and ALLOCATABLE KEYWORDS: DO CONCURRENT, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) ... DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) ALLOCATE(x(i),STAT=j) ... y(i) = SUM(x) IF (IAND(i,1)==1) DEALLOCATE(x,STAT=j) END DO This is clearly not conforming, as it violates the requirement in [178:5-6 8.1.6.7 p1 first bullet]: "A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration." However, consider example 2, identical except for replacing the first statement with: REAL,ALLOCATABLE :: x(:) This satisfies the first restriction for allocatables - if allocated by more than one iteration, it shall be subsequently deallocated by that iteration. The second restriction for allocatables - that it not be referenced by a different iteration - only applies to allocatables allocated/deallocated by a single iteration, not by multiple iterations. Together with use of STAT= and a previously allocated array, this allows cross-iteration dependencies. Q1. Was this intended to be standard-conforming? Consider example 3 REAL,ALLOCATABLE :: x(:) ALLOCATE(x(10)) DO CONCURRENT(i=1:2) IF (i==1) THEN DEALLOCATE(x) ELSE IF (ALLOCATED(x)) THEN PRINT *,'Iteration 2 happened first' ELSE PRINT *,'Iteration 1 happened first' END IF END DO This does not fall foul of the restrictions because using ALLOCATED does not "reference" x. Q2. Was this intended to be standard-conforming? Consider example 4 REAL,ALLOCATABLE :: x(:) ... ALLOCATE(x(999)) DO CONCURRENT (i=1:3) IF (i>1) ALLOCATE(x(i)) X = 3 DEALLOCATE(x) END DO Again, the reference and DEALLOCATE in an iteration that does not ALLOCATE it is permitted because it is ALLOCATEd in more than one iteration. This would not have been permitted if x had been a pointer. Q3. Was this intended to be standard-conforming? The second allocatable restriction says [178:13-14]: "An allocatable object that is ... deallocated in only one iteration shall not be deallocated ... in a different iteration." This does not achieve anything, since the "deallocated ... in a different iteration" means that it is deallocated in more than one iteration in the first place. Q4. What is the meaning of this restriction? ANSWER: No, the examples were not intended to be standard-conforming. The restriction is faulty; an edit is supplied to correct it. EDITS to 10-007: [178:13-14] In 8.1.6.7p1, ante-penultimate bullet point, Replace the sentence "An object ... iteration." With "An allocatable object that is referenced, defined, deallocated, or has its allocation status, dynamic type, or a deferred type parameter value inquired about, in any iteration, either shall be previously allocated in that iteration or shall not be allocated or deallocated in any other iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-175 m192 F08/0025 submitted 10-175r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0026 TITLE: DO CONCURRENT and output interleaving KEYWORDS: DO CONCURRENT, output DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the trivial example: DO CONCURRENT (i=1:1) PRINT *,'Line 1' PRINT *,'Line 2' END DO According to the ultimate bullet point of 8.1.6.7, the output records appear in an indeterminate order, therefore it appears that the processor is permitted to produce the output Line 2 Line 1 for that program fragment. Q1. Is this intentional? Also, this ordering statement appears as a bullet point belonging to "The following additional restrictions apply to execution of a DO CONCURRENT construct." but it is not a restriction, either on the user or on the processor (rather the opposite of a restriction on the processor). Q2. Should this not be a separate paragraph to avoid confusion? ANSWER: A1. No, this was not intentional. An edit is supplied to correct this. A2. Yes, this should not have been a bullet point as it does not belong in the list of restrictions. EDITS to 10-007: [178:17-18] Delete the last bullet point of 8.1.6.7. [178:18+] Insert new paragraph "If records are written to a sequential file by more than one iteration, the ordering between records written by different iterations is indeterminate." {This leaves the statement within the subclause entitled "Restrictions on ..." which is suboptimal but not an actual contradiction.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-176 m192 F08/0026 submitted 10-176r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0027 TITLE: ATOMIC_REF example KEYWORDS: intrinsic, atomic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the example for ATOMIC_REF correct? ANSWER: No. The arguments are in the wrong order. EDIT to 10-007: [332:25] In 13.7.21 ATOMIC_REF, paragraph 4, change "CALL ATOMIC_REF (I[3], VAL)" to "CALL ATOMIC_REF (VAL, I[3])". SUBMITTED BY: John Reid HISTORY: 10-177 m192 F08/0027 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0028 TITLE: Does a procedure reference cause loop termination? KEYWORDS: branch, transfer of control, loop termination, procedure reference DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following DO construct DO CALL SUB END DO According to subclause 8.1.6.6.4 [177:28-29], loop termination occurs when "Control is transferred from a statement within the range of a DO construct to a statement that is neither the nor within the range of the same DO construct." A subroutine reference is a transfer of control. The first executable statement of SUB is not within the range of the DO construct. Does the loop terminate when SUB is invoked? ANSWER: It is not intended that execution of a DO construct be terminated by a procedure reference. Edits are provided to correct this. EDITS to 10-007: Replace the fourth item in the bulleted list in subclause 8.1.6.6.4 Loop termination [177:28-29] with the following: "o A branch occurs within the range of a DO construct and the branch target statement is neither the nor within the range of the same DO construct." SUBMITTED BY: Van Snyder HISTORY: 10-178 m192 F08/0028 submitted 10-178r1 m192 Draft answer 10-178r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0029 TITLE: G0 edit descriptor and floating-point output KEYWORDS: G edit descriptor, 0 width DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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-007: In 10.7.5.2.2, paragraph 2: [258:9] "Reasonable processor-dependent" -> "Processor-dependent". {A5.} [258:10] After "value" insert ", that do not result in the field being filled with asterisks". {A1.} [258:10] Append new sentences to paragraph: "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 ------------------------------------------------------------------------ NUMBER: F08/0030 TITLE: Unlimited format repeat effects KEYWORDS: repeat count DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program Program example Integer :: x(3) = (/ 1,2,3 /) Print 1,x 1 Format(1x,999999999('a',I0,'b')) Print 2,x 2 Format(1x,*('a',I0,'b')) Print 3,x 3 Format(1x,999999999('a',:,',',I0,'b')) Print 4,x 4 Format(1x,*('a',:,',',I0,'b')) End Program According to the first statement of 10.4p8 [249:12-13], "If format control encounters the rightmost parenthesis of a complete format specification and another effective item is not specified, format control terminates." This means that the first two lines of output should be a1ba2ba3ba a1ba2ba3b and the second two lines of output should be a,1ba,2ba,3ba a,1ba,2ba,3b But according to Note 10.7, "The effect of an unlimited-format-item is as if its enclosed list were preceded by a very large repeat count." which it manifestly is not. Is the normative text correct or the note? ANSWER: The note is correct. In the example above the output of the first two lines should be the same and equal to the first of the two lines and the second two lines should be the same and equal to the first of those two lines. An edit is supplied to correct the normative text. To make the following example non-standard: print 20 20 format ( *('a') ) the reused portion of the unlimited format item must contain at least one data edit descriptor. A constraint is provided. EDITS to 10-007: [246:15] After C1002 in 10.3.1, add a new constraint: "C1002A (R1005) An shall contain at least one data edit descriptor." [249:11+] Insert after the seventh paragraph of 10.3.3 a new paragraph: "If format control encounters the rightmost parenthesis of an unlimited format item, format control reverts to the leftmost parenthesis of that unlimited format item. This reversion of format control has no effect on the changeable modes (9.5.2)." [249:19-20] Change "If format control reverts ... , the" to "The" SUBMITTED BY: Malcolm Cohen HISTORY: 10-180 m192 F08/0030 submitted 10-180r1 m192 Draft answer 10-180r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0031 TITLE: PURE INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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. NOTE TO J3: This interpretation request has an interaction with interp F08/0034 (10-184). Care should be taken to keep these consistent. (This note should be removed in due course.) EDITS to 10-007: [312:22+] In 12.7 after C1278, insert new constraint "C1278a 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 ------------------------------------------------------------------------ NUMBER: F08/0032 TITLE: PURE FUNCTION result finalization KEYWORDS: PURE FUNCTION FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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-007: [24:10] 1.6.2 last sentence, "Any"->"Except as identified in this subclause, any". {This edit is also present in interp F08/0033.} [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be finalizable by an impure final subroutine. This is not permitted by this part of ISO/IEC 1539." [312:20+] In 12.7 after C1276, insert new constraint "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." 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 ------------------------------------------------------------------------ NUMBER: F08/0033 TITLE: PURE polymorphic finalization KEYWORDS: PURE CLASS FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE root REAL c CONTAINS FINAL pf PROCEDURE asgn GENERIC :: ASSIGNMENT(=) => asgn END TYPE TYPE,EXTENDS(root) :: t CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS PURE SUBROUTINE pf(x) TYPE(root),INTENT(INOUT) :: x x%c = 0 END SUBROUTINE SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE asgn(a,b) CLASS(root),INTENT(OUT) :: a CLASS(root),INTENT(IN) :: b a%c = b%c END SUBROUTINE SUBROUTINE process(array,scalar) CLASS(root) array(:),scalar FORALL (i=1:SIZE(array)) array(i) = scalar END SUBROUTINE END MODULE TYPE(root) w,x(100) TYPE(t) y(100),z ... CALL process(x,w) ! (1) CALL process(y,z) ! (2) The procedure reference at (1) will execute process with the dynamic types of its dummy arguments being TYPE(root); the finalization of the array elements caused by the defined assignment in the FORALL statement will execute only the pure procedure pf, so all is well. However, the procedure reference at (2) will execute process with the dynamic types of its dummy arguments being TYPE(t); the finalization of the array elements in this case will additionally call the impure final procedure f, so all is not well. However, this cannot be detected at compilation time. But constraint C1284 requires diagnosis of this error. Surely some mistake? Either the constraint cannot be a constraint (which would be bad, since a design goal of pure procedures is that violation of purity can be detected at compile time), or polymorphic arguments to pure procedures need to be restricted in some way. Q1. Should polymorphic INTENT(OUT) arguments to pure procedures be allowed? Note that finalization can also occur via DEALLOCATE of an ALLOCATABLE or POINTER dummy argument that is not INTENT(IN). Q2. Should ALLOCATABLE and POINTER dummy arguments of pure procedures be allowed to be polymorphic and not INTENT(IN)? Or should deallocation of any polymorphic subobject of a dummy argument simply be disallowed? Note that problematic (as in undecidable at compile time) finalization can also occur via DEALLOCATE of a non-polymorphic component of a non-INTENT(IN) argument if it has a subobject that is an ALLOCATABLE polymorphic component. Furthermore, such deallocation can occur via intrinsic assignment. Q3. Should this be constrained in some way? ANSWER: A1. This interaction between polymorphism, finalization, and purity is inadvertent. An INTENT(OUT) argument of a pure procedure should not be allowed to be polymorphic; an edit is supplied to correct this mistake. A2. Yes, deallocation of any polymorphic entity should be forbidden in a pure procedure. An edit is supplied to correct this. A3. Any statement that might result in a deallocation that is forbidden should not be allowed in a pure procedure. An edit is supplied, with a note. EDITS to 10-007: [24:10] 1.6.2 last sentence, "Any"->"Except as identified in this subclause, any". {This edit is also present in interp F08/0032.} [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted an INTENT(OUT) argument of a pure subroutine to be polymorphic. This is not permitted by this part of ISO/IEC 1539.". [312:22+] Insert new constraint "C1278b An INTENT(OUT) dummy argument of a pure procedure shall not be polymorphic." [313:6+] Insert new constraint "C1284a A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure. Note 12.48x Apart from the DEALLOCATE statement, this includes intrinsic assignment if the variable has a polymorphic allocatable component at any level of component selection that does not involve a pointer component but which might involve one or more allocatable components." SUBMITTED BY: Malcolm Cohen HISTORY: 10-183 m192 F08/0033 Submitted 10-183r1 m192 Revised note in the edit - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0034 TITLE: ELEMENTAL INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t1 REAL,POINTER :: vec(:) CONTAINS FINAL f1 END TYPE TYPE t2 REAL,POINTER :: vec(:) CONTAINS FINAL f2 END TYPE CONTAINS PURE SUBROUTINE f1(x) TYPE(t1),INTENT(INOUT) :: x IF (ASSOCIATED(x%vec)) DEALLOCATE(x%vec) END SUBROUTINE PURE SUBROUTINE f2(y) TYPE(t2),INTENT(INOUT) :: y(:) INTEGER i DO i=1,SIZE(y) IF (ASSOCIATED(y(i)%vec)) DEALLOCATE(y(i)%vec) END DO END SUBROUTINE ELEMENTAL SUBROUTINE zap1(z1) TYPE(t1),INTENT(OUT) :: z1 END SUBROUTINE ELEMENTAL SUBROUTINE zap2(z2) TYPE(t2),INTENT(OUT) :: z2 END SUBROUTINE END MODULE ... TYPE(t1) a,aa(10) TYPE(t2) b,bb(10) ... CALL zap1(a) ! (1) CALL zap1(aa) ! (2) CALL zap2(b) ! (3) CALL zap2(bb) ! (4) The question is which CALL statements result in finalization and thus deallocation of the various vec components. If the finalization of an INTENT(OUT) argument is considered to happen "on invocation" in the caller, then presumably the CALL statements marked (1) and (4) will result in deallocation. On the other hand, if the finalization of an INTENT(OUT) argument is considered to be done in the called procedure, then arguably it is the CALL statements marked (1) and (2) instead that will result in deallocation. In either case some clarification would seem to be useful. Q. Which statements result in deallocation of the vec components? ANSWER: A. The finalization is considered to occur in the called procedure, so the statements marked (1) and (2) will result in deallocation of the vec components. Note that this is consistent with the answer to interp F08/0031 (10-181r1). EDITS to 10-007: [76:31] At the end of 4.5.6.3 paragraph 8, append new sentence "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: Malcolm Cohen HISTORY: 10-184 m192 F08/0034 submitted 10-184r1 m192 Selected alternative answer, fixed example - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ---------------------------------------------------------------------- NUMBER: F08/0035 TITLE: Maximum value for SHIFT argument to SHIFTL and SHIFTR KEYWORDS: SHIFTL, SHIFTR, BIT_SIZE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: A significant part of the justification for the addition of the redundant SHIFTL and SHIFTR intrinsic functions was that in the case of a nonconstant SHIFT argument, the generated code needed to test the shift direction and that such tests were inefficient. However, it is not uncommon for the actual hardware shift instructions to only shift the argument modulo the bit size, for either 32-bit or 64-bit shifts, or both. Since SHIFT is allowed to be equal to the bit size, this means that tests still need to be done to check for this case. Since being able to generate the value zero by shifting an arbitrary nonzero argument completely, applying the feature justification leads one to surmise that perhaps SHIFT should have been limited to BIT_SIZE-1 instead of BIT_SIZE. Q. Should the maximum value of the SHIFT argument to the SHIFTL and SHIFTR intrinsics be BIT_SIZE or BIT_SIZE - 1? Note: A similar argument does not apply quite so straightforwardly to SHIFTA, since it provides new functionality. ANSWER: A. Although allowing SHIFTL and SHIFTR by BIT_SIZE provides little useful functionality, this is allowed for consistency with ISHFT. EDITS to 10-007: None. SUBMITTED BY: Malcolm Cohen HISTORY: 10-185 m192 F08/0035 submitted 10-185r1 m192 Draft answer with straw vote alternative == answer not alternative - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0036 TITLE: NORM2 example in Annex C KEYWORDS: intrinsic, norm2 DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the example for NORM2 in C.13.3.6 correct? ANSWER: No. "|X_i|" should be "|X_i|^2". EDIT: [527:18 p3] In C.13.3.6 Vector norms (13.7.2, 13.7.109, 13.7.123), paragraph 3, replace "|X_i|" by "|X_i|^2". SUBMITTED BY: John Reid HISTORY: 10-186 m192 F08/0036 submitted 10-186r1 m192 Draft answer 10-186r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0037 TITLE: PROCEDURE POINTER vs PROTECTED KEYWORDS: PROCEDURE, PROTECTED DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following module fragment correct syntax for an abstract interface i_f? procedure(i_f), pointer, protected :: p_f1 => null() F2008 10-007 [100:4] C549 says "An entity with the PROTECTED attribute shall be a procedure pointer or variable." But 12.4.3.6 [287:11+] does not list PROTECTED as an allowable attribute on the procedure declaration statement. ANSWER: The module fragment was intended to be standard-conforming. An edit is provided to correct this. EDITS to 10-007: [287:15+] in R1213 after "<> POINTER", insert a new line "<> PROTECTED" SUBMITTED BY: Stan Whitlock HISTORY: 10-188 m192 F08/0037 submitted 10-188r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ----------------------------------------------------------------------- NUMBER: F08/0038 TITLE: Are pointless restrictions on DIM arguments intended? KEYWORDS: DIM argument, optional, intrinsic reduction function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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). 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) This was an oversight. (2) No. Edits are provided to remove it. EDITS to 10-007: [13.2.4p1 316:26] Insert "absent" before "optional". [13.7.61p3 347:34] Delete "The corresponding ... optional dummy argument." [13.7.71p3 352:27] Delete "The corresponding ... optional dummy argument." [13.7.73p3 353:22] Delete "The corresponding ... optional dummy argument." [13.7.83p3 357:30] Delete "The corresponding ... optional dummy argument." [13.7.108p3 366:29] Delete "The corresponding ... optional dummy argument." [13.7.109p3 367:35] Delete "The corresponding ... optional dummy argument." [13.7.114p3 369:36] Delete "The corresponding ... optional dummy argument." [13.7.115p3 371:2] Delete "The corresponding ... optional dummy argument." [13.7.133p3 379:7] Delete "The corresponding ... optional dummy argument." [13.7.161p3 390:22] Delete "The corresponding ... optional dummy argument." Additional edits if interp F08/0003 passes ------------------------------------------ [13.7.10p3 328:8] Delete "The corresponding ... optional dummy argument." [13.7.13p3 329:12] Delete "The corresponding ... optional dummy argument." [13.7.123p3 374:29-30] Delete "The corresponding ... optional dummy argument." [13.7.128p3 377:26] Delete "The corresponding ... optional dummy argument." [13.7.165p3 392:12-13] Delete "The corresponding ... optional dummy argument." 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 ------------------------------------------------------------------------ NUMBER: F08/0039 TITLE: Many-one vector subscript usage KEYWORDS: Vector subscripts. DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider SUBROUTINE zap(z,i) REAL z(:) INTEGER i(:) IF (no_duplicates(i)) z(i) = 0 END SUBROUTINE ... REAL x(10) ... CALL zap(x,(/ 2,3,2 /)) (The user-defined function no_duplicates returns .TRUE. if and only if its argument has no duplicate values.) 6.5.3.3.2 "Vector subscript" paragraph 3 says: "If a vector subscript has two or more elements with the same value, an array section with that vector subscript shall not appear in a variable definition context (16.6.7)." In the execution of zap from the CALL statement, the array section z(i) has a vector subscript with two elements with the same value, and appears in a variable definition context, in violation of the stated requirement. Q. Is this program fragment standard-conforming? ANSWER: Yes, this program is standard-conforming. The quoted requirement is poorly worded; an edit is supplied to correct it. EDITS to 10-007: [124:9] Replace "shall ... (16.6.7)" with "is not definable and shall not be defined or become undefined". SUBMITTED BY: Malcolm Cohen HISTORY: 10-195 m192 F08/0039 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 ------------------------------------------------------------------------ NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: No. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray; therefore MOVE_ALLOC would need to be an image control statement for consistency with the DEALLOCATE statement. An edit is supplied to clarify this. EDIT: In 10-007 In 13.7.118p3 MOVE_ALLOC (FROM, TO): [372:18] After "It shall be allocatable." in FROM, add "It shall not be a coarray." [372:19] After "It shall be allocatable." in TO, add "It shall not be a coarray." 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 ---------------------------------------------------------------------- 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 letter ballot 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, 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 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-007} [xiii] 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. 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 ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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, 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, and needed to avoid a potential type enquiry of an object on another image. Consider TYPE,EXTENDS(foo) :: badfoo CLASS(*),ALLOCATABLE :: badcomponent(:) END TYPE If the dynamic type of object "o_foo" were "badfoo", the call to the type-bound procedure cannot be resolved without enquiring the type of o_foo%badcomponent on image 2 (because it needs to know how much to copy, and how); this type is not necessarily the same type as that of o_foo%badcomponent on image 1. A2. Yes, constraint C1229 is redundant. An edit is supplied to remove this unnecessary redundancy. EDITS to 10-007: [290: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 ---------------------------------------------------------------------- NUMBER: F08/0044 TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Consider the following code: module m type :: foo integer :: i = 0 end type end module m program p use m class(foo), allocatable :: o_foo[:] integer :: j allocate(foo :: o_foo[*]) if (this_image() == 1) then select type(a => o_foo[2]) ! 1 type is(foo) j = a%i end select select type(a => o_foo) ! 2 type is(foo) j = a[2]%i end select select type(o_foo) ! 3 type is(foo) j = o_foo[2]%i end select end if end program p (1) Is the first SELECT TYPE block standard-conforming? (2) Is the second SELECT TYPE block standard-conforming? (3) Is the third SELECT TYPE block standard-conforming? ANSWERS: References are to 10-007 (1) No. is in the definition of in R847 [184:10]. is defined in R805 [170:17]. C803 [170:22] disallows a coindexed object if is a . C803 constrains in both and . (2) Yes. This is implied by 8.1.3.3 para 1 [171:2]. (3) Yes. EDITS: None SUBMITTED BY: R. Bader HISTORY: 10-209 m193 F08/0044 submitted 10-209r1 m193 Proposed answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- 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/0046 TITLE: VALUE attribute restrictions KEYWORDS: VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program unit SUBROUTINE s(x,y,n) REAL,VALUE :: x(:) CHARACTER(n),VALUE :: y DO i=2,SIZE(x) x(i) = x(i) + x(i-1) END DO PRINT *,y,x END SUBROUTINE This is not valid in Fortran 2003 as it violates constraint C527 "If the VALUE attribute is specified, the ... DIMENSION ... attribute shall not be specified." and also violates constraint C528 "If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions." The corresponding constraint to F2003/C527 for Fortran 2008, C558, does not prohibit the DIMENSION attribute. There does not appear to be any constraint in F2008 corresponding to F2003/C528. Therefore this program unit is apparently now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention these as new features. Is the omission of these requirements an oversight? ANSWER: No, these are deliberate additions to the language. An edit is supplied to clarify the Introduction. EDITS: {to 10-007} [xiii] Introduction, bullet "Data declaration", append "The VALUE attribute is permitted for an array, and for an object with a nonconstant length type parameter." SUBMITTED BY: Malcolm Cohen HISTORY: 10-212 m193 F08/0046 submitted - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0047 TITLE: public generic with same name as private type KEYWORDS: generic, accessibility DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot Consider the following code: module m implicit none private public :: foo ! A type, private :: foo ! B integer :: i = 0 end type type(foo), public :: o_foo interface foo module procedure foo_proc end interface contains function foo_proc(i) result(this) integer, intent(in) :: i type(foo) :: this this%i = i write(*, *) 'Hello' end function end module m program p use m implicit none o_foo = foo(2) end program QUESTION: Is this program standard conforming? ANSWER: No. DISCUSSION: The PUBLIC statement at A contradicts the PRIVATE attribute at B which violates the standard. SUBMITTED BY: R. Bader HISTORY: 10-213 m193 F08/0047 submitted 10-213r1 m193 Proposed answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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)) 12.5.2.4 paragraph 13 seems to imply that this ought to be valid. ANSWER: Yes, passing an array element to a dummy coarray was not intended to use sequence association. There is no contradiction with 12.5.2.4 paragraph 13 (which as is simply doesn't apply), but it is confusing so an edit is supplied to clarify it. EDIT: [294:33] Append new sentence to 12.5.2.4 paragraph 13, "If the dummy argument is a coarray that is an array, the actual argument shall be an 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 ** start of negative comments Bill Long's No vote on F08/0048: The proposed restriction on coarrays as actual arguments sequence associated with a contiguous dummy makes yet another exception to ordinary array behavior for coarrays. In this case, there seems to be no justification other than the view that sequence association of arguments is archaic. I think that the confusion introduced by making another case where coarrays are different from ordinary arrays is less desirable that allowing coarrays to behave like "old" arrays. John Reid's NO vote on F08/0048: Sequence association is allowed for array coarrays, so I can see no reason for disallowing it for a scalar coarray that is an element of a simply contiguous array. 12.5.2.4 para 13 says: "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array." As the standard stands, I believe that this applies. It is made not to apply by the new edit: "If the dummy argument is a coarray that is an array, the actual argument shall be an array." I think this is a technical change that contradicts one of our design principles: wherever possible, coarrays should behave just like variables that are not coarrays. I suggest that we go back to 10-226 which contains the edit In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:9], add "or an element of a simply contiguous array". Jim Xia's No vote on F08/0048: I believe this restriction might be a bit surprising to users who regularly use sequence associations. Also there isn't an apparent technical difficulties in support this. ** end of negative comments ---------------------------------------------------------------------- NUMBER: F08/0049 TITLE: ELEMENTAL functions with nonconstant type parameters KEYWORDS: ELEMENTAL, type parameter DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Interpretation F03/0119, which became part of the Fortran 2008 standard, added as constraint the requirement of an elemental function that its result variable "shall not have a type parameter that is defined by an expression that is not a constant expression". This makes a number of valid Fortran 95 programs invalid, for no apparent technical reason. Moreover, no text was added to clause 1 to indicate this incompatibility with Fortran 95. Here are several examples of non-problematic Fortran 95 elemental procedures that are apparently not valid Fortran 2008. MODULE ex1 INTEGER :: mylen CONTAINS ELEMENTAL CHARACTER(mylen) FUNCTION f(a) INTEGER,INTENT(IN) :: a f = REPEAT(CHAR(a),mylen) END FUNCTION END MODULE ELEMENTAL FUNCTION ex2(a,b) CHARACTER(*),INTENT(IN) :: a,b CHARACTER(LEN(a)+LEN(b)) :: ex2 ex2 = a//b END FUNCTION MODULE ex3 INTEGER,ALLOCATABLE :: x(:) CONTAINS PURE FUNCTION gcd(a) INTEGER :: gcd INTEGER,INTENT(IN) :: a(:) gcd = ... code to calculate this omitted ... END FUNCTION ELEMENTAL FUNCTION f(y,z) CHARACTER(*),INTENT(IN) :: y,z CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f f = ... END FUNCTION END MODULE Was this incompatibility with Fortran 95 an oversight? ANSWER: Yes, this was an oversight; requiring the type parameter values to be constant is unnecessarily onerous. An edit is supplied to correct this defect in the standard. EDITS: {to 10-007} [314:6-7] 12.8.1, C1290, delete ", and shall not ... expression". {Delete erroneous constraint.} [314:7+] Insert new constraint "C1290a In the that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry, and that specification enquiry shall not depend on a property that is deferred." SUBMITTED BY: Malcolm Cohen HISTORY: 10-231 m193 F08/0049 submitted - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 ----------------------------------------------------------------------