J3/08-006A Outstanding Fortran Interpretations, January 28, 2008 Stan Whitlock for /interp > see 05-015 == closed F95 interps > see 05-016 == 05-006T1 of m173 for interps for F2003 Corr #1 N1636 > see 08-017 == 06-006T2r1 of m177 for interps for F2003 Corr #2 N1664 > includes interps passed by J3 letter ballot #13 {07-250r1/07-272} > includes interps submitted at m181 {92..101} and passed * includes interps passed by J3 letter ballot #14 {07-279/07-321} * includes interps submitted at m182 {102..109} and passed [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, 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) X Excluded for the reasons given N S T number title - - - ------ ----- * X F95/0031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) * P I F95/0074 TARGET dummy arguments and POINTER expressions * P F95/0098 Are dummy functions returning assumed-length character legal? * P E 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 * M E F03/0003 Referencing deferred bindings * M 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 E 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? * P I F03/0022 Coexistence of IEEE and non-IEEE kinds T2 E F03/0023 IEEE_SET/GET_UNDERFLOW_MODE * P I 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() * P 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() * P 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 * B E F03/0049 Separators in list-directed output involving UDDTIO * B 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 P E F03/0063 Procedure pointers in BLOCK DATA program units * P E F03/0064 Recursive declaration of procedure interfaces * P 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? * P I F03/0071 Subroutine/function ambiguity in generics T2 E F03/0072 Default initialization for "automatic" components * P E F03/0073 C interop of dummy procedures * P E F03/0074 Type mismatch for C character arguments * P E F03/0075 C interop of derived types with array components * P C F03/0076 Scope of Fortran names of procedures with binding labels * P E F03/0077 LBOUND of array structure component * P C F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence * M E F03/0079 Value of decimal exponent for a real zero value * M I F03/0080 Formatted output of a negative real zero value * P C F03/0081 F edit descriptor with field width 0 * P E 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 * B E F03/0086 Elemental and BIND(C) * P E F03/0087 Entry names as dummy procedure arguments * B E F03/0088 Defined operations/assignments and VOLATILE/ASYNCHRONOUS * B 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 * B E F03/0092 Procedure characteristics and unlimited polymorphic * B E F03/0093 Allocatable array on intrinsic assignment with scalar expr * B E F03/0094 Final subroutine and VALUE attribute * B I F03/0095 Bounds remapped pointer assignment and ASSOCIATED * P E F03/0096 Can a read statement change the unit value? * B E F03/0097 Blanks as separators in NAMELIST input * B E F03/0098 Does allocate with source= define subcomponents? * M E F03/0099 Clause 16 does not account for volatile variable * M E F03/0100 Error in field width for special cases of signed INFINITY output * B E F03/0101 Is UDDTIO output suitable for namelist and list-directed input * M E F03/0102 Evaluation of bound-expr in data pointer assignment * M E F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type * M I F03/0104 Deallocation and finalization of bounds-remapped pointers * M E F03/0105 SIZE= specifier and UDDTIO * M E F03/0106 Inquire by unit inconsistencies * M E F03/0107 Are the IEEE_* elemental routines required * M C F03/0108 Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions * M E F03/0109 Referencing deferred binding via absent dummy argument Here is the complete index to the F95 interps: N S T number title - - - ------ ----- d P I 000000e Rejected Minor edits and corrections C1 I 000001 Visibility of a data object with statement scope C2 I 000002 Free source form requirement for blank in PRINT statement C1 I 000003 Ability to overload the character operator // d W I 000004 Value returned by MAXVAL/MINVAL C1 I 000005 Value returned by SELECTED_REAL_KIND d W I 000006 Character length specification of a function result C2 I 000007 Optional intrinsic function arguments d W I 000008 Optional arguments to MAX/MIN C2 I 000009 INTENT of MOLD argument to TRANSFER C2 E 000010 Meaning of embedded blanks in namelist input name C2 E 000011 G editing typo C2 E 000012 Evaluation of Intrinsic Procedures X 000013 Format of zero in list-directed and namelist output {removed completely - questions duplicated in 000067 in C2} C2 000014 Format of complex numbers in list-directed and namelist output C2 000015 Commas in list-directed output X 000016 Completely removed - duplicate of 000071 d W I 000017 Characteristics of an array function result C2 E 000018 ELEMENTAL procedures with no arguments C2 E 000019 Result of NULL intrinsic associated with CHARACTER(*) dummy argument C2 E 000020 Execution of a WHERE statement within a WHERE construct C2 E 000021 Restrictions on on END INTERFACE C2 E 000022 Use of NULL() as initialization d W I 000023 Termination of the previous record by a WRITE statement C2 E 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement C2 E 000025 List-directed input: types of variables corresponding to repeated values C2 I 000026 List-directed input: types of variables corresponding to repeated values C2 C 000027 Sequential formatted I/O: position of the left tab C2 C 000028 Implicitly Typed Statement Function Character Dummy C2 C 000029 Association of a pointer actual argument with a dummy argument W T1 E 000030 Ordering requirements on definition of specification functions * X 000031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) C2 000032 Is the TRANSFER function result undefined? C2 E 000066 Errors in processing data transfer statements C2 E 000067 Writing zeros d W I 000068 Asterisks as I/O units C1 E 000069 What is a numeric character? C1 E 000070 Asymmetry between constant specification and initialization expressions C2 E 000071 Character array constructors C1 E 000072 Resolving generic procedure references C2 000073 Is padding allowed in storage sequences? * P I 000074 TARGET dummy arguments and POINTER expressions C2 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures C1 E 000076 INTENT(IN) dummy arguments and implied DO loops C1 E 000077 INTENT(IN) dummy arguments and NULLIFY W T1 E 000078 Resolving generic procedure references C1 E 000079 Pointer Assignment and Allocatable Arrays C1 E 000080 Host association and the EXTERNAL attribute C2 E 000081 Definition status of derived-type objects with pointer components C1 E 000082 Usage of BOZ literal constants C1 E 000083 Scope of array-constructor implied-DO variable C1 E 000084 Events that cause variables to be defined C2 E 000085 Public components of private types C2 E 000086 Definition status requirements for defined operations C2 E 000087 MOD and MODULO intrinsic functions with zero divisor C2 E 000088 INTRINSIC statement and attribute C2 C 000089 Rules allowing duplicate names C2 E 000090 What do `Prior Specification' and `defined previously' mean? C2 E 000091 Definition of "present" is defective C2 E 000092 Values of the PAD= Specifier in the INQUIRE Statement C2 E 000093 Allocatable arrays as actual arguments C2 E 000094 NULL intrinsic in initialization expressions C2 E 000095 Names of functions, results and entry points W T1 E 000096 End-of-record and PAD C2 E 000097 Open Scratch File Example * P 000098 Are dummy functions returning assumed-length character legal? d W E 000099 STAT= variable requirements in ALLOCATE d W E 000100 TARGET attribute and structure components d W E 000101 Generic resolution * P E 000102 mask-expr evaluated only once d W E 000103 Derived type name DOUBLEPRECISION d W I 000104 Representation method of result of REAL d W I F90/000049 Characteristics of function results d W I F90/000070 Characteristics specified by interface bodies d W I F90/000096 Definition of "Declaration" C1 I F90/000100 ASSOCIATED intrinsic and zero-sized objects d W I F90/000140 TARGET attribute for a derived-type object with a pointer component * P E F90/000145 Expressions in of a FUNCTION statement C2 C F90/000164 Use of ONLY with multipart definitions C1 I F90/000179 DO variable with POINTER attribute d W I F90/000180 Unambiguous generic references C1 I F90/000185 What is the allocation status of an array after an allocation failure? C2 I F90/000190 Subobjects of constants in a DATA statement C2 I F90/000191 Interaction of SEQUENCE derived types and rename C1 I F90/000194 Statements between SELECT CASE and CASE C2 C F90/000196 Inaccessibility of intrinsic procedures C2 F90/000197 Relationship of NEAREST and SPACING C2 E F90/000204 Meaning of "same variable" description of MVBITS C2 E F90/000205 Restrictions on EXTERNAL d W I F90/000206 Collating sequence inconsistencies W T1 E F90/000207 Integer bit-model inconsistency d W I F90/000208 nonadvancing output followed by list directed output C2 E F90/000209 STOP|PAUSE in I/O statement d W I F90/000210 nonadvancing write followed by list directed write C2 E F90/000211 Multiple MODULE PROCEDURE specs C2 C F90/000212 EQUIVALENCE of Data Objects of Different Types or Kinds C2 E JP-04 Construction of derived-type values C2 I JP-05 Construction of array values C2 E JP-06 Type declaration statements C2 E JP-08 Type declaration statements C2 JP-12 Bounds of each dimension of an array pointer C2 E JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement d W I JP-17 Multiple occurrence of namelist group object in namelist group d W E JP-24 The bnf term shared-term-do-construct C2 E JP-31 Signs of literal constants X JP-39 Withdrawn by submitter ====================================================================== 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/0031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: Interpretation STATUS: Subsumed by interp #74 QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: The program does not conform to the standard. See the answer to F95 interpretation #000074. EDITS: None SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 F95/0031 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-200 m157 Passed by J3 meeting 10-2 01-275 m158 Failed J3 letter ballot 04-417r1 m170 Subsumed by interp #74 05-180 m172 F95 interp 000074 failed WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F95/0074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: Interpretation STATUS: J3 consideration in progress see also F95 interp 000031 QUESTION: Consider the following program. PROGRAM questionable REAL,TARGET :: x CALL s1(f(x)) CALL s2(f(x)) CALL s3(f(x)) CONTAINS FUNCTION f(a) REAL,POINTER :: f REAL,TARGET :: a f => a END FUNCTION SUBROUTINE s1(variable) variable = 42 ! statement 1 END SUBROUTINE SUBROUTINE s2(variable) INTENT(OUT) variable variable = 42 ! statement 2 END SUBROUTINE SUBROUTINE s3(targ) REAL,TARGET :: targ REAL,POINTER :: p p => targ PRINT *,ASSOCIATED(p,x) ! statement 3 END SUBROUTINE END Is this program standard-conforming, and if so, what value is printed? The real question is whether an expression argument that is a pointer function reference is treated as a variable (data-object) argument with the variable being the target of the pointer expression. (Or whether it is dereferenced as usual in the absence of POINTER dummy arguments). Re (statement 1), the question is whether VARIABLE is definable when argument-associated with "F()". Re (statement 2), if the previous answer was Yes (VARIABLE is definable), then presumably it can be made INTENT(OUT). A random sample of 4 compilers revealed that they considered it not to be definable. Re (statement 3), the question is whether P is pointer-associated with X, not pointer-associated with X, or processor-dependent. Of the same random sample 3 thought it was associated with X, 1 thought not. ANSWER: 1. The call to s1 is not standard conforming. 12.5.2.1 says: 'A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.' Here the actual argument is a function result, which is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. (Being "defined" or "undefined" is fundamentally a concept that applies only to variables.) 2. The call to s2 is not standard conforming. 12.4.1.1 says: 'If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.' Again the actual argument is a function result, which is not definable. 3. The call to s3 is standard conforming and the pointer assignment in s3 causes p and x to become associated. This may be deduced from 12.4.1.1, which says [200:38-42]: 'If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure ...' EDITS: None. SUBMITTED BY: Malcolm Cohen HISTORY: 99-198 m150 F95/0074 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-311 m168 Passed by J3 meeting vote - alternate answer removed 04-417r1 M170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- NUMBER: F95/0102 TITLE: mask-expr evaluated only once KEYWORDS: WHERE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is a mask-expr required to be evaluated in a WHERE such as: WHERE ( (/ .TRUE., .TRUE. /) ) A = A + 1 ELSE WHERE (MASKF()) A = MAX END WHERE where an optimizing compiler might notice that the ELSEWHERE branch will never be executed ? Page 112, line 38 says of the mask expression in ELSEWHERE statements "The mask-expression is evaluated only once." ANSWER: No, it is not required to evaluate the mask-expr in a WHERE. An edit is supplied to correct this oversight. EDITS: [112:30-31] Change "only once" to "at most once" [112:38] Change "only once" to "at most once" SUBMITTED BY: Matthijs van Waveren HISTORY: 03-239 m165 F95/0102 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 ---------------------------------------------------------------------- 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/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: I thought that the intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program (Sorry, but I don't have any compilers up to syntax-checking this). module defer type, abstract :: t contains procedure (sub), nopass, deferred :: deferred_proc end type t type, extends(t) :: t2 contains procedure :: deferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module defer program p use defer class(t), pointer :: x nullify(x) call x%deferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? Note that x%deferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. Nor is it clear that there is an intent to prohibit invocation of type-bound procedures for disassociated pointer objects; except in the case of deferred bindings, this seems well-defined and potentially useful. Because x is disassociated, its dynamic type is the same as its declared type, thus making the interpretation of x%nondeferred_proc reasonably clear. ANSWER: No, this was not intended to be a valid program. A type-bound procedure may not be invoked through an undefined pointer, a disassociated pointer, or an unallocated allocatable variable. An edit is supplied to clarify this situation. The same answer and edit also apply to F03/0004. EDITS: Insert after [04-007: 266: 24] ([07-007r3: 309: 11]): "The shall not be an undefined pointer, a disassociated pointer, or an unallocated allocatable variable." Note: this is the same edit as interp F03/0004. SUBMITTED BY: Richard Maine HISTORY: 04-322 m169 F03/0003 Submitted 04-322r1 m169 Passed by J3 meeting 04-418r1 m170 Subsumed by interp F03/0004 05-180 m172 Failed WG5 ballot N1617 - the edit is subsumed by F03/0004 07-280 m182 Revised 07-280r1 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: It appears that the dynamic type is undefined for a pointer with undefined association status. This impacts type-bound procedures. Consider the following program. module undefined type :: t contains procedure, nopass :: nondeferred_proc => sub end type t type, extends(t) :: t2 contains procedure, nopass :: nondeferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module undefined program p use undefined class(t), pointer :: x call x%nondeferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? If so, what does it print. Note that x%nondeferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. If x were disassociated, its dynamic type would be t and the interpretation of this would be reasonably clear. However, the standard does not appear to specify the dynamic type of x when its association status is undefined. Nor can I find any prohibition that applies to this case. ANSWER: No, the program is not valid, because the standard does not establish an interpretation of it. An edit is supplied to clarify this. Furthermore, the case with a disassociated pointer was not intended to be valid. An edit is supplied to correct this oversight. DISCUSSION: Access to object-bound procedures (a.k.a. procedure pointer components) always require there to be an object. Access to type-bound procedures of an object was intended to require this too, but the effect of the NOPASS attribute on this was overlooked. EDITS: All edits refer to 04-007. Insert after [266:24]: "The shall not be an undefined pointer, a disassociated pointer, or an unallocated allocatable variable." Note: this is the same edit as interp F03/0003. SUBMITTED BY: Richard Maine HISTORY: 04-323 m169 F03/0004 Submitted 04-323r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Failed WG5 ballot N1617 07-337 m182 Passed by J3 meeting ---------------------------------------------------------------------- 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 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 ---------------------------------------------------------------------- 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 J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 ---------------------------------------------------------------------- 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: Interpretation STATUS: J3 consideration in progress 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 intentional. Support of these two flags means that the exceptions can be detected, either by a subsequent use of IEEE_GET_FLAG or by program termination (this is not under program control unless IEEE_SUPPORT_HALTING is true for those flags). Whether the flags are supported outside of a routine which uses IEEE_EXCEPTIONS or IEEE_ARITHMETIC is processor dependent. EDITS: None. 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 Dick Hendrickson's NO comment on F03/0022: The answer doesn't appear to answer the details of the question. Saying that IEEE and non-IEEE reals are both allowed is not an answer the question about REQUIRING overflow and divide by zero for the NON-IEEE reals in the second paragraph. What practical use is there in requiring a processor to support overflow and divide-by-zero for NON-IEEE reals in a subroutine that uses both kinds of reals? Surely the purpose of NON-IEEE reals is that they are not bound by the same rules as the IEEE reals are. Why was it intentional to bind at least some of the IEEE rules to them? The answer should be reversed to state that the speculation in the last paragrpah of the question is correct, and edits provided. ---------------------------------------------------------------------- NUMBER: F03/0024 TITLE: DEALLOCATE and array pointers KEYWORDS: DEALLOCATE, array pointers DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: We currently say that one can deallocate an array pointer if it points to the "whole of an object that was created by allocation". What exactly does "whole" mean in this rule? Specifically, is the following allowed: REAL, DIMENSION(:), POINTER :: a, b ALLOCATE(a(1:10)) b=>a(1:10) DEALLOCATE(b) ANSWER: Yes, this is allowed, since "whole" means that b is ASSOCIATED with all elements of an array that was ALLOCATEd. In the given example, ASSOCIATED(a,b) is .TRUE., therefore either a or b can be used to DEALLOCATE the memory. EDITS: None 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 Dick Hendrickson's NO comment for F03/0024: The answer appears to be incomplete. The question is "What exactly does "whole" mean in this rule", but the answer appears to be limited just to the specific example given. We also need to consider things like b=>a(10:1:-1) Also, pining the answer to ASSOCIATED is risky for understanding other cases. ASSOCIATED is true for zero sized things. Given ALLOCATE(A(0),C(0)) b=>C then ASSOCIATED(B,A) is true, yet A isn't deallocated. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- NUMBER: F03/0034 TITLE: IEEE_LOGB() KEYWORDS: IEEE-754, logb() DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: What is logb(denormal)? Is it of the hardware representation, or is it as if the hardware had an unbounded exponent range? What is logb(NaN)? logb(-INF)? logb(+INF)? logb() should be defined as if the hardware representation had an unbounded exponent range. logb(NaN) should be the same NaN; shall be a NaN. logb(-INF) shall be +INF logb(+INF) shall be +INF ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the functions copysign, scalb, logb, nextafter, rem, and unordered shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED." Case (i) of 14.10.12 correctly specifies that if the value of X is denormal, its unbiased exponent is returned; however, the note there is wrong in this case. An edit is supplied. For consistency with the IEEE International Standard, an edit is also supplied for the case where X is infinite. EDITS: Page and line numbers refer to 04-007. [376:15]. Subclause 14.10.12, Result Value, line 2. After "Note:" add "if X is normal,". [376:17+]. Subclause 14.10.12, Result Value. Add extra case: "Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the result is +infinity." . 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 ---------------------------------------------------------------------- NUMBER: F03/0039 TITLE: HYPOT() KEYWORDS: IEEE-754, hypot() DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: 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 slightly. 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. EDITS: Page and line numbers refer to 04-007. [389:12]. Subclause 14.11, Note 14.17, final paragraph, line 2. Before "exception" add "overflow or underflow". [389:16+]. Subclause 14.11, Note 14.17, at the end of the final paragraph, add "This HYPOT function does not handle infinite arguments in the same way that the hypot function in the C International Standard does." 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *), 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? ANSWER: 1) No. It is the intent of the standard (10.9.2) that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard (10.9.2) that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list-directed output. When one of the sequences is written by a child or parent output statement that is not list-directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list-directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list-directed input/output, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. EDITS: [241:5+] In Section 10.9.2, add the following to the end of the first paragraph: "Two undelimited character sequences are considered adjacent when both were written using list-directed input/output, no intervening data transfer or input/output file positioning operations occurred, and both were written either by a single data transfer statement, or during the execution of a parent data transfer statement along with its child data transfer statements." SUBMITTED BY: Rob James HISTORY: 05-140 m171 F03/0049 Submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 06-367r1 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0050 TITLE: Questions about internal files KEYWORDS: internal file, data transfer DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: Question 1: Fortran 2003 does not seem to prohibit this kind of recursive internal input/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m1 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() WRITE(ifile, *) 'QWERTY' foo = 'abc' END FUNCTION END MODULE PROGRAM ex1 USE m1 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile END PROGRAM Question 2: Fortran 2003 does not seem to prohibit this kind of recursive internal Iinput/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m2 CHARACTER(20) :: ifile = 'abc def ghi jkl mno ' CHARACTER(3) :: char CONTAINS CHARACTER(3) FUNCTION foo() READ(ifile, *) char foo = 'abc' END FUNCTION END MODULE PROGRAM ex2 USE m2 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, char END PROGRAM Question 3: Fortran 2003 does not appear to prohibit modifying a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m3 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() ifile = 'bad thing to do?' foo = 'abc' END FUNCTION END MODULE PROGRAM ex3 USE m3 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM Question 4: Fortran 2003 does not appear to prohibit referencing a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m4 CHARACTER(20) :: ifile = '' LOGICAL :: flag = .FALSE. CONTAINS CHARACTER(3) FUNCTION foo() IF (ifile == ' xyz') THEN flag = .TRUE. END IF foo = 'abc' END FUNCTION END MODULE PROGRAM ex4 USE m4 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM ANSWER: All of these examples were intended to be prohibited. Edits are provided to prohibit referencing or defining a variable used as an internal unit as a result of evaluating any output list items, or transferring values to any input list item. EDITS: In section 9.5.3.4, after the paragraph: "If an internal file has been specified, an input/output list item shall not be in the file or associated with the file." add these paragraphs [196:29+]: "During the execution of an output statement that specifies an internal file, no part of that internal file shall be referenced, defined, or become undefined as the result of evaluating any output list item. During the execution of an input statement that specifies an internal file, no part of that internal file shall be defined or become undefined as the result of transferring a value to any input list item." SUBMITTED BY: Rob James HISTORY: 05-141 m171 F03/0050 Submitted 06-368 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0051 TITLE: Repeat specifiers and UDDTIO KEYWORDS: repeat specifier, POS=, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- 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: J3 consideration in progress 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: Yes, it was intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [253:12] After "derived-type definitions", insert ", abstract interface blocks,". [253:14] Before "and type declaration", insert "procedure declaration statements,". [254:3] After "specifiers", insert "if it declares a data object". [254:3] Append a new sentence: A procedure declaration statement shall not declare an external procedure. SUBMITTED BY: Rob James HISTORY: 05-178 m172 F03/0063 Submitted 05-225 m173 Passed by J3 meeting 06-133r1 m175 Passed J3 letter ballot #12 N1658 m176 Failed WG5 ballot N1657 ---------------------------------------------------------------------- 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. 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 Rob James' NO comment for F03/0064: There are some cases of this kind of thing that don't seem to be caught by this interpretation response. In particular, these cases don't seem to be prohibited: MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE Maybe some sort of statement would cover all of these cases if it is along the lines that a dummy procedure's characteristics can't depend on the characteristics of the procedure or interface body in which it is declared. ---------------------------------------------------------------------- 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: DISCUSSION: EDITS: SUBMITTED BY: Fred Tydeman HISTORY: 05-192 m173 F03/0065 Submitted ---------------------------------------------------------------------- NUMBER: F03/0071 TITLE: Subroutine/function ambiguity in generics KEYWORDS: subroutine, generic, implicit DEFECT TYPE: STATUS: J3 consideration in progress 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 uncertainly 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 of 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: I'm not sure. But presumably either the compiler is required to make the mentioned deductions or the code must be nonconforming. If the code is intended to be nonconforming, edits to say so might be needed. EDITS: To be supplied SUBMITTED BY: Richard Maine HISTORY: 05-265 m174 F03/0071 Submitted ---------------------------------------------------------------------- NUMBER: F03/0073 TITLE: C interop of dummy procedures KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: ERRATUM STATUS: J3 consideration in progress QUESTION: Is the following interface interoperable, and if yes, what is the interoperable C prototype? use iso_c_binding subroutine my_sub(my_fun) bind(c, name="My_Proc") interface function my_fun(x) bind(c) use iso_c_binding integer(c_int) :: my_fun real(c_double), value :: x end function end interface end subroutine ANSWER: Yes, this interface is interoperable with the following protype: void My_Sub(int (*my_fun)(double)) or equivalently (according to the C standard) void My_Sub(int my_fun(double)) Item (5) in the list in section 15.2.6 seems to have been written with only data objects in mind, and it is not clear whether it applies to dummy procedures. I quote it here: (5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and the dummy argument is interoperable with an entity of the referenced type (C International Standard, 6.2.5, 7.17, and 7.18.1) of the formal parameter; We believe that the intention is that dummy procedures be included, and that this text should be revised accordingly. EDITS: In item (5) in the list in section 15.2.6, replace "any dummy argument without the VALUE attribute" with "any dummy argument that is not a procedure and does not have the VALUE attribute" and replace "pointer type" with "object pointer type". and add a new item (5+) to the list: (5+) any dummy procedure argument corresponds to a formal parameter of the prototype that is of function pointer type, and the dummy procedure is interoperable with a function of the referenced type of the formal parameter; SUBMITTED BY: Aleksandar Donev HISTORY: 06-102 m175 F03/0073 Submitted ---------------------------------------------------------------------- NUMBER: F03/0074 TITLE: Type mismatch for C character arguments KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: ERRATUM STATUS: J3 consideration in progress QUESTION: Is the following conforming if C_CHAR is not the same as default character kind: interface subroutine sub(string) bind(c) character(c_char) :: string(*) end subroutine end interface character(kind=c_char,len=10) :: string call sub(string) The second and 3rd paras of 12.4.1.2 do not treat C character kind the same as default character kind, and seem to require matching types between the actual and dummy. This makes Note 15.23 nonconforming if C_CHAR is not the same as default character kind, and is also not in sync with 270:25-26. ANSWER: Yes, this is conforming, the omission in 12.4.1.2 is accidental. EDITS: In the second and 3rd paras of 12.4.1.2, replace "of type default character" with "of type default character, of type character with the C character kind (15.1)," SUBMITTED BY: Aleksandar Donev HISTORY: 06-105 m175 F03/0074 Submitted ---------------------------------------------------------------------- NUMBER: F03/0075 TITLE: C interop of derived types with array components KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: ERRATUM STATUS: J3 consideration in progress QUESTION: Is the following C struct: typedef struct { float x[5]; } array interoperable with this Fortran type: type, bind(c) :: array real(c_float) :: x(3) end type ANSWER: The intended answer is no. According to the current words in 15.2.3, the answer is yes, since only interoperability of the types of the C and Fortran components is required. This is however an accidental omission and array components have not been integrated correctly. EDITS: Append to the end of C1505 a new sentence: "If the component is an array, the corresponding C component shall be an array and the shapes of the two arrays shall be as prescribed in 15.2.5." SUBMITTED BY: Aleksandar Donev HISTORY: 06-106 m175 F03/0075 Submitted ---------------------------------------------------------------------- NUMBER: F03/0076 TITLE: Scope of Fortran names of procedures with binding labels KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Is the following conforming: module A interface subroutine CProc() bind(C,name="AnExternalCProcedure") end subroutine end interface end module module B interface subroutine CSub() bind(C,name="AnExternalCProcedure") end subroutine end interface end module ANSWER: The standard's current wording is such that this is not conforming. The name of an external procedure is a global entity and it is unique to a given procedure. That is, the external C procedure AnExternalCProcedure, must be given a unique Fortran name inside a Fortran program. However, the question is whether this was intended or whether it happened by virtue of improper integration of binding labels (which should be global entities, rather than the Fortran name) with the existing words for Fortran external procedures (which have only one name, the Fortran name, and therefore it should be global). Forbidding examples like tone one above violate basic principles of modularity and introduce global entities without justification. The Fortran names given to the external C procedure AnExternalCProcedure should be local to the scopes of modules A and B respectively, not of global scope. Correcting this problem may be done in the next revision of the standard, if it is deemed that the answer to this Interp ought to be yes. EDITS: SUBMITTED BY: Aleksandar Donev HISTORY: 06-107 m175 F03/0076 Submitted ---------------------------------------------------------------------- NUMBER: F03/0077 TITLE: LBOUND of array structure component KEYWORDS: LBOUND, lower bounds, bounds, structure component, array sections DEFECT TYPE: ERRATUM STATUS: J3 consideration in progress QUESTION: What is the result of this program: PROGRAM TYPE :: t REAL :: x END TYPE TYPE(t) :: y(-5:5) WRITE(*,*) LBOUND(y%x), LBOUND(y(3:5)%x) END PROGRAM ANSWER: Option 1) The program prints "1 1" Option 2) The program prints "-5 1" Note: There are compilers on both side of the spectrum, though it seems the majority print "1 1". I believe the intended answer is "1 1". Discussion: The definition of LBOUND: "If ARRAY is a whole array or array structure component and either ARRAY is an assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, LBOUND (ARRAY, DIM) has a value equal to the lower bound for subscript DIM of ARRAY. Otherwise the result value is 1." uses the phrase "array structure component", which can be read as "structure component that is an array" (which y%x and y(3:5)%x are), or "array component of a structure" (which neither y%x and y(3:5)%x are). The first reading says that the answer is equal to the lower bound of y%x, but the standard does not actually specify what the lower bounds of array sections are (since they cannot be subscripted). The second reading says that the answer is "1 1", and I believe it is the intended one. EDITS: Either: 1) Modify the words for LBOUND to say something alike "array component of a scalar of derived type" instead of "array structure component", or 2) Make an array component of a scalar of derived type be a "whole array" (this may have other consequences, but seems more intuitive than just tweaking the definition of LBOUND). Possibly also rewrite NOTE 6.6 to make it explicitly clear that something can be both a component and a section (assuming this is the intention), for example, add the sentence: "Some forms of are both a structure component and an array section." SUBMITTED BY: Aleksandar Donev HISTORY: 06-118 m175 F03/0077 Submitted ---------------------------------------------------------------------- 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/0079 TITLE: Value of decimal exponent for a real zero value KEYWORDS: Data edit descriptors, Numeric editing, decimal exponent, zero value DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: In formatted output, what is the value of the decimal exponent produced for a real zero value under the D, E, EN, ES, and G edit descriptors? ANSWER: In such a case, the decimal exponent should have the value zero whether or not a nonzero scale factor is in effect. Edits are supplied to make this clear. DISCUSSION: The Fortran 2003 standard does not specify what the value of the decimal exponent of a real zero value should be under formatted output. Every implementation of which Sun is aware uses the value zero for the decimal exponent unless a nonzero scale factor is in effect. Different implementations format real zeros differently under nonzero scale factors, but the difference is mainly in the form of the mantissa and not the exponent. EDITS: [227:15+] At the end of the numbered list in 10.6.1 "Numeric editing", add: "(7) On output of a real zero value, the digits in the exponent field shall all be zero, whether or not a nonzero scale factor is in effect." SUBMITTED BY: Michael Ingrassia HISTORY: 06-125 m175 F03/0079 Submitted 07-281r2 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0080 TITLE: Formatted output of a negative real zero value KEYWORDS: formatted output, negative zero, IEEE DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Suppose a Fortran processor's representation of the real zero value is signed. When a negative real zero value is written using formatted output, does the Fortran 2003 standard require the representation of the zero value in the output field to be prefixed with a minus sign? ANSWER: Yes, the negative sign is required to appear in formatted output of a negative zero value. In subclause 10.6.1, list item (3) at [227:3-4] says "The representation of a negative internal value in the field shall be prefixed with a minus sign." For a processor that distinguishes between positive and negative zero, there is no exemption for output at [38:1-6]. For the case of IEEE reals, the IEEE_IS_NEGATIVE function at [375:25] explicitly says that -0.0 is "negative". EDITS: none. SUBMITTED BY: Michael Ingrassia HISTORY: 06-126 m175 F03/0080 Submitted 07-282r1 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0081 TITLE: F edit descriptor with field width 0 KEYWORDS: Data edit descriptors, F edit descriptor, field width DEFECT TYPE: Clarification STATUS: J3 consideration in progress QUESTION: Does the Fortran 2003 standard allow the output field produced by an F edit descriptor with a field width w whose value is zero for a real value whose magnitude is less than one to include an optional leading zero? For example, is the PRINT statement PRINT '(F0.2)', 0.01 allowed to write "0.01"? ANSWER: No. This is clear from Section 10.6.1 of the Fortran 2003 standard, item (6). DISCUSSION: This question came from a customer. Many implementations, including Sun's, include the optional leading zero. EDITS: None required. SUBMITTED BY: Michael Ingrassia HISTORY: 06-127 m175 F03/0081 Submitted ---------------------------------------------------------------------- NUMBER: F03/0082 TITLE: VALUE in place of INTENT for pure procedure dummy arguments KEYWORDS: VALUE, INTENT, PURE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: C1266 requires all nonpointer dummy arguments of a pure function to be data objects that have INTENT(IN). C1267 requires all dummy arguments of a pure subroutine to have specified intents. Was it intended that VALUE not be allowed in place of INTENT(IN), that is, was it intended that if a dummy argument of a pure procedure has the VALUE attribute, it is nonetheless also required to have the INTENT(IN) attribute explicitly specified? ANSWER: It was an oversight that VALUE is not allowed to stand on its own. EDITS: All edits refer to 04-007. [286:12] at the end of C1266, add "or the VALUE attribute". [286:13-14] Replace C1277: C1267 Within the of a pure subroutine subprogram, for each non-pointer dummy data object, either its intent shall be explicitly specified or it shall have the VALUE attribute. SUBMITTED BY: Van Snyder HISTORY: 06-153 m176 F03/0082 Submitted, fix edit, needs more ---------------------------------------------------------------------- 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 Submitted F03/0084 ---------------------------------------------------------------------- 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 Submitted F03/0085 ---------------------------------------------------------------------- NUMBER: F03/0086 TITLE: Elemental and BIND(C) KEYWORDS: Elemental, BIND(C), ENTRY DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is it allowed for a procedure to have both the BIND(C) and elemental attributes? Constraint C1242 disallows trivial ways of writing an elemental BIND(C) procedure. However, the following example achieves the effect for sub_c without violating the syntactic constraint. elemental subroutine sub(x) entry sub_c(x) bind(c) end subroutine sub ANSWER: No, it is not allowed. Constraint C1242 was intended to disallow the combination of elemental and BIND(C), but it inadvertently failed to cover the case shown in the above example. EDITS Replace C1242 in subclause 12.5.2.1 with [280:6-7] "C1242 An ELEMENTAL procedure shall not have the BIND attribute.". SUBMITTED BY: Richard Maine HISTORY: 07-101 m179 Submitted F03/0086 07-101 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0087 TITLE: Entry names as dummy procedure arguments KEYWORDS: Entry names, dummy procedure arguments DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Does the following subprogram fragment conflict with the 2003 Fortran standard? If so, was the conflict intended? entry A ( X ) interface subroutine X ( A ) abstract interface subroutine I ( ... ) ... end subroutine I end interface procedure (I) A end subroutine X end interface ... It seems that constraint C1255 in subclause 12.5.2.4 [283:10-12] prohibits the entry name A to appear in the PROCEDURE statement in the interface body. There shouldn't be a problem, however, since the PROCEDURE statement is in a different scoping unit. REMARK: There is no constraint parallel to C1255 concerning the in a SUBROUTINE statement, and only an indirect one (C1235 in subclause 12.5.2.1 [279:24-25]) concerning the in a FUNCTION statement, and only then if the FUNCTION statement has a RESULT clause. Subclauses 16.1 and 16.2 adequately cover the problems that constraint C1255 appears to have been intended to cover. ANSWER: It was not intended that this usage be prohibited. An edit is provided to remove the prohibition. EDITS: Within constraint C1255 in subclause 12.5.2.4, insert "the scoping unit of" after "Within". SUBMITTED BY: Van Snyder HISTORY: 07-105 m179 Submitted F03/0087 07-105 m179 Passed by J3 meeting 07-250r1/272 m181 Failed J3 letter ballot #13 Bill Long's YES comment on F03/0087: It would be helpful to include a reference for the edit: [283:10]. While we're fixing this constraint, we might as well fix the end of the sentence as well. The end is "nor shall appear in an EXTERNAL, INTRINSIC, or PROCEDURE statement". PROCEDURE statements, [258:27], appear only in interface blocks, and are not similar to EXTERNAL or INTRINSIC. I suspect we really meant procedure declaration statements [264:9]. ---------------------------------------------------------------------- NUMBER: F03/0088 TITLE: Defined operations/assignments and VOLATILE/ASYNCHRONOUS KEYWORDS: Defined operations, defined assignment, VOLATILE, ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot PROBLEM: Fortran 2008 Unresolved Technical issue 097 asked a question that also affects Fortran 2003. Consider this example: INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(1,*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:,:),q(:) ... CALL s(p,q) ! Violation of constraint C1233 [271:9-11], ! associating P with A p = q ! No constraint violation because ! syntax is not being used QUESTION: Did Fortran 2003 intend to enforce constraints on in defined assignment? ANSWER: Yes, the constraints and restrictions should be enforced in defined assignment and in defined operator evaluation. Edits are provided below to do this. EDITS: [262:16] add at the end of the paragraph "All restrictions and constraints that apply to actual arguments in a reference to the function also apply to the corresponding operands in the expression as if they were used as actual arguments." [263:12] insert after "the second argument." "All restrictions and constraints that apply to actual arguments in a reference to the subroutine also apply to the left-hand-side and to the right-hand-side enclosed in parentheses as if they were used as actual arguments." SUBMITTED BY: Stan Whitlock HISTORY: 07-172 m179 Submitted F03/0088 {see 07-171 for F08 fix} 07-172 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0089 TITLE: Interoperability of non-BIND derived types KEYWORDS: Interoperability, derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot INTRODUCTION Subclause 15.2.3 of 04-007 says [398:9-12]: "A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran type specifies BIND(C) (4.5.1), the Fortran derived type and the C struct type have the same number of components, and the components of the Fortran derived type have types and type parameters that are interoperable with the types of the corresponding components of the struct type." QUESTIONS 1. Is a Fortran derived type for which BIND(C) is not specified interoperable with any C struct type? 2. Does a Fortran derived type interoperate with a C struct type that has a different number of components? 3. Does a Fortran derived type interoperate with a C struct type that specifies the same components in a different order? 4. Does a Fortran derived type with a pointer or allocatable component that has interoperable type and type parameters interoperate with any C struct type? ANSWERS: None of these Fortran derived types are interoperable with any C struct type. EDITS: [398:9] Replace "if" by "if and only if". SUBMITTED BY: Van Snyder HISTORY: 07-213 m180 Submitted F03/0089 07-213r2 m180 Passed by J3 meeting 07-272 m181 Passed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0090 TITLE: Polymorphic array constructors KEYWORDS: polymorphic, array constructor DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 Submitted F03/0090 (revised by Malcolm Cohen) 07-231 m180 Passed by J3 meeting 07-250r1/272 m181 Failed J3 letter ballot #13 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 Submitted F03/0091 (modified by Malcolm Cohen) ---------------------------------------------------------------------- NUMBER: F03/0092 TITLE: Procedure characteristics and unlimited polymorphic KEYWORDS: Procedure, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider abstract interface function foo (x) class(*) x class(*), pointer :: foo end function end interface procedure (foo), pointer :: proc_ptr procedure (foo), target :: proc_tgt proc_ptr => proc_tgt According to the rules of procedure pointer assignment at [144:39-41], proc_ptr and proc_tgt are required to have the same interface characteristics. However because an unlimited polymorphic entity is not considered to have a declared type, the rules for characteristics of dummy data objects [256:26-32] and characteristics of function results [257:2-8] are not applicable. In addition, rules at [145:5-6] require that proc_ptr and proc_tgt have the same function return type. This also does not apply to unlimited polymorphic data. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to clarify this. The characteristics however are adequately defined. FOO, and thus both PROC_PTR and PROC_TGT have no type, but are polymorphic; this precisely characterises an unlimited polymorphic entity. Only the requirement of type matching in 7.4.2.2 is incorrect. EDITS to 04-007: [145:5] After "the same type" insert " or both be unlimited polymorphic". SUBMITTED BY: Jim Xia HISTORY: 07-247 m181 F03/0092 Submitted 07-247r1 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0093 TITLE: Allocatable array on intrinsic assignment with scalar expr KEYWORDS: allocatable array, intrinsic assignment DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER(:), ALLOCATABLE :: str(:) ALLOCATE (CHARACTER(1) :: str(0:9)) str = 'reallocate?' According to the third paragraph of 7.4.1.3, the variable STR should be deallocated on this assignment because it has a deferred length type parameter different from the ('reallocate?'); it should then be allocated with its length type parameter the same as that of the and with the shape and bounds of . But the STR cannot be allocated with the shape and bounds of the since it is a scalar. The standard, however, provides a possible interpretation for the shape of two paragraphs later where it says "If is a scalar and is an array, the is treated as if it were an array of the same shape as with every element of the array equal to the scalar value of ." Q(1). Should the variable STR be reallocated in this case? Q(2). If so, what are the values of its length type parameter, shape and bounds? ANSWER: (1) Yes, STR should be reallocated - that is the purpose of the combination of ALLOCATABLE and deferred type parameters. If the user does not wish for automatic reallocation he can use "str(:) = 'do not reallocate'" instead. (2) The length parameter of str after the assignment is 11 (the value returned by LEN('reallocate?')). The shape and bounds should be unchanged. An edit is provided to clarify this. Note that the standard does not forbid, but does not specify semantics for, str = 'oops' when STR is an unallocated array with a deferred length parameter. An edit is supplied to make it clear that this is not allowed. Note also that this applies to parameterized derived types with deferred type parameters. EDITS: [139:22-] Insert new sentence at beginning of paragraph "If is an unallocated allocatable array, shall be an array of the same rank as ." [139:25] Change "corresponding type parameters of ," to "corresponding type parameter of ." [139:25] Before ", with the shape of " Insert ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". SUBMITTED BY: Jim Xia HISTORY: 07-248 m181 F03/0093 Submitted 07-248r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0094 TITLE: Final subroutine and VALUE attribute KEYWORDS: Final subroutine, VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Currently, the F03 standard allows the VALUE attribute to be specified for the dummy argument of a final subroutine. This seems to defeat the purpose of final subroutine, which is intended to apply to the finalizable entity (the actual argument) itself. Should the dummy argument of a final subroutine be allowed to have the VALUE attribute? ANSWER: No, the VALUE attribute should not be allowed. An edit is provided to correct this oversight. EDITS to 04-007: [58:14] Replace "not be INTENT(OUT)" with "not have the INTENT(OUT) or VALUE attribute". SUBMITTED BY: Jim Xia HISTORY: 07-249 m181 F03/0094 Submitted 07-249r1 m181 Passed by J3 meeting 07-279/321 m182 Passed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0095 TITLE: Bounds remapped pointer assignment and ASSOCIATED KEYWORDS: pointer assignment, bounds-remapping, ASSOCIATED DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Case (v) of intrinsic inquiry function ASSOCIATED [305:5-9] says If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise, the result is false. If POINTER is disassociated, the result is false. This will cause the intrinsic to return false if the POINTER is pointer assigned to the TARGET with bounds-remapping (POINTER and TARGET can be of different ranks). The same issue also exists for case (vii). Is the POINTER associated with the TARGET if the POINTER is pointer assigned to the TARGET with bounds-remapping? ANSWER: No, it is not intended that ASSOCIATED(POINTER, TARGET) return true after pointer assignment using a bounds-remapping that changes the shape or rank. This was a conscious decision made in response to a Fortran 90 interpretation request concerning dummy arguments that are different shaped versions of the same array in the calling procedure. EDITS to 04-007: none SUBMITTED BY: Jim Xia HISTORY: 07-259 m181 F03/0095 Submitted 07-259r2 m181 Passed by J3 meeting 07-279/321 m182 Passed by J3 letter ballot #14 ---------------------------------------------------------------------- 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 Submitted F03/0096 07-266r1 m181 Draft answer ---------------------------------------------------------------------- NUMBER: F03/0097 TITLE: Blanks as separators in NAMELIST input KEYWORDS: Namelist input, blanks, separators DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1) Was it intended that blanks be allowed as separators in Namelist Input? Consider a namelist input fragment: I = 3 J = 4 Page 243:12 says that the name-value subsequences are separated by value separators. Page 243:5 says that namelist value separators are the same as list directed value separators. Page 239:7 says those value separators are "...blanks between values" and then defines what the values are. The "J" above isn't a value, so the blanks aren't separators and the fragment is illegal for namelist input 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment Page 245:29-30 says that a name-value subsequence is separated from the ! in a comment by a value separator. ANSWER: 1) Yes, it was intended to allow blanks as separators for namelist input. Edits are supplied to correct the wording in the standard. 2) Yes, there is a similar problem with comments. The fragment is intended to be legal. The edits correct the error. EDITS: [243:5] Replace the paragraph by "A value separator for namelist formatting is a value separator for list-directed formatting (10.9), or one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator." SUBMITTED BY: Dick Hendrickson HISTORY: 07-267 m181 F03/0097 Submitted 07-267r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that an allocate with a source= clause define subcomponents? Bullet 11 on 422 says "Successful execution of an ALLOCATE statement ...causes the subcomponent to become undefined." ANSWER: An Allocate with a SOURCE= specifier was intended to define subcomponents. In fact, none of the lists in clause 16 account for a SOURCE= specifier. Edits are supplied to clarify this. EDITS: [113:21] At the end of the last sentence in 6.3.1.1 insert "unless they are defined by a SOURCE= specifier" [421:27-28] 16.5.5, list item 19, modify by adding after "Allocation of an object", "except by an ALLOCATE statement with a SOURCE= specifier". [421:28+] 16.5.5, insert new list item after (19) "(19a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become defined if the corresponding subobject of the SOURCE= expression is defined." [422:41] 16.5.6, list item (11) insert "with no SOURCE= specifier" after "ALLOCATE statement" [422:43+] 16.5.6, add a new list item after (11), "(11a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become undefined if the corresponding subobject of the SOURCE= expression is undefined." SUBMITTED BY: Dick Hendrickson HISTORY: 07-268 m181 F03/0098 Submitted 07-268r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0099 TITLE: Clause 16 does not account for volatile variable KEYWORDS: volatile, defined, undefined DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Should the various lists in clause 16 that describe definition and association be modified to include the effects of volatile variables? In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact that pointer association status can be volatile and change by other means. 16.5.4 says "all other variables are initially undefined.? Can a volatile variable be initially defined by other means? 16.5 (26) says volatile variables "become defined", but they also can become undefined, by other means. Allocatable volatile variables can become allocated or unallocated by other means also. ANSWER: Yes, the lists in clause 16 should be modified to include the effects of volatility. In addition, the effects of volatile on pointer objects are not completely specified in clause 5. The effect on allocatable objects is not complete in clause 6. EDITS: [85:10] In the paragraph between note 5.21 and note 5.22, change "association status and array bounds" to "association status, dynamic type and type parameters, and array bounds" [415:27] Add a new paragraph at the end of 16.4.2.1.4 "The association status of a pointer object with the VOLATILE attribute may change by means not specified by the program. If the association status of such an object changes, its array bounds or deferred type parameters may change. If in addition it is polymorphic, its dynamic type and additional type parameters not specified in its declaration may also change." [421:42-43] In 16.5.5 Replace list item (26) with (as text, not a list item) "In addition, an object with the VOLATILE attribute (5.1.2.16) might become defined by means not specified by the program." [423:28+] In 16.5.6 after the last list item insert (as text, not a list item) "In addition, an object with the VOLATILE attribute (5.1.2.16) might become undefined by means not specified by the program." SUBMITTED BY: Dick Hendrickson HISTORY: 07-269 m181 F03/0099 Submitted 07-269r2 m181 Passed by J3 meeting 07-279/321 m182 Failed letter ballot #14 07-339 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 less than the mimimum required but large enough to produce the form "Inf" then the form "Inf" is output.' [229:2] In the last sentence of the paragraph in 10.6.1.2.1 "F editing" covering the output of NaN values, replace "If is less than 3" with "If is greater than zero and less than 3". SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 Submitted 07-271r2 m181 Passed by J3 meeting 07-279/321 m182 Failed letter ballot #14 07-340r1 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0101 TITLE: Is UDDTIO output suitable for namelist and list-directed input KEYWORDS:UDDTIO, list-directed I/O, namelist I/O DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The first paragraph of 10.9.2 says that the form of the values produced by list-directed output is the same as that required for input. It also says values are separated blanks or commas, etc. The first paragraph of 10.10.2 has similar words for namelist output. It also requires that the variable name be produced in upper case and that the output consist of name-value pairs. Is it intended that output produced by user-defined derived type routines conform to these rules? ANSWER: No, it was not intended to constrain the user-derived type output values. There should be an exception similar to the one for adjacent undelimited character values. User derived type output fields do not need to be readable by either namelist or list-directed input. EDITS: [241:5] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during list-directed output is specified by the invoked routine. It need not be compatible with list-directed input." [246:4] After "and logical values" add ", and output produced by user-defined derived type output" [246:7] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during namelist output is specified by the invoked routine. It need not be compatible with namelist input." SUBMITTED BY: Dick Hendrickson HISTORY: 07-275 m181 F03/0101 Submitted 07-275r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0102 TITLE: Evaluation of bound-expr in data pointer assignment KEYWORDS: pointer, pointer assignment, bounds, expression DEFECT TYPE: Erratum STATUS: Passed by J3 meeting DISCUSSION: Currently there are no rules in 7.4.2.1 to prohibit changing of a pointer's association status during evaluation of bound expressions in a data pointer assignment (pointer with either bounds-spec or bounds-remapping specified). This may lead to ambiguous code with regard to the evaluation orders between the bound expression and the data pointer assignment itself. Consider the following code, integer, target :: tar2(100, 100) integer, target :: tar1(100) integer, pointer :: ptr(:,:) ptr(-2:, f1(ptr, tar1, 1, 1):) => tar2 print*, lbound(ptr) print*, ubound(ptr) print*, size(ptr) contains function f1(ptr, arr, i, j) integer :: i, j, f1 integer, pointer :: ptr(:, :) integer, target :: arr(:) ptr (i:j, i:j) => arr f1 = -1 end function end In 7.4.1.3 for interpretation of intrinsic assignments, there are rules explicitly requesting evaluation of all expressions in variable occurred before the variable is defined [139:14-19]. It appears that data pointer assignment should also follow similar rules. Note the similar problem also exists for evaluating the if it references a function that returns a data pointer. QUESTION: (a) Is this program intended to be standard conforming? (b) If it is standard conforming, then what would it print? ANSWER: (a) No, this program is not intended to be standard conforming. Edits are provided to clarify this. EDITS: [04-007:128:6] After "undefinition" insert ", or changes the pointer association status or allocation status," SUBMITTED BY: Jim Xia HISTORY: 07-297r1 m182 F03/0102 Submitted 07-297r2 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0103 TITLE: Restrictions on dummy arguments not present for polymorphic type or parameterized derived type KEYWORDS: dummy argument, present, polymorphic, parameterized derived type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0104 TITLE: Deallocation and finalization of bounds-remapped pointers KEYWORDS: deallocate, finalization, bounds-remapping, pointer DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting INTRODUCTION: Consider the following example assuming a derived type of X is declared previously and made accessible to the current scoping unit, type(X), pointer :: a(:), b(:,:) allocate (a(100)) b(1:10, 1:10) => a DEALLOCATE (b) QUESTION: (a) Is DEALLOCATE (b) in the example intended to be standard conforming? (b) If the answer to (a) is yes, and also assume type X has finalizers of both rank-one and rank-two, then which finalizer should be invoked by the DEALLOCATE statement. ANSWER: (a) Yes, the example is intended to be standard conforming. The deallocation of pointer b should be executed successfully. (b) Standard is clear about how the finalizations processed in this case. In 4.5.5.1, the first step in invoking the appropriate final subroutine requires a finalizer matching the rank of the entity being finalized. In this case, object b is being finalized and therefore the rank-two final subroutine of type X will be invoked with object b as the actual argument. EDITS: None. SUBMITTED BY: Jim Xia HISTORY: 07-299 m182 F03/0104 Submitted; Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0106 TITLE: Inquire by unit inconsistencies KEYWORDS: inquire, unit, not connected DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: There are many things that can be inquired about, such as ACTION or READ, that are purely file or connection properties. In some cases, such as ACTION, the specifier description includes "If there is no connection [the result is] the value UNDEFINED" or similar words. In other cases, such as READ, there seems to be a tacit assumption that there is a file connected to the unit. The descriptions refer to "the file" and don't specify a result if there is no connection. In most cases, there is a phrase like "if the processor is unable to determine if the file ... [the result is] {UNDEFINED, UNKNOWN, -1, etc.}". Question 1) Are the inquire specifiers DIRECT, ENCODING, FORMATTED, NAMED, NEXTREC, NUMBER, POS, READ, READWRITE, SEQUENTIAL, SIZE, STREAM, UNFORMATTED, and WRITE allowed in an INQUIRE by unit when there is no file connected to the unit? Question 2) If so, should the descriptions for the above specifiers be clarified by adding phrases such as "if there is no file specified or connected" to the "UNKNOWN" result descriptions? ANSWER: Question 1) Yes. In an inquiry by unit, the specifiers have little meaning when there is no file connected to the unit. However, the standard should specify the results. Question 2) Yes, edits are supplied below. Note: 9.9.1.15 NAMED= [213:10] needs no edit; the value will be false if the unit specified by UNIT= is not connected to a file EDITS: 9.9.1.8 DIRECT= At [212:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.9 ENCODING= At [212:21], after "file" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.12 FORMATTED= At [212:36], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.16 NEXTREC= At [213:16], after "connection" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.17 NUMBER= At [213:21+], insert "If the unit specified by UNIT= is not connected to a file, the value is the unit specified by UNIT=." 9.9.1.21 POS= At [214:20], after "conditions" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.23 READ= At [215:2], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.24 READWRITE= At [215:7], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.27 SEQUENTIAL= At [215:26], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.29 SIZE= At [215:34], after "determined" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.30 STREAM= At [216:5], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.31 UNFORMATTED= At [216:10], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.32 WRITE= At [216:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" SUBMITTED BY: Dick Hendrickson HISTORY: 07-309 m182 F03/0106 Submitted 07-309r1 m182 Answer based on 07-310; Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0107 TITLE: Are the IEEE_* elemental routines required KEYWORDS: IEEE, elemental routines DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The descriptions for all of the IEEE elemental intrinsics listed in 14.9 say something like "shall not be invoked if IEEE_SUPPORT_DATATYPE(X) is false". I believe this was to allow a careful programmer to do something like if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif and program around partial IEEE support. But 14.9.2 says that "IEEE_ARITHMETIC contains the following [routines] for which IEEE_SUPPORT_DATATYPE(X) [is] true" I'd read that as saying the functions aren't there for cases where IEEE_SUPPORT_DATATYPE is false. But, then, there is no way to program around their absence. The example above will fail at load time because IEEE_SCALB is absent. If a processor provides the IEEE_ARITHMETIC module must it provide versions of all of the intrinsics for all of the available datatypes, including those for which IEEE_SUPPORT_DATATYPE() is false? ANSWER: Yes, edits are provided to make this clear. DISCUSSION: It was intended that the above coding snippet could be used by a careful programmer to program portably for processors which have varying degrees of IEEE support. This might require processors to provide some stub function for each routine and for each non-IEEE datatype they support. If a program invokes one of the stub routines, it is a run-time programming error. Nevertheless, a program which has references to the routines, but doesn't invoke them, must load and execute. EDITS: [370:8-9] Replace "for reals X and Y for which IEEE_SUPPORT_DATATYPE(X) and IEEE_SUPPORT_DATATYPE(Y) are true" with "for all reals X and Y" Insert a note at [369:28+] "The standard requires that code such as if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif be executable. The elemental functions in the IEEE_ARITHMETIC module (14.9.2) must exist for all real kinds supported by the processor, even if IEEE_SUPPORT_DATATYPE returns false for some kinds. However, if IEEE_SUPPORT_DATATYPE returns false for a particular kind, these functions must not be invoked with arguments of that kind. This allows a careful programmer to write programs that work on processors that do not support IEEE arithmetic for all real kinds. The processor might provide stub routines which allow the program to link and execute, but which will abort if they are invoked." SUBMITTED BY: Dick Hendrickson HISTORY: 07-312 m182 F03/0107 Submitted 07-312r2 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0108 TITLE: Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions KEYWORDS: IEEE_SUPPORT_NAN, IEEE support functions DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: The restriction of IEEE_IS_NAN requires that IEEE_SUPPORT_NAN returns the value true. The restrictions for the similar functions IEEE_IS_{FINITE, NEGATIVE, and NORMAL} all require that IEEE_SUPPORT_DATATYPE be true. This is a much stronger restriction. Should IEEE_SUPPORT_NAN also require that IEEE_SUPPORT_DATATYPE return true? ANSWER: No. The IEEE_SUPPORT_NAN restriction is weaker than requiring IEEE_SUPPORT_DATATYPE but IEEE_SUPPORT_NAN is sufficient. IEEE_SUPPORT_DATATYPE is used in IEEE_IS_FINITE, IEEE_IS_NEGATIVE, and IEEE_IS_NORMAL because there are no IEEE_SUPPORT_* inquiry functions to query support for finite, negative, or normal. IEEE_SUPPORT_INF asks about infinities not finites and IEEE_SUPPORT_DENORMAL only covers denormals and not the other non-finites (NaNs and Infinities). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 07-328 m182 F03/0108 Submitted 07-328r2 m182 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0109 TITLE: Referencing deferred binding via absent dummy argument KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program program P type, abstract :: T contains procedure(sub), nopass, deferred :: deferred_proc end type T call sub contains subroutine Sub ( X ) class(t), optional :: X call x%deferred_proc end subroutine Sub end program P Is this a valid program? If not, what restriction of the standard does it violate? Since x%deferred_proc has the NOPASS attribute, this does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, the first item in the second list in 12.4.1.2 (at [04-007:272:32-33]) does not prohibit this. ANSWER: This was not intended to be a valid program. A type-bound procedure shall not be invoked through an absent dummy argument. An edit is supplied to clarify this situation. EDITS: Insert after C1224 in subclause 12.4 (at [04-007: 266: 24]) ([07-007r3: 309: 11]): "The shall not be an undefined pointer, a disassociated pointer, an unallocated allocatable variable, or a dummy data object that is not present (12.4.1.6)." (This subsumes the edits for F03/0003 and F03/0004). SUBMITTED BY: Van Snyder HISTORY: 07-338 m182 F03/0109 Submitted; Passed by J3 meeting ----------------------------------------------------------------------