J3/09-006Ar2 Outstanding Fortran Interpretations, June 13, 2009 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) > m187 interps: submitted 128, 129; passed 63..65, 119, 128, 129 + removed Corr 4 interps: see 022 + letter ballot #18 09-187r2: passed 63, 71, 112, 119, 122 125..127, 129; failed: 64, 65, 128 + m188 interps: submitted 130..133; passed 22, 24, 34, 39, 130..133 [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 F95 interpretations: - the remaining F95 interp numbers start with F95/ - the F95 interps that are numbered 1-32 and 66-104 - the F90 interps that are numbered F90/... and being interpreted against F95 - there are no more Japanese F95 interps with their JP-... numbers Part 3 contains active F2003 interpretations (prefixed with "F03/") ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done {if S = C1 | C2 | T1 | T2 | T3 | T4, then done is assumed} * == active W == would go in F95 Corrigendum 3 if there were one 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 C1 Included in F95 corrigendum 1 (see N1422) C2 Included in F95 corrigendum 2 (see N1473) T1 Included in F03 corrigendum 1 (see N1636/N1640) T2 Included in F03 corrigendum 2 (see N1657/N1664) T3 Included in F03 corrigendum 3 (see N1730/N1727) T4 Included in F03 corrigendum 4 (see N1771/N1764) X Excluded for the reasons given N S T number title - - - ------ ----- T4 F95/0031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) T4 I F95/0074 TARGET dummy arguments and POINTER expressions * P F95/0098 Are dummy functions returning assumed-length character legal? T4 I F95/0102 mask-expr evaluated only once * P E F90/0145 Expressions in of a FUNCTION statement T1 I F03/0001 Generic type-bound procedures T1 I F03/0002 Component value for pointer components T4 E F03/0003 Referencing deferred bindings T4 E F03/0004 Type-bound procedures and undefined association status T1 E F03/0005 Argument association and the TARGET attribute T1 E F03/0006 Intrinsic assignment and allocatable components T1 E F03/0007 Finalization of structure constructors in specifications T2 E F03/0008 Pointer assignment and arrays T1 E F03/0009 VALUE attribute for passed-object dummy arguments T1 E F03/0010 Unlimited polymorphic pointer/allocatable dummy arguments T1 E F03/0011 Allocating objects of abstract types T2 E F03/0012 Procedure pointers and the EXTERNAL attribute T1 E F03/0013 VALUE attribute for polymorphic dummy arguments T1 E F03/0014 Automatic arrays in interface bodies T1 E F03/0015 TARGET attribute for associate names T1 E F03/0016 Invoking type-bound procedures via array objects * 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 T2 E F03/0020 Kinds of intrinsic type parameters * P E F03/0021 What kind of token is a stop code? * M E F03/0022 Coexistence of IEEE and non-IEEE kinds T2 E F03/0023 IEEE_SET/GET_UNDERFLOW_MODE * M E F03/0024 DEALLOCATE and array pointers T2 E F03/0025 Abstract types in CLASS IS type guard statements T2 E F03/0026 Intrinsic types in CLASS IS type guard statements T2 E F03/0027 Assumed character length in type guard statements T2 E F03/0028 Commas in complex namelist output T2 E F03/0029 Negative zero and intrinsic functions * P E F03/0030 IEEE divide by zero T1 I F03/0031 IEEE invalid T1 I F03/0032 Sign bit of IEEE NaN T1 I F03/0033 IEEE_VALUE() * M E F03/0034 IEEE_LOGB() T1 I F03/0035 IEEE_NEXT_AFTER() T1 I F03/0036 IEEE_REM() T1 I F03/0037 IEEE_RINT() T1 I F03/0038 IEEE_SCALB() * M E F03/0039 HYPOT() T1 I F03/0040 2.0+2.0 and IEEE T1 I F03/0041 IEEE halting and exceptions * P E F03/0042 IEEE funny values and Standard real generic intrinsic procedures T1 E F03/0043 Passed-object arguments and procedure pointer components T1 E F03/0044 Implicit interfaces and conflicting references T2 E F03/0045 Finalization and assumed-sized arguments with INTENT(OUT) * P E F03/0046 Unlimited polymorphic pointers in common blocks * P E F03/0047 Polymorphic arguments to intrinsic procedures * P E F03/0048 Control edit descriptors in UDDTIO T4 E F03/0049 Separators in list-directed output involving UDDTIO T3 E F03/0050 Questions about internal files * P E F03/0051 Repeat specifiers and UDDTIO T1 I F03/0052 ADVANCE= specifier in child data transfer statements * P E F03/0053 The BIND attribute for C_PTR and C_FUNPTR T1 E F03/0054 Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT T1 E F03/0055 Denormal inputs to SPACING and RRSPACING T2 I F03/0056 Null input values and list-directed UDDTIO T2 E F03/0057 Namelist I/O and UDDTIO T2 I F03/0058 Recursive namelist output * P E F03/0059 Structure components in namelist input T2 E F03/0060 Default initialization of INTENT(OUT), assumed-size arrays {subsumed by F03/0045} T2 E F03/0061 Polymorphism and explicit-shape or assumed-size dummy arguments T2 E F03/0062 Finalization of array constructors * B E F03/0063 Procedure pointers in BLOCK DATA program units * P E F03/0064 Recursive declaration of procedure interfaces * P I F03/0065 Relational equivalence T2 I F03/0066 Precision of operation T2 I F03/0067 Accuracy of conversion of real literal constants T2 E F03/0068 First character of namelist output records T2 E F03/0069 Procedure pointers in defined assignment T2 E F03/0070 Can child I/O statements be advancing I/O statements? * B E F03/0071 Subroutine/function ambiguity in generics T2 E F03/0072 Default initialization for "automatic" components T4 I F03/0073 C interop of dummy procedures T4 E F03/0074 Type mismatch for C character arguments T4 E F03/0075 C interop of derived types with array components T4 I F03/0076 Scope of Fortran names of procedures with binding labels T4 E F03/0077 LBOUND of array structure component * P C F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence T3 E F03/0079 Value of decimal exponent for a real zero value T3 I F03/0080 Formatted output of a negative real zero value T4 I F03/0081 F edit descriptor with field width 0 T4 I F03/0082 VALUE in place of INTENT for pure procedure dummy arguments X C F03/0083 Interpretation request concerning DATA {withdrawn by submitter} * P I F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine * P I F03/0085 Finalizing targets of pointer or allocatable actual arguments T3 E F03/0086 Elemental and BIND(C) T4 I F03/0087 Entry names as dummy procedure arguments T3 E F03/0088 Defined operations/assignments and VOLATILE/ASYNCHRONOUS T3 E F03/0089 Interoperability of non-BIND derived types * P E F03/0090 Polymorphic array constructors * P E F03/0091 Array components cannot depend on length type parameters T3 E F03/0092 Procedure characteristics and unlimited polymorphic T3 E F03/0093 Allocatable array on intrinsic assignment with scalar expr T3 E F03/0094 Final subroutine and VALUE attribute T3 I F03/0095 Bounds remapped pointer assignment and ASSOCIATED * P E F03/0096 Can a read statement change the unit value? T3 E F03/0097 Blanks as separators in NAMELIST input T4 E F03/0098 Does allocate with source= define subcomponents? T4 E F03/0099 Clause 16 does not account for volatile variable * P E F03/0100 Error in field width for special cases of signed INFINITY output T3 E F03/0101 Is UDDTIO output suitable for namelist and list-directed input T4 C F03/0102 Evaluation of bound-expr in data pointer assignment * P E F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type T3 I F03/0104 Deallocation and finalization of bounds-remapped pointers * P E F03/0105 SIZE= specifier and UDDTIO T3 E F03/0106 Inquire by unit inconsistencies T3 E F03/0107 Are the IEEE_* elemental routines required T3 C F03/0108 Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions T4 E F03/0109 Referencing deferred binding via absent dummy argument * P E F03/0110 Restoring dropped restriction on ENTRY T4 C F03/0111 Is defined assignment to a vector subscripted array allowed? * B E F03/0112 Attributes allowed for dummy arguments in defined assignments T4 E F03/0113 Size and uniqueness considerations for ID= T4 E F03/0114 Inconsistent restrictions on i/o specifiers X E F03/0115 Are circular dependencies between specification expressions permitted? {Withdrawn by submitter} * P E F03/0116 indistinguishable specifics for a generic interface with use association T4 E F03/0117 STOP executed via function in input/output list * P E F03/0118 Are lower bounds of assumed-shape arrays assumed? * B E F03/0119 Elemental procedures and deferred length character components * P E F03/0120 When are parameterized sequence types the same type? * P C F03/0121 Precise FP semantics of the REAL intrinsic * B E F03/0122 When do objects of sequence derived type have the same type? * P I F03/0123 Implicit typing in derived types * P I F03/0124 definition is poorly defined * B E F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS * B E F03/0126 References to VOLATILE variables in pure procedures * B E F03/0127 Duration of procedure execution * P E F03/0128 Subobjects in namelist output * B E F03/0129 C_LOC of character substrings * M I F03/0130 Elemental specific intrinsic procedure characteristics * M E F03/0131 SAVE attribute and EQUIVALENCE * M E F03/0132 Unformatted i/o and private components * M E F03/0133 Is unlimited polymorphic allowed in COMMON? ====================================================================== 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 F95 interpretations ====================================================================== ---------------------------------------------------------------------- NUMBER: F95/0098 TITLE: Are dummy functions returning assumed-length character legal? KEYWORDS: DUMMY FUNCTION, ASSUMED-LENGTH CHARACTER DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Are dummy functions returning assumed-length character legal? Consider the following program: character*5 f external f call ss3(f) end subroutine ss3(ff) character*(*) ff, a*10 external ff a = ff()//'99999999' print *, '<', a, '>' end function f() character*(*) f f = '123' end The issue is the call to the dummy function 'ff' in subroutine 'ss3'. Some compilers issue an error message. Others print the result: <123 99999> There appear to be two relevant, contradictory passages in the F95 standard. Refer to section 5.1.1.5. <> means italics, [] means obsolescent font. The third constraint says "A function name shall not be declared with an asterisk [unless it is the name of the result of an external function or the name of a dummy function.] Before note 5.6 on the next page, the third bullet says: (3) [In an external function, the name of the function result may be specified with a character length parameter value of *; in this case, any scoping unit invoking the function shall declare the function name with a character length parameter value other than * or access such a definition by host or use association. When the function is invoked, the length of the result variable in the function is assumed from the value of this type parameter.] According to the standard, the use in the example program is legal, because 'ff' is the name of a dummy function. But it seems clear that the standard intended that the length of the variable returned by a character function be known at compile time; it is not known in the case where the function is a dummy function. ANSWER: EDITS: SUBMITTED BY: Larry Meadows HISTORY: 02-157 m160 F95/0098 submitted 04-417r1 m170 Duplicate of interp #6 05-180 m172 Failed WG5 ballot N1617 - not a duplicate of F95 interp 000006 Malcolm Cohen NO vote on F95/000098 I agree with John that there is an issue here which is not adequately covered by Interp F95/000006. However, I think that the suggestion that item (3) of 5.1.1.5 means that the program is invalid is without merit. A literal interpretation of item (3) means that even if subroutine SS3 declared dummy FF as being CHARACTER*5, the program would still be invalid since the name of the function is F, not FF. This would be a completely ridiculous result. Thus item (3) of 5.1.1.5 is faulty and an edit is required for it to handle (assumed-length) dummy functions at all. John Reid NO vote on 000098 This is different from interpretation 6 since the function has assumed character length, which means that item (3) of page 51 applies. Hence, I think the ANSWER should be The program does not conform with the standard because of the rule in item (3) of the list in 5.1.1.5. The function f is invoked from the scoping unit of ss3 within which the function name does not satisfy any of the required conditions. ---------------------------------------------------------------------- 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 2: 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/0022 TITLE: Coexistence of IEEE and non-IEEE kinds KEYWORDS: IEEE, kind DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it allowed for a processor to have one or more real kinds for which there is no IEEE support, while also having real kinds for which there is IEEE support? Much of the IEEE material appears to assume that a processor could simultaneously support both IEEE and non-IEEE kinds. I thought this was the intent. However, the first sentence of the second paragraph in section 14 says that if IEEE_EXCEPTIONS or IEEE_ARITHMETIC is accessible in a scoping unit, then IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are supported in the scoping unit for *ALL* [emphasis mine] kinds of real and complex data. This says to me that if there is any kind of real for which the processor cannot support IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO, then pretty much none of the IEEE stuff can be used on that processor at all; there isn't much of the IEEE stuff that can be used without IEEE_ARITHMETIC or IEEE_EXCEPTIONS. This seems draconian and unintended. I speculate that this condition is intended to apply to all IEEE real kinds rather than to all real kinds. ANSWER: Yes, this is allowed. The requirement that IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO be supported for all kinds of real and complex data within that scoping unit was unintentional. Support of these two flags means that the exceptions can be detected for real and complex kinds that are IEEE floating point data. The Standard makes no claims about non-IEEE kinds. An edit is provided to clarify this. EDITS: All edits pertain to 04-007. Clause 14 "Exceptions and IEEE arithmetic", 1st sentence of 2nd paragraph [363:9-10] replace "for all kinds of real and complex data" with "for all kinds of real and complex IEEE floating-point data" SUBMITTED BY: Richard Maine HISTORY: 04-419 m170 F03/0022 submitted 04-419r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 09-223 m188 Revised answer 09-223r1 m188 Passed by J3 meeting + F2008 fix 09-226 ---------------------------------------------------------------------- NUMBER: F03/0024 TITLE: Pointer deallocation and "whole object" KEYWORDS: DEALLOCATE, POINTER DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 6.3.3.2 paragraph 2 (F03 [116:24-25]) states "If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation." What does this requirement entail? In particular, which of the following examples conform to this requirement? Q1. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(10)) Y => X(1:10) ! Note that ASSOCIATED(X,Y) is true. DEALLOCATE(Y) Q2. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(10)) Y => X(10:1:-1) ! Note that ASSOCIATED(X,Y) is false because the order differs. DEALLOCATE(Y) Q3. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(0)) Y => X ! Note that ASSOCIATED(X,Y) is false because they are zero-sized. DEALLOCATE(Y) Q4. REAL,POINTER :: X(:),Y(:,:) ALLOCATE(X(100)) Y(1:10,1:10) => X(1:100) ! Note that ASSOCIATED(X,Y) is false because the shapes differ. DEALLOCATE(Y) Q5. REAL,POINTER :: X(:),Y ALLOCATE(X(1)) Y => X(1) ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) Q6. TYPE T REAL NOTHING(0) REAL A(0) CHARACTER C END TYPE TYPE(T),POINTER :: X CHARACTER,POINTER :: Y ALLOCATE(X) Y => X%C ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) Q7. TYPE T CHARACTER C END TYPE TYPE,EXTENDS(T) :: XT ! No additional components END TYPE TYPE(XT),POINTER :: X TYPE(T),POINTER :: Y ALLOCATE(X) Y => X%T ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) ANSWER: In this context, "whole object" requires the type and type parameter values to be the same, and if the object is an array that the elements are the same elements in the same array element order. A scalar is never the "whole" of an array (a processor is permitted to have extra padding between array elements). This gives the answers to the specific questions as follows: Q1 - conforming; Q2 - not conforming (order differs); Q3 - conforming; Q4 - conforming; Q5 - not conforming (scalar vs. array); Q6 - not conforming (type differs); Q7 - not conforming (type differs). An edit is supplied to clarify this intent. EDITS: [116:25] After "by allocation." insert new sentence "The pointer shall have the same dynamic type and type parameters as the allocated object, and if the allocated object is an array the pointer shall be an array whose elements are the same as those of the allocated object in array element order." SUBMITTED BY: Aleksandar Donev HISTORY: 04-378 m170 F03/0024 submitted 04-378r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 09-205 m188 Revised answer - passed by J3 meeting + F2008 fix 09-226 ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEEE-754). The definitions in 14.2 were intended to describe IEEE exceptions with sufficient latitude to allow use on near-IEEE and non-IEEE machines. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with the IEEE International Standard. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with the IEEE standard, because this exception is not raised for operations on infinite operands. Edits are provided to fix these inconsistencies. EDITS: Page and line numbers refer to 04-007. [365:13-15] Clause 14.2, lines 3 and 5. After "assignment" add "with finite operands", twice. [365:18] Clause 14.2, line 8. Change "nonzero numerator" to "finite nonzero numerator". 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 Malcolm Cohen NO vote of F03/0030. The edit for [365:13-15] makes the text read "the result for an intrinsic real operation or assignment with finite operands ..." this has two flaws (1) it is now ambiguous (2) assignment doesn't have "operands" there is a pre-existing flaw, in that (3) assignment doesn't have a "result" This needs significant editorial fixup. ---------------------------------------------------------------------- NUMBER: F03/0034 TITLE: IEEE_LOGB() KEYWORDS: IEEE-754, ieee_logb() DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: What is ieee_logb(denormal)? Is it of the hardware representation, or is it as if the hardware had an unbounded exponent range? What is ieee_logb(NaN)? ieee_logb(-INF)? ieee_logb(+INF)? ieee_logb() should be defined as if the hardware representation had an unbounded exponent range. ieee_logb(NaN) should be the same NaN; shall be a NaN. ieee_logb(-INF) shall be +INF ieee_logb(+INF) shall be +INF ANSWER: Case (i) of 14.10.12 correctly specifies that if the value of X is denormal, its unbiased exponent is returned, that IEEE_LOGB(X) is equal to EXPONENT(X)-1. That this conclusion is true is the subject of F2003 interp F03/0054, answered in Corrigendum 1. For consistency with the IEEE International Standard, edits are also supplied for the case where X is infinite and X is NaN. EDITS: Page and line numbers refer to 04-007. Subclause 14.10.12 "IEEE_LOGB (X)" Result value [376:17+] add: "Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the result is +infinity. Case (iv) If IEEE_SUPPORT_NAN(X) is true and X is a NaN, the result is a NaN." SUBMITTED BY: Fred Tydeman HISTORY: 05-113 m171 F03/0034 submitted 05-113r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 09-221 m188 Revised answer 09-221r1 m188 Passed by J3 meeting + F2008 fix 09-226 ---------------------------------------------------------------------- NUMBER: F03/0039 TITLE: HYPOT() KEYWORDS: IEEE-754, hypot() DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: HYPOT is the Fortran function defined in Note 14.17. What is HYPOT(NaN,infinity)? HYPOT(NaN,finite)? HYPOT(X,Y) when X and/or Y is an infinity (even if the other is a NaN) shall be +infinity. Reason: hypot(), when one of the arguments is an infinity, is +infinity independent of the value of the other argument. So, if the NaN argument is replaced by zero, any finite number, or any infinity, hypot(infinity,NaN) is still infinity. HYPOT(X,Y) when X and/or Y is a NaN (and neither is infinite) shall be a NaN, and should one of the NaN arguments. ANSWER: The HYPOT example in note 14.17 illustrates the use of the features of this section to provide reliable software that is fast in the uncomplicated case. We did not consider what would happen if one of the arguments is a NaN and have therefore edited the text. DISCUSSION: In fact, if either X or Y is a NaN, the first executable statement will set HYPOT to a NaN without signaling an exception. The slower code in the IF construct will therefore not be executed and a NaN will be returned, which is consistent with the way NaNs are handled by intrinsic operators, see paragraph 3 of section 6.2 of the IEEE International Standard. To make this explicit, an edit is provided to test for these conditions. EDITS: Page and line numbers refer to 04-007. [page 389]. Subclause 14.11, Note 14.17, after the comment "! The processor clears the flags on entry" insert " IF (IEEE_IS_NAN (X) .OR. IEEE_IS_NAN (Y)) THEN HYPOT = SQRT (-1.0) RETURN ENDIF" [page 389]. Subclause 14.11, Note 14.17, final paragraph, line 2. Before "exception" add "overflow or underflow". SUBMITTED BY: Fred Tydeman HISTORY: 05-118 m171 F03/0039 submitted 05-118r3 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 09-222 m188 Revised answer 09-222r1 m188 Revised again to test for NAN arguments 09-222r2 m188 Passed by J3 meeting + F2008 fix 09-226 ---------------------------------------------------------------------- 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: J3 consideration in progress 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.5.3.7.2 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.5.3.7.2 was to prohibit a child data transfer statement from possibily overwriting or re-reading any characters in the current record that an active parent I/O statement had previously written or read. 9.5.3.7.2 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 0 or more spaces. Edits are supplied to clarify the intent of 9.5.3.7.2, add "file position" to the glossary, and remove the phrases "record position" and "record positioning" from the standard. EDITS: [202:34] In section 9.5.3.7.2, in the paragraph that begins with "Because a child data transfer statement does not position the file prior to data transfer," replace "list item or record positioning edit descriptor" with "list item or edit descriptor" [202:36] In section 9.5.3.7.2, replace the phrase "A record positioning edit descriptor, such as TL and TR," with "The edit descriptors T and TL," [463:4] In section C.6.2, first paragraph, delete "record positioning" [430:4+] In Annex A, add this definition: "<> (9.2.3): A connected unit has a file position. A unit's file position typically affects where the next data transfer operation will begin transferring data into or out of the file. The file position is usually just before a record, just after a record, within a record, just before the first file storage unit in the file, just after the last file storage unit in the file, or between two adjacent file storage units." SUBMITTED BY: Rob James HISTORY: 05-139 m171 F03/0048 submitted 05-139r1 m171 Passed by J3 meeting 05-167/170 m172 Failed J3 letter ballot #11 06-366r2 m178 Passed by J3 meeting 07-250r1/272 m181 Failed J3 letter ballot #13 Bill Long's YES comment on F03/0048: In looking at the test resulting from the edits, it seems like it would be better to delete paragraph [202:36-203:2] and instead add this paragraph at [236:2+]: "The left tab limit for a child data transfer statement is the file position of the parent data transfer statement at the time that the user-defined derived-type input/output procedure was invoked." on the grounds that the stuff related to Tx edit descriptors really belongs in 10.7.1.1. Given that the concept of left tab limit already includes most of what is in the paragraph at [202:32-34], one might consider deleting that paragraph as redundant. ---------------------------------------------------------------------- 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-/167170 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 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/0063 TITLE: Procedure pointers in BLOCK DATA program units KEYWORDS: Procedure pointer, common block, block data DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: It is clear that procedure pointers are permitted in common blocks. However, due to the restrictions on BLOCK DATA program units, it seems that such a common block can not appear in a BLOCK DATA program unit. Was it intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit? ANSWER: It was a mistake to try to allow procedure pointers in common blocks. Edits are provided to correct this blunder. EDITS: All edits refer to 04-007. [98:17] Delete the second line of R558 {114:19 R569 in 09-007r1}. [98:18] Remove "or " {114:21 in 09-007r1}. [98:21] After "allocatable" insert "a procedure pointer," {114:24 in 09-007r1}. [98:25] Remove "or " {115:2 in 09-007r1}. [411:21] Remove item (7) in the list of names in a scoping unit that override the same host-associated name. {448:22 in 09-007r1}. SUBMITTED BY: Rob James HISTORY: 05-178 m172 F03/0063 submitted 05-225 m173 Passed by J3 meeting 06-133r2 m175 Passed J3 letter ballot #12 N1658 m176 Failed WG5 ballot N1657 09-148 m187 Revised answer, passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot #18 09-155 as modified F2008 note: include edits above + [04-007/98:21-22 5.5.2 C588] Delete "a function name, an entry name," because these were originally synonyms for "a result name" (as applied to in R558). Now, "a function name" (as applied to in R558) prohibits function pointers. ---------------------------------------------------------------------- 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/0071 TITLE: Subroutine/function ambiguity in generics KEYWORDS: subroutine, generic, implicit DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Is the following generic allowed? interface q subroutine qr(f) implicit real(f) external f end subroutine subroutine qc(f) implicit complex(f) external f end subroutine end interface q The uncertainty arises because it is not established whether F is a subroutine or a function. If either F were a subroutine, then it would be clear that the generic was disallowed. One might be able to use this to deduce that both Fs must be functions. This seems like an obscure deduction to demand of the compiler. Q2. Consider the following "obviously" allowed generic module m interface q subroutine qr(f) real, external :: f end subroutine subroutine qc(f) complex, external :: f end subroutine end interface q end module m Is the following main program valid? program main use m external ff call q(ff) end Again, the problem is that it is unclear whether or not ff is a function or subroutine. If it is a subroutine, then the call is ambiguous. One might thus deduce that ff must be a function, and therefore of type real, but this seems like an obscure deduction to demand of the compiler. ANSWER: 1. The program fragment is not conforming. A generic interface is required to be nonambiguous. This is a similar situation to the declaration of an external procedure in a module, where a procedure that is a function is required to have its type and type parameters explicitly declared. An edit is provided to require this for specific procedures in a generic interface. 2. The main program program unit is conforming, although the program would not be if the external procedure FF were not in fact a real function. If the reference had been to QR instead of Q, it would be clear that FF has to be a real function, from the point of view of the main program scoping unit. At the call site, the reference to Q is known to be a reference either to QR or QC (the interface block for Q is not defective), both of which require a function actual argument. FF is known to be either a subroutine or a function, since it explicitly has the EXTERNAL attribute, and if it is a function it is known by implicit typing rules to be real. Because neither specific in the generic allows a subroutine as an argument, FF must therefore be a function. Since FF is real, QR is called. (The generic cannot have a specific that accepts a subroutine as an argument, as that would violate the requirements in 16.2.3.) EDITS: [261:3] In 12.3.2.1 Interface block, immediately after "A generic interface is always explicit.", append new sentence to paragraph "If a specific procedure in a generic interface has a function dummy argument, that argument shall have its type and type parameters explicitly declared in the specific interface." {I.e. if you just say EXTERNAL dummy, you must mean a subroutine.} SUBMITTED BY: Richard Maine HISTORY: 05-265 m174 F03/0071 submitted 08-189r1 m184 Answer provided - Passed by J3 meeting 08-259 m185 Failed J3 letter ballot #17 08-213 08-262 m185 Passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot #18 09-155 F2008 note: edit is 09-007r1 [285:5+] 12.4.3.4.1 "Generic identifiers" after "A generic interface is always explicit." - edit not passed as of m188 ---------------------------------------------------------------------- NUMBER: F03/0078 TITLE: IEEE_SUPPORT_DATATYPE vs. mathematical equivalence KEYWORDS: IEEE_SUPPORT_DATATYPE, mathematical equivalence DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Does the function IEEE_SUPPORT_DATATYPE (Section 14.8) override the mathematical equivalence rule (Section 7.1.8.3)? For example, could the program PROGRAM MAIN USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES X = 2.0 + 2.0 PRINT *, X END be executed as PROGRAM MAIN USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES X = 220.0*(1.0/55.0) PRINT *, X END if IEEE_SUPPORT_DATATYPE(X) is .TRUE.? Background: The committee recently ruled that 2.0 + 2.0 must produce the value 4.0 if IEEE_ARITHMETIC is in effect. I agree that if the particular operation the processor implements is addition of 2.0 and 2.0, the result must be 4.0. However, if IEEE_ARITHMETIC does not override the mathematical equivalence rule, the requirement is essentially meaningless, since there is no assurance that the expression in the program is the expression that will be evaluated. EDITS: SUBMITTED BY: Michael Ingrassia HISTORY: 06-124 m175 F03/0078 submitted ---------------------------------------------------------------------- NUMBER: F03/0083 TITLE: Interpretation request concerning DATA KEYWORDS: DATA, substring DEFECT TYPE: Interpretation STATUS: Withdrawn by submitter QUESTION: Does the following program unit conform to the 2003 Fortran standard? subroutine S ( N ) character(3) :: c(2) data ( c(i)(n:n), i = 1, 2 ) / 'A', 'B' / end subroutine s ANSWER: No. A is required to be an or a (see R528 [87:31-32]). An is only a with some extra constraints (see R616 [107:10]). A ends with a and does not include a (see R612 and R613, [105:1-2]). Therefore c(i)(n:n) is not an array element. Similarly, a is a , and therefore c(i)(n:n) is not a structure component either. Therefore there is a syntax error in the third line of the program unit. EDITS: None SUBMITTED BY: Van Snyder HISTORY: 06-173 m176 F03/0083 submitted 06-173r1 m176 revised question 06-173r2 m176 Draft answer - withdrawn by submitter; no further action on F03/0083 will be taken ---------------------------------------------------------------------- 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: Interpretation STATUS: J3 consideration in progress 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 sixth paragraph of 4.5.5.2 [04-007:59:31-32] says "When a procedure is invoked, a nonpointer nonallocatable object that is an actual argument associated with an an INTENT(OUT) dummy argument is finalized.'' Is the target of TV finalized with SUB is invoked? If TV were allocatable instead of a pointer would it be finalized? ANSWER: 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 is finalized with the procedure is invoked. Edits are provided to correct the error. EDITS: Replace the sixth paragraph of 4.5.5.2 [04-007:59:31-32] with the following: "When a procedure is invoked, an object that becomes argument associated with a nonpointer nonallocatable INTENT(OUT) dummy argument of that procedure is finalized." Or "An object that becomes argument associated with a nonpointer nonallocatable INTENT(OUT) dummy argument of a procedure is finalized when the procedure is invoked." Or "An object is finalized when it becomes argument associated with a nonpointer nonallocatable INTENT(OUT) dummy argument" SUBMITTED BY: Van Snyder HISTORY: 06-374 m178 F03/0085 submitted ---------------------------------------------------------------------- NUMBER: F03/0090 TITLE: Polymorphic array constructors KEYWORDS: polymorphic, array constructor DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider FUNCTION f(dummy,n) CLASS(t) dummy TYPE(t) f(n) f = [ (dummy,i=1,n) ] END FUNCTION (1) Is this standard-conforming? (2) If so, is the array constructor polymorphic? ANSWER: (1) Yes. (2) No. Its declared and dynamic type are both T. An edit is provided to clarify this. EDITS: [67:21] "same type" -> "same declared type" [68:9] "type and" -> "declared type and" [68:14+] Insert new paragraph "The dynamic type of the array constructor is the same as its declared type." SUBMITTED BY: Van Snyder HISTORY: 07-231 m180 F03/0090 submitted (revised by M. Cohen) 07-231 m180 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 Jim Xia's NO vote on F03/0090: Answer (2) of the interp says an array constructor is non-polymorphic with declared type and dynamic type both of T. I see at least four problems with this answer: 1) There is no requirement anywhere in the standard for RHS expression be non-polymorphic in an intrinsic assignment. The array constructor can surely be interpreted as a polymorphic array, and the effect is the same as if a polymorphic pointer/ allocatable array appears as the RHS expression in the assignment. This interpretation will give the same results for the assignment. 2) There are other potential usage of an array constructor containing polymorphic entities, such as an actual argument to be associated with a polymorphic dummy array, a selector in ASSOCIATE or SELECT TYPE construct, a in an ALLOCATE statement for a polymorphic pointer/allocatable array. It's appropriate to interpret it as a polymorphic array with the same declared type and dynamic type as those appearing in the array constructor, respectively. 3) This interpretation prohibits use of unlimited polymorphic data in an array constructor because they don't have a declared type. There is no rationale in banning unlimited polymorphic entities in an array constructor. 4) The same effect of obtaining a non-polymorphic array constructor can already be achieved by using . ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider MODULE m TYPE t(n) INTEGER,LEN :: n REAL v(n) END TYPE END According to C542 at [78:21-22], the bounds in that are required to be initialization expressions. That seems to prevent the intended use of length type parameters. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to correct this. EDITS: [78:21-22] After "a function result," insert "a component,". SUBMITTED BY: Van Snyder HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen) ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is it allowed to change the value of a variable which supplies the unit number to an read statement? Page 219:16 says the value of any input/output specifier shall not depend on any input-item. If you trace back, the unit= is a specifier in a READ statement. Note 9.40 on page 196 gives the example READ(N) N, X(N) and discusses how the changes in N work. In F77 the similar example had READ(3). In Fortran 90 this was changed to READ(N) (on page 126) and was normative. In F95 the example was changed to a non-normative note. The words prohibiting the example usage appear to be new to F03. ANSWER: Yes, the example was intended to be allowed. The restriction on page 219 is overly restrictive. Edits will limit the restriction to "output items" in the specifier list and the Format. These are the items that the processor will usually reference during actual input/output transfers. EDITS: [219:16] In the 6th paragraph of 9.11 replace "The value of a specifier" with "The value of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier" SUBMITTED BY: Dick Hendrickson HISTORY: 07-266 m181 F03/0096 submitted 07-266r1 m181 Draft answer ---------------------------------------------------------------------- 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: Erratum STATUS: J3 consideration in progress DISCUSSION: 9.5.1.14 [191:21-26] 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 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: No, this example is not standard conforming. SIZE= specifier is not allowed in the example presented here. Edits are provided to correct this oversight. EDITS: [188:8+] In 9.5.1 "Control information list", after the list of constraints, append to the end of the first paragraph "A SIZE= specifier shall not appear in a parent input statement if the user-defined derived-type input procedure to be invoked performs either list-directed or namelist input on the same unit." 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 NO Comment for F03/0105 from Malcolm Cohen: I don't quite follow the reasoning behind this one; it appears to me that the characters are being transferred by the DT edit descriptor (proxied via the child i/o procedure). It is also a horrible restriction that cannot be detected statically. Resolution for F03/0105: failed letter ballot We believe that the example is standard conforming. We believe the Standard requires SIZE= to work in the presence of child I/O. ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: ERRATUM STATUS: J3 consideration in progress 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: Yes, it should. It was not intended to add new functionality to ENTRY in Fortran 90, 95, 2003. It is of course not timely to ask for a corrigendum to Fortran 90 or Fortran 95. EDITS: At [04-007:283:36-38] After the words "as a dummy argument" add "or as the entry-name" "In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in an executable statement preceding that ENTRY statement" SUBMITTED BY: Michael Ingrassia HISTORY: 07-341 m182 F03/0110 submitted ---------------------------------------------------------------------- NUMBER: F03/0112 TITLE: Attributes allowed for dummy arguments in defined assignments KEYWORDS: defined assignment, dummy argument, attributes DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot INTRODUCTION: It seems the standard is quite loose in allowing various attributes declared for the dummy arguments used in a defined assignment (7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE can be declared for dummy arguments in the defined assignment. However the interpretations on their declarations need to be clarified. QUESTION: Consider the follow subroutines (assuming a derived type DT already defined) Q1. Are POINTER and ALLOCATABLE attributes allowed for the second dummy argument in defined assignment? interface ASSIGNMENT (=) subroutine defAssgn1 (dt1, dt2) type(DT), intent(out) :: dt1 type(DT), POINTER, intent(in) :: dt2 end subroutine end interface In 12.3.2.1.2 [263:10-12], the standard says the following "A defined assignment is treated as a reference to the subroutine, with the left-hand side as the first argument and the right-hand side enclosed in parentheses as the second argument." This statement seems to prohibit the use of subroutine defAssgn1 for defined assignment since a pointer enclosed in parentheses refers to its associated target not the pointer itself, as indicated by rules in 7.1.4.1 [123:39-124:3]. Q2. Are POINTER and ALLOCATABLE attributes allowed for the first dummy argument in defined assignment? interface ASSIGNMENT (=) subroutine defAssgn2 (dt1, dt2) type(DT), POINTER, intent(out) :: dt1 type(DT), intent(in) :: dt2 end subroutine end interface There are no rules in the standard that disallow this declaration. However the use of POINTER/ALLOCATABLE attributes on the first dummy argument is very doubtful. Since POINTER/ALLOCATABLE attributes don't disambiguate generic declarations(16.2.3), their use will prevent the normal declarations of defined assignments, wherein dt1 is declared without POINTER or ALLOCATABLE attribute. ANSWER: Yes to both questions. The interface blocks are not defective. The standard places very few restrictions on the arguments to defined assignment subroutines: [363:6...] Each of these subroutines shall have exactly two dummy arguments. Each argument shall be nonoptional. The first argument shall have INTENT (OUT) or INTENT (INOUT) and the second argument shall have INTENT (IN). ... Preventing the first argument from having the POINTER attribute violates F90. Preventing the second argument from having the ALLOCATABLE attribute would introduce a prohibition not specified by TR 15581, and might therefore be viewed as an incompatibility that ought to be announced in subclause 1.5. A program couldn't reference defAssgn1 by way of defined assignment because the right-hand side of a defined assignment is treated as an expression enclosed in parentheses which would have neither the POINTER nor the ALLOCATABLE attribute. A note is provided to draw the readers attention. EDITS: At the end of 12.3.2.1.2 insert a new NOTE 12.10+: "NOTE 12.10+ If the second argument of a procedure specified in a defined assignment interface block has the POINTER of ALLOCATABLE attribute, it cannot be accessed by defined assignment, since the right-hand side of the assignment is enclosed in parentheses before being associated as an actual argument with the second argument. This makes it an expression, which does not have the POINTER or ALLOCATABLE attribute." SUBMITTED BY: Jim Xia HISTORY: 08-120 m183 F03/0112 Submitted 08-120r1 m183 Create answer 08-120r2 m183 Passed by J3 meeting 08-163 m184 Failed J3 letter ballot 08-141 08-186r1 m184 Another answer - Passed by J3 meeting 08-259 m185 Failed J3 letter ballot #17 08-213 08-263r1 m185 Revised answer - passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot 09-155 F2008 note: edit is 09-007r1 [287:6-] 12.4.3.4.3 "Defined assignments" after NOTE 12.8 - edit passed at m188 ---------------------------------------------------------------------- NUMBER: F03/0115 TITLE: Are circular dependencies between specification expressions permitted? KEYWORDS: specification expression DEFECT TYPE: Erratum STATUS: Withdrawn by submitter QUESTION: Is the following specification part standard conforming? integer :: A(size(B)) integer :: B(size(A)) ANSWER: The specification part is not standard conforming. Edits are proovided to clarify this. EDITS: Before item (7)(b)(i) in Subclause 7.1.6 "Specification Expressions" insert another item "(i-) declared after the specification inquiry," SUBMITTED BY: Van Snyder HISTORY: 08-151 m184 F03/0115 submitted - withdrawn by submitter F2003 04-007, section 7.1.6 {126:14-19] says: 9 A variable in a specification expression shall have its type and type parameters, if any, specified by a 10 previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, 11 or by host or use association. If a variable in a specification expression is typed by the implicit typing 12 rules, its appearance in any subsequent type declaration statement shall confirm the implied type and 13 type parameters. No further action will be taken on F03/0115 ---------------------------------------------------------------------- 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/0119 TITLE: Elemental procedures and deferred length character components KEYWORDS: deferred length, elemental DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Constraint C1279 says "In the scoping unit of an elemental subprogram, an object designator with a dummy argument as the base object shall not appear in a except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6)." It has been stated in previous J3 papers that the reason for this restriction is to ensure that every iteration of a single invocation of an elemental procedure will have the same stack size: and this desire was achieved in Fortran 95. However, the situation changes with deferred-length character components. Consider example 1: PROGRAM example1 TYPE t CHARACTER(:),ALLOCATABLE :: cp END TYPE TYPE(t) array(100) DO i=1,100; array(i)%cp = REPEAT('x',i); END DO CALL zap(array) ... CONTAINS ELEMENTAL SUBROUTINE zap(x) TYPE(t),INTENT(INOUT) :: x REAL work(LEN(x%cp)) ... END SUBROUTINE END PROGRAM In the invocation "CALL zap(array)", the invoked procedure will have a different size for its WORK array for every element of ARRAY. Thus the restriction no longer achieves its aim (though this aim is not actually stated in the standard). However, as stated the restriction still prohibits the very similar program example2: PROGRAM example2 INTEGER :: array(100) = (/ (i,i=1,100) /) CALL es(array) PRINT *,array CONTAINS ELEMENTAL SUBROUTINE es(x) INTEGER,INTENT(INOUT) :: x REAL work(x) ... END SUBROUTINE END PROGRAM There does not seem to be any technical reason for the prohibition of example2. A more problematic case arises for an elemental function whose result variable has a length type parameter that depends on a deferred length parameter of a dummy argument. This can occur both for intrinsic type CHARACTER and for parameterized derived types. Consider: PROGRAM example3 TYPE t1(n) INTEGER,LEN :: n INTEGER istring(n) END TYPE TYPE t2 CHARACTER(:),ALLOCATABLE :: string END TYPE PRINT *,f( [ t2('short'),t2('this is much longer') ] ) CONTAINS ELEMENTAL FUNCTION f(x) TYPE(t2),INTENT(IN) :: x TYPE(t1(x%string%len)) f INTEGER j f%istring = [ (ICHAR(x%string(j:j),j=1,f%n)) ] END FUNCTION END The invocation of F in the PRINT statement will return an array whose elements have different length type parameters, something that is supposed to be impossible. Is this restriction still correct and useful? That is, (a) was example1 intended to be standard-conforming, (b) should example2 be standard-conforming, (c) was example3 intended to be standard-conforming. ANSWER: Although there is no technical (implementation) reason for prohibiting example2 while allowing example1, doing so is not a defect in the standard. However, allowing elemental functions to produce arrays whose elements have different length type parameters would be a defect. Thus, example1 is standard-conforming as argued; example2 is not conforming, because it violates constraint C1279; example3 was intended to be prohibited: an edit is supplied to fix this defect in the standard. EDIT: In 12.7.1, constraint C1278, [287:17] After "scalar" change "and" to a comma. [288:1] At the end of the sentence insert ", and shall not have a type parameter that is defined by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 08-258 m185 Submitted F03/0119 08-299r1 m186 Revised answer, passed by J3 meeting 09-103 m187 Revised, passed by J3 meeting + F2008 fix 09-187 m188 Passed J3 letter ballot 09-155 as modified ---------------------------------------------------------------------- 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: J3 consideration in progress QUESTION: Must the intrinsic function REAL with KIND parameter wp return a value that is a REAL (KIND=wp) floating point number? RATIONALE FOR THE QUESTION: Computer hardware may use a wider floating-point format for registers than for memory; e.g., 80 bits for registers and 64 bits for memory for the case of standard double precision floating point numbers. Some algorithms require a high level of control over floating point semantics. If the intrinsic function REAL with KIND parameter wp is guaranteed to return a REAL (KIND=wp) result then a programmer can use this to force intermediate results into main memory format, never mind that the optimizing compiler may have placed the intermediate in a register. I am interested in a J3 interpretation of this matter, especially a loud and clear affirmative interpretation, because it appears that some present Fortran compilers optimize away my explicit use of the REAL intrinsic. The context is code for compensated summation (Kahan summation). I appreciate that parentheses are inviolable courtesy of the Fortran standard, but in order to have code that cannot be broken by an optimizing compiler I seem to need also a language mechanism to force intermediate results into main memory format. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANSWER: EDITS: HISTORY: 08-208r1 m185 F03/0121 submitted ---------------------------------------------------------------------- NUMBER: F03/0122 TITLE: When do objects of sequence derived type have the same type? KEYWORDS: SEQUENCE type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE MOD TYPE, PRIVATE :: T SEQUENCE INTEGER :: I END TYPE TYPE(T) :: X, Y CONTAINS SUBROUTINE S X = Y END SUBROUTINE S END PROGRAM MAIN USE MOD CALL S X = Y END The first sentence of subclause 4.5.1.3 of the 2003 Fortran standard says the program conforms because the objects X and Y have the same type, because they are declared by reference to the same type definition. The last sentence of that subclause says they do not have the same type because the type definition is declared to be PRIVATE. Does the program conform to the 2003 Fortran standard? If not, which assignment statement causes the program not to conform? ANSWER: The program conforms to the 2003 Fortran standard. ANALYSIS: The determination that an object cannot have the same type as another one that is declared by reference to a type that is declared to be PRIVATE cannot possibly refer to an object declared in a scope where the type is not accessible. Therefore the objects must be declared in scopes where the type is accessible. It is irrelevant whether the type is "declared to be PRIVATE" in that scope, because accessibility attributes determine whether a name is accessible in a different scope. It would be absurd if the assignment statement in the module subprogram were not standard conforming. Given that it must be standard conforming, it would be absurd if the assignment statement in the main program were not standard conforming. Edits are provided to clarify this conclusion. EDITS: In subclause 4.5.1.3 [47:11], remove "declared to be PRIVATE or" from the last sentence. SUBMITTED BY: Van Snyder HISTORY: 08-270 m185 F03/0122 submitted 08-270r1 m185 Passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot 09-155 F2008 note: edit is 09-007r1 [63:10] 4.5.2.4 "Determination of derived types" remove "declared to be PRIVATE or" - edit passed at m188 --------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: This is from Robert Corbett via f08 PC J32026 a/k/a 08-240. AT 185, 08-240r1 suggested making this an Interp. Done herewith. Consider the program PROGRAM MAIN TYPE T INTEGER :: I = BIT_SIZE(J) END TYPE CALL SUBR1 CONTAINS SUBROUTINE SUBR1 J = 1 CALL SUBR2 PRINT *, J END SUBROUTINE SUBROUTINE SUBR2 J = 2 END SUBROUTINE END This program prints either 1 or 2 depending on the implementation with which it is compiled. Some implementations implicitly declared J in the top-level scope of the main program. Some declare J in the scope of the derived type definition, which is semantic nonsense, but there you have it. ANSWER: Paragraph 4 of Section 5.5 of the Fortran 2008 draft states The data entity is treated as if it were explicitly declared in the outermost scoping unit in which it appears. The derived type definition is the outermost scoping unit in which the occurrence of J in the derived type definition appears, but an explicit definition of J is not allowed in that context. The simple solution for this problem is to ban implicit typing in derived type definitions. EDITS: None SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-268 m185 F03/0123 submitted - from a public comment processed in 08-240r2 ---------------------------------------------------------------------- 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, Y EQUIVALENCE (I, X, Y) X%J = 2 I = 1 PRINT *, I, X, Y END The assignment to the variable I causes I, X, and Y to become defined (see items (1) and (15) of Section 16.6.5). Therefore, according to item (1) of Section 16.6.6, I, X, and Y become undefined. ANSWER: Item (1) of Section 16.6.6 should be modified so that it directly applies only to ultimate components. The effect on aggregate types will then occur as is appropriate because of the rules given in Section 16.6.1. EDITS: none proposed SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted - from a public comment J32027 processed in 08-241 ---------------------------------------------------------------------- NUMBER: F03/0125 TITLE: Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS KEYWORDS: EXTENDS_TYPE_OF SAME_TYPE_AS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The arguments of EXTENDS_TYPE_OF and SAME_TYPE_AS are required to be of extensible type. Does this restriction apply to the declared type, the dynamic type, or both? ANSWER: This restriction was intended to apply to the dynamic type; this is clear from the existing text. However, the restriction is stronger than required or useful, and so an edit is supplied to weaken it. DISCUSSION: For EXTENDS_TYPE_OF, this is clear from the Result Value paragraph which explicitly specifies the result when either the A or MOLD argument to the intrinsic is unlimited polymorphic. For SAME_TYPE_AS, this is clear from Note 13.17 which explains how to work out the result when one or both arguments is a disassociated pointer (or unallocated allocatable), including that of an unlimited polymorphic entity. However, in the case of unlimited polymorphic, it is unreasonable to require the program to somehow know that the dynamic type is extensible; these functions should return the right result whenever either argument is of extensible type, and otherwise it should be processor dependent, i.e. the restriction should be weakened. EDITS: [316:16-17] In 13.7.38, EXTENDS_TYPE_OF, arguments A and MOLD, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [316:21] Change the last "otherwise" to "if the dynamic type of A or MOLD is extensible,". [316:22] At the end of the sentence insert "; otherwise the result is processor dependent". [347:30,348:1] In 13.7.101, SAME_TYPE_AS, arguments A and B, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [348:3] Change "The" to "If the dynamic type of A or B is extensible, the" [348:4] Append new sentence to paragraph "If neither A nor B have extensible dynamic type, the result is processor dependent." SUBMITTED BY: John Reid HISTORY: 08-281 m186 F03/0125 submitted 08-281r2 m186 Passed by J3 meeting + F2008 fix 09-187r2 m188 Passed by J3 letter ballot #18 09-155 ---------------------------------------------------------------------- NUMBER: F03/0126 TITLE: References to VOLATILE variables in pure procedures KEYWORDS: VOLATILE, PURE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended to allow a VOLATILE variable to be referenced in a pure procedure? ANSWER: No. It was intended that the result of invoking a pure function in a FORALL assignment statement should never depend on the order in which the invocations are executed, see NOTE 12.44. The value of a variable with the VOLATILE attribute might change between invocations of the function in ways incompatible with this design. EDIT: [286:22+] In 12.6, Pure procedures, add a new constraint: "C1271a The of a variable with the VOLATILE attribute shall not appear in a pure subprogram." SUBMITTED BY: John Reid and Bill Long HISTORY: 08-284 m186 F03/0126 submitted in response to N1745 by Nick Maclaren noting the problem 08-284r1 m186 Passed by J3 meeting {F2008 fixed in 12.7 "Pure procedures" 09-007 [317:14] C1281} 09-187r2 m188 Passed J3 letter ballot #18 09-155 ---------------------------------------------------------------------- NUMBER: F03/0127 TITLE: Duration of procedure execution KEYWORDS: argument association, procedure DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: In the following questions, the following type definition and procedure are assumed: TYPE T INTEGER :: C = 17 END TYPE SUBROUTINE S(A,B) TYPE(T),INTENT(IN) :: A TYPE(T),INTENT(OUT) :: B ... END (1) Consider TYPE(T) X X%C = 3 CALL S(X,X) Q1. Is this valid, and if so, is A%C equal to 3 or 17? Discussion: B is default-initialized "on invocation", and A is not permitted to be changed "during execution", so this depends on whether "during execution" was intended to include the process of invocation. (2) Consider TYPE(T) X X%C = 3 CALL S(F(),X) where F is the internal function TYPE(T) FUNCTION F() F = X END FUNCTION Q2. Is this valid? If so, what is the value of B%C (3 or 17)? Discussion: The reference to procedure F is not permitted to "affect or be affected by the evaluation of any other entity within the statement" (7.1.8 paragraph 3). However, X is not being affected by "evaluation" (it is not being evaluated by becoming argument- associated with dummy argument A). A becomes defined "on invocation" of S and it is not clear whether that precedes argument evaluation or not. (3) Consider SUBROUTINE V(AA,BB) TYPE(T),VALUE :: AA TYPE(T),INTENT(OUT) :: BB ... END TYPE(T) X X%C = 3 CALL V(X,X) Q3. Is this valid? If so, what is the value of AA%C (3 or 17)? Discussion: AA gets its value by argument association, so happens at the same time as the definition of BB (which defines the actual argument). It is not clear what the semantics are here. Q4. It is similarly unclear as to what is or is not permitted during invocation of a procedure when an actual argument might be modified by some other activity, for example if it has the VOLATILE or ASYNCHRONOUS attribute. ANSWER: The standard does not unambiguously supply an interpretation of these, and therefore they are invalid by subclause 1.5, first sentence. Edits are supplied to clarify this. EDITS: [81:15] 5.1.2.7, paragraph beginning "The INTENT(IN)", change "during the execution" to "during the invocation and execution". {Makes example 1 clearly invalid, and makes it clear that INTENT(IN) variables are unchanged from the start of invocation.} [81:26] Append to the INTENT(OUT) paragraph "Any undefinition or definition implied by association of an actual argument with an INTENT(OUT) dummy argument shall not affect any other entity within the statement that invokes the procedure." {Makes examples 2 and 3 clearly invalid.} [275:2,5] Change "during the execution" To "during the invocation and execution", Twice. {Makes it clear that the anti-aliasing rules apply for the whole process of procedure invocation and execution, not just the execution part.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-298r1 m186 F03/0127 submitted 08-298r2 m186 Passed by J3 meeting + F2008 edit 09-187r2 m188 Passed J3 letter ballot #18 09-155 ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Was it intended to disallow vendors to provide namelist output that includes a subobject designator followed by a value? ANSWER: No, it was intended that vendors should have the same choice as users writing namelist input as to whether to provide the name of an object followed by a list of values that give the value of the object or to provide a sequence of subobject designators, each followed by a list giving the value of the subobject. DISCUSSION: At the start of clause 10.10.2 (Namelist Output) of the Fortran 2003 standard, as amended by Corrigendum 3, is the text "The form of the output produced is the same as that required for input, except for the forms of real, character, and logical values, and output produced with user-defined derived-type output". There is no exception for the freedom on input to use subobject designators. The text in the second paragraph of clause 10.10.2.2, says "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.". The intention here was to use "name" in the generalized sense of name or designator, as in paragraph 1 of clause 10.10.1.1: "If a namelist group object is an array, the input record corresponding to it may contain either the array name or the designator of a subobject of that array, using the syntax of object designators (R603). 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." Because of the meaning attached to "name", in the rest of the standard, it should not be used in this way in clause 10.10.2.2. EDIT: [247:27] In 10.10.2.2, Namelist output records, paragraph 2, change "The name" to "The name or designator". SUBMITTED BY: John Reid HISTORY: 09-115 m187 Submitted F03/0128 09-115r1 m187 Passed by J3 meeting + F2008 fix {pulled} 09-187r2 m188 Failed J3 letter balllot #18 09-155: accept edit line number change, F2008 fix from m187 does not appear in 09-0007r1; Malcolm Cohen REASON for F03/0128 NO vote: The sentence being edited begins "The name of each namelist group object list item is placed ...". This is not ambiguous in any way. The namelist group object list items are the named variables in the NAMELIST statement; see p95 R553 <> There can be no question about this, regardless of what nonstandard behaviour some vendor might or might not do. This is a feature request, and what's more, one that makes a processor that uses the feature not compliant with Fortran 90/95. In the compatibility section we list the things that "may have a different interpretation" for F77, so this ought to be there as well (that is if we thought it was a good idea). Oh, and the edit is way short of implementing the feature, since the "designator" of a namelist group object list item is just its name. ---------------------------------------------------------------------- NUMBER: F03/0129 TITLE: C_LOC of character substrings KEYWORDS: interoperability DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider SUBROUTINE S(A,I,K) USE ISO_C_BINDING CHARACTER(*),TARGET :: A CHARACTER(:),ALLOCATABLE,TARGET :: B TYPE(C_PTR) P1,P2,P3,P4,P5 P1 = C_LOC(A(1:1)) ! *1 P2 = C_LOC(A(I:I)) ! *2 P3 = C_LOC(A(1:)) ! *3 P4 = C_LOC(A(I:K)) ! *4 ALLOCATE(CHARACTER(1)::B) P5 = C_LOC(B) ! *5 END SUBROUTINE C_LOC (case 1) requires of its argument that it have interoperable type and type parameters (15.1.2.5, p395). Case 2 does not apply because character type has a length type parameter. 15.2.1 states "if the type is character, interoperability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one". However, a substring does not have a declared type parameter that can be omitted or specified by an initialization expression. Even in the reference marked *1, it is the substring starting and ending positions that are specified by initialization expressions, not the substring length. In any case, if *1 satisfied the quoted requirement then *3 also has its starting and ending positions specified by by initializations "or omitted". In case *2, it must be totally obvious that the length has to be 1 since the expressions are lexically identical with no user function references, but neither are initialization expressions. If I==K, it would be reasonable to expect *4 to be interoperable but it certainly does not satisfy the stated requirements. Or, another interpretation would be that for substrings the length type parameter is by definition "omitted" since they have no syntax for its specification: in which case the question would arise as to what happens for zero-length substrings. It seems that the authors of the requirement forgot that "variables" include "substrings". Finally, case *5 is totally ambiguous because B has multiple length specifications, one which does not satisfy the requirement (the declaration) and one which does (the ALLOCATE statement). ANSWER: C_LOC should only require nonzero length, which corresponds to the requirement we make for arrays. Furthermore, the description of interoperability of intrinsic types is confusing for type CHARACTER. Edits are provided to fix the defects. EDITS: [395:8(15.1.2.5)] In the <> paragraph, Before "type parameters" insert "kind". [395:16+] Insert new sentence after list: "X shall not be a zero-length string." [396:5-7] Replace "; if ... one." with ". If the type is character, the length type parameter is interoperable if and only if its value is one." {Reword so that the type/kind can be interoperable even if the length is not.} [399:2-3(15.2.4p1)] Before "scalar" insert "named", {I think this is supposed to be talking about named variables only, not about subobjects.} Change "if" to "if and only if" {Seems to be broken...} Change the second "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". {It seems more straightforward to forbid the invalid than to require the valid.} [399:7-8(15.2.5)] Change "An array Fortran variable" to "A Fortran variable that is a named array", Change "if" to "if and only if", Change the second "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 09-121r1 m187 Submitted F03/0129 09-121r1 m187 Passed by J3 meeting + F2008 fix 09-187r2 m188 Passed J3 letter ballot 09-155 as modified ---------------------------------------------------------------------- NUMBER: F03-0130 TITLE: Elemental specific intrinsic procedure characteristics KEYWORDS: Elemental intrinsic, procedure pointer, dummy procedure DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: (1) Are the specific intrinsic procedures (listed in 13.6 and not marked with a bullet) elemental or nonelemental? (2) What rank do those specific intrinsic procedures have? (3) May one of those procedures become associated with a dummy procedure or procedure pointer with nonzero rank? (4) When one of these procedures is associated with a dummy procedure or procedure pointer, does it still have the elemental property? ANSWER: (1) Those specific intrinsic procedures are elemental. (2) They are elemental functions; thus they are scalar in themselves, but may be applied to an array in which case the reference will be an array. (3) No. As elemental procedures, by definition the dummy arguments and result have rank zero. This does not satisfy the requirements for procedure argument or procedure pointer association. (4) The specific intrinsic procedure itself retains the elemental property (so a reference using its own name can be elemental), but the dummy procedure or procedure pointer associated with it is not elemental and so cannot be used to reference the specific intrinsic procedure elementally. EDIT: None. SUBMITTED BY: Van Snyder HISTORY: 09-171r1 m188 Submitted F03/0130 09-217 m188 Revised question/answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0131 TITLE: SAVE attribute and EQUIVALENCE KEYWORDS: SAVE, EQUIVALENCE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: If one object in an EQUIVALENCE set has the SAVE attribute, do all the other objects in the EQUIVALENCE set implicitly have the SAVE attribute? This can be detected by the program: SUBROUTINE s1 TYPE T SEQUENCE REAL :: C = 3.0 END TYPE TYPE(t) x,y SAVE x EQUIVALENCE(x,y) x = t(1.0) RETURN ENTRY s2 PRINT *,y ! Does this print 1.0 or 3.0? END PROGRAM show CALL s1 CALL s2 END If Y has the SAVE attribute the program will print 1.0; if not, it will print 3.0 due to the default initialization. ANSWER: Yes, the SAVE attribute propagates through EQUIVALENCE. An edit is supplied to clarify this. EDIT: [97:7+] Insert new paragraph "If any data object in an has the SAVE attribute, all other objects in the have the SAVE attribute; this may be confirmed by explicit specification." SUBMITTED BY: Malcolm Cohen HISTORY: 09-194 m188 Submitted F03/0131 09-194r1 m188 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0132 TITLE: Unformatted i/o and private components KEYWORDS: UNFORMATTED, INPUT/OUTPUT, PRIVATE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Module M Type T Private Real :: UDATA(100) End Type End Module ... Type(T) X ... Write (10,*) X ! Formatted Write Write (20) X ! Unformatted Write Both of the WRITE statements were not valid Fortran 95. Are either of them valid Fortran 2003? According to [193:9-12], the formatted WRITE statement is not valid. But the corresponding paragraph for unformatted WRITEs, at [193:1-5], only forbids private components when some component of T would itself be handled by user-defined derived-type input/output. That does not seem to be consistent. DISCUSSION: The "shall not be pointers or allocatables" part of the [193-:1-5] paragraph is repeated later, at [193:13-15]. This makes no mention of accessibility. ANSWER: Both cases were intended to be invalid. An edit is supplied to repair the requirements for unformatted i/o. EDIT: [193:13-15] Replace paragraph "If a derived-type list item is not processed by a user-defined derived-type input/output procedure and is not treated as a list of its individual components, all the subcomponents of that list item shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable". SUBMITTED BY: Malcolm Cohen HISTORY: 09-195 m188 Submitted F03/0132 - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0133 TITLE: Is unlimited polymorphic allowed in COMMON? KEYWORDS: Unlimited polymorphic, CLASS(*), COMMON DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: For a pointer to a derived type to be storable in COMMON, it must be of sequence type. However, there does not seem to be any prohibition against a CLASS(*) pointer in COMMON. Is this allowed? ANSWER: This was inadvertently allowed in the Fortran 2003 standard as published. An edit is supplied to correct this error. EDIT: [98:22] After "BIND attribute," insert "an unlimited polymorphic pointer," SUBMITTED BY: Malcolm Cohen HISTORY: 09-204 m188 Submitted F03/0133 - passed by J3 meeting ----------------------------------------------------------------------