ISO/IEC JTC1/SC22/WG5 N1399 Four more Fortran 95 Interpretations Ready for WG5 NUMBER: 000001 TITLE: Visibility of a data object with statement scope KEYWORDS: visibility, data object, statement scope, scope DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Part 1: Consider the following program: MODULE mod INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) END MODULE PROGRAM main USE mod INTEGER :: i DO i = 1, 10 PRINT *, 'jmin(i) = ', jmin(i) END DO END PROGRAM Some Fortran compilers consider the implied-DO variable I used in the module to be visible to program units using the module and some Fortran compilers do not consider the I to be visible to using program units. Is an entity with statement scope in the specification part of a module visible to a program unit using the module and accessing the public data of the module as exemplified by the above example? Part 2: Consider the adaptation of the example program from Part 1: MODULE mod INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) CONTAINS SUBROUTINE one i = 99 ! Is this a local or module variable? ! Compilers that export I probably say module END SUBROUTINE SUBROUTINE two PRINT *, i END SUBROUTINE END MODULE The module specification part uses the variable I as an implied-DO variable of an array constructor. Module procedure ONE sets a variable named I to a value. Given: * An implicitly declared data object in the module specification part where the variable has statement scope, and * An implicitly declared variable in a module procedure where the variable has the same name as the variable described in the first bullet of this list is the variable in the module procedure a module variable (known to the entire module and thus available outside the module) or is the variable local to the module procedure? ANSWER: The implied-DO variable is not visible to the using program. 14.1.3 Statement Entities states, in part, that The name of a variable that appears as the DO variable of an implied-DO in a DATA statement or an array constructor has a scope of the implied-DO list. It has the type and type parameter that it would have if it were the name of a variable in the scoping unit that includes the DATA statement or array constructor and this type must be integer. The words "would have if it were" were intended to convey the idea that the existence of an array constructor or data implied-DO variable does not actually cause an associated variable in the scoping unit to come into existence. Also, the following text appears in the same section (281:12-14): If the name of a global or local entity accessible in the scoping unit of a statement is the same as the name of a statement entity in that statement, the name is interpreted within the scope of the statement entity as that of the statement entity. The word "If" here implies that there need not be any such global or local entity with the same name as that of the statement entity. The first edit makes this clear. The second edit makes the same point for FORALL statements and constructs. EDITS: Page 280, Clause 14.1.3, at the end of the first paragragh (280:44) add: The appearance of a name as the DO variable of an implied-DO in a DATA statement or an array constructor is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement. Page 281, Clause 14.1.3, at the end of the second paragraph [281:4] add: The appearance of a name as an index-name in a FORALL statement or FORALL construct is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement or construct. SUBMITTED BY: Larry Rolison HISTORY: 97-237 m143 submitted 00-158 m153 passed unanimously 00-Aug m153 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000003 TITLE: Ability to overload the character operator // KEYWORDS: overload, intrinsic, // DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: On page 89 of the Fortran 95 standard, the Note at the bottom of Table 7.1 states in part: For the intrinsic operators REQUIRING {emphasis not in standard} operands of type character, the kind type parameters of the operands shall be the same. Since there is only one intrinsic operator (//) that REQUIRES its operands to be of type character, one may conclude that the operands of the // operator MUST be of type character and MUST have the same kind type parameters. The last sentence of the first full paragraph on page 90 restates the above rule for intrinsic uses of // as follows: For the character intrinsic operator //, the kind type parameters shall be the same. Contrast this with the last sentence of the last paragraph of this section: A {character relational intrinsic operation} is a relational intrinsic operation where the operands are of type character and have the same kind type parameter value. >From the wording of this last sentence, one may conclude that if the kind type parameters are the same, then the relational operation is intrinsic but if the kind type parameters are NOT the same, then the relational operation is NOT intrinsic and must be defined via a user-provided function. Thus, it is possible for the character operands of a relational operator to have differing kind type parameter values. Now compare this to the following sentence from 7.1.4.2: For an expression // where and are of type character, the character length parameter is the sum of the lengths of the operands and the kind type parameter is the kind type parameter of , which shall be the same as the kind type parameter of . Note that there is no text or title to indicate that the description is only for intrinsic operators. There appears to be no way to overload the // symbol at all since the wording does not restrict the rule to the intrinsic interpretation of the operator (it appears in fact from the wording that once the operands are of type character, there can be no other interpretation other than intrinsic). This is surely not what was intended. The wording should be redone to more closely resemble that for the character relational operators such that if the operands of // do not have the same kind type parameters, an overload is allowed (and the operator is not interpreted as being intrinsic). (See also 7.2.2 Character intrinsic operation.) ANSWER: Intrinsic concatenation is defined only for character operands with the same kind type parameter value. This is stated clearly (90: 8-9): 'For the character intrinsic operator //, the kind type parameters shall be the same'. There is a need for a similar restriction at this point for relational intrinsic operators with character operands. The words at the end of the next paragraph (90: 12) actually suggest that there are relational intrinsic operations for character operands of different kind type parameter values that are not character relational intrinsic operations. The word 'requiring' in the last sentence in the note in Table 7.1 should be changed since all the intrinsic operators with character operands require their operands to have the same kind type parameter value. EDITS: Page 89, Table 7.1, penultimate line (89:38). Change 'requiring' to 'with'. Page 90, line 9. Add 'For the relational intrinsic operators with character operands, the kind type parameters shall be the same'. Page 90, line 12. Delete 'and have the same kind type parameter value'. SUBMITTED BY: Larry Rolison HISTORY: 97-239 m143 submitted 00-159 m153 passed unanimously 00-Aug m153 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: The SELECTED_REAL_KIND intrinsic function does not appear to cover one specific case for real data types. Consider the following precisions and ranges for a particular model: KIND TYPE PRECISION RANGE 4 6 37 8 15 307 16 31 291 A test case for a system with this model is: PRINT *, 'selrealkind(31,291) = ', SELECTED_REAL_KIND(P=31,R=291) PRINT *, 'selrealkind(31,292) = ', SELECTED_REAL_KIND(P=31,R=292) PRINT *, 'selrealkind(32,291) = ', SELECTED_REAL_KIND(P=32,R=291) PRINT *, 'selrealkind(32,292) = ', SELECTED_REAL_KIND(P=32,R=292) END The Result Value section of the description of SELECTED_REAL_KIND clearly describes the result value when the values of P and R are within the ranges specified for the given implementation of the real data type model. It further describes the values to be returned by SELECTED_REAL_KIND when a value of P or R is not within the range of model numbers specified by the implementation. From the text in the Result Value section, the following may be determined: * The reference to SELECTED_REAL_KIND(P=31,R=291) (first PRINT line) should return the (kind type parameter) value 16. * The third and fourth SELECTED_REAL_KIND references should return -1 since the PRECISION argument is outside the set of allowed precision values. However, the value returned by the second reference to SELECTED_REAL_KIND is unknown since it does not appear to be covered by the wording of the Result Value paragraph of section 13.14.95. 1. What should the processor return for the value of the SELECTED_REAL_KIND intrinsic function when it does not have a single data type that satisfies both the P and R values? 2. In particular, given the precision and range values shown above, what should the processor return for the last three invocations of the SELECTED_REAL_KIND intrinsic function? ANSWER: The intention is that the value -1 be returned if the range can be supported but the precision cannot, the value -2 be returned if the precision can be supported but the range cannot, and the value -3 be returned if neither the precision nor the range can be supported. Provision needs to be made for the case where each can be supported, but not in combination. With the edit below, the returned values for the four invocations will be 16, -4, -1, -1. In addition, using the model above, these test cases: PRINT *, 'selrealkind(32) = ', SELECTED_REAL_KIND(P=32) PRINT *, 'selrealkind(r=308) = ', SELECTED_REAL_KIND(R=308) the returned values for the two invocations will be -1, -2. EDITS: Page 266, Clause 13.14.95, line 8 (266: 23). After , add 'If P or R is absent, the result value is as would have been obtained with the argument present with the value 0.' Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together.' SUBMITTED BY: Larry Rolison / Joanne Brixius HISTORY: 97-241 m143 submitted 00-161 m153 Passed unanimously as amended 00-Aug m153 Passed by J3 letter ballot as amended ---------------------------------------------------------------------- NUMBER: 000012 TITLE: Evaluation of Intrinsic Procedures KEYWORDS: Algorithm, Mathematical, Computational DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: 1. When the standard specifies an algorithm for computing a mathematical procedure, must a processor use the specified algorithm? Example: ANINT is defined as INT (A + 0.5). On some processors ANINT (16 000 001.0) evaluates to 16 000 002.0 using this algorithm. 2. May a processor return a mathematically equivalent result in the evaluation of a numeric intrinsic procedure? Example: If ANINT (16 000 001.0) can be computed as the more expected 16 000 001.0, may a processor do so? ANSWER: 1. No, a processor is not required to use the algorithm from the standard. 2. Yes, a processor may return the mathematically equivalent result in the evaluation of any numeric intrinsic procedure. DISCUSSION: The use of an algorithm in the definitions for intrinsic procedures is intended to describe the end result. It is not intended to require that a processor use a particular method of achieving that result. Thus, an algorithm specifies the mathematical results, not the computational results, of the evaluation of intrinsic procedures. This standard does not require a processor to use a particular accuracy or precision. Section 1.4, "Exclusions", states in part: "This standard does not specify: . . . (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." [1:26, 1:37-38] EDITS: None. SUBMITTED BY: Keith H. Bierman HISTORY: 95-247r1 m134 Submitted as F90 interp 000202 with proposed response, approved 9-4, subsumes F90 interp 000200. 95-256 m134 Ballot failed, 10-6 95-260 m135 Proposed response, no action 96-023 m136 Proposed response, no action 96-054 m137 Proposed response, no action 96-117 m138 Proposed response, no action 97-259r1 m143 Re-submitted as F95 interp 000012 with proposed response 00-214 m153 Passed unanimously 00-Aug m153 Passed by J3 letter ballot