J3/00-202 Date: 19-Apr-2000 To: J3 Members From: Interp/Stan Whitlock Subj: F95 Interp letter ballot #1 (email x3j3.2000-136) due 19-May-2000 Enclosed in the first letter ballot on Fortran 95 interpretations. The rules we operate on say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o 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 a J3 letter ballot is equivalent to missing a J3 meeting, with subsequent negative effects on 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. 14 Fortran 95 interpretations have been passed at J3 meetings #150, #151, and #152. This is the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000066 Errors in processing data transfer statements --- --- 000067 Writing zeros --- --- 000068 Asterisks as I/O units --- --- 000069 What is a numeric character? --- --- 000070 Asymmetry between constant specification and initialization expressions --- --- 000071 Character array constructors --- --- 000072 Resolving generic procedure references --- --- 000076 INTENT(IN) dummy arguments and implied DO loops --- --- 000077 INTENT(IN) dummy arguments and NULLIFY --- --- 000079 Pointer Assignment and Allocatable Arrays --- --- 000080 Host association and the EXTERNAL attribute --- --- 000082 Usage of BOZ literal constants --- --- 000083 Scope of array-constructor implied-DO variable --- --- 000084 Events that cause variables to be defined The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above "yes" or "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to x3j3@ncsa.uiuc.edu by Midnight, PDT, Friday, 19-May-2000, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: 000066 TITLE: Errors in processing data transfer statements KEYWORDS: ERR=; IOSTAT=; Data transfer statements DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider the following program. INTEGER :: A(10), IDX, J OPEN(10, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', STATUS='OLD', & & ACTION='READ') READ(10, IOSTAT=IOS) IDX, J, A(IDX) END If an error occurs while processing the variable J in the data transfer statement, does this program become non-standard conforming? According to 9.4.3: "If an error condition or an end-of-file condition occurs during execution of an input/output statement, execution of the input/output statement terminates and if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined. If an error condition occurs during execution of an input/output statement, the position of the file becomes indeterminate. If an error or end-of-file condition occurs on input, all input list items become undefined." According to 9.4.4: "The effect of executing a data transfer input/output statement shall be as if the following operations were performed in the order specified: (1) Determine the direction of data transfer (2) Identify the unit (3) Establish the format if one is specified (4) Position the file prior to data transfer (9.2.1.3.2) (5) Transfer data between the file and the entities specified by the input/output list (if any) or namelist (6) Determine whether an error condition, an end-of-file condition, or an end-of-record condition has occurred (7) Position the file after data transfer (9.2.1.3.3) (8) Cause any variables specified in the IOSTAT= and SIZE= specifiers to become defined." A simple reading of this seems to indicate that the point at which the error occurs and is detected by a standard-conforming processor is unspecified. Because IDX becomes undefined, the reference to IDX in the variable A(IDX) is incorrect. However, this is a very common style of coding I/O operations in Fortran. QUESTION 1: Was it the committee's intent that such a program should not be standard- conforming in the presence of an error condition? QUESTION 2: Does the fact that the error occurred before the item A(IDX) was processed mean that there was no reference to IDX, and hence, that the program is standard-conforming? ANSWER 1: No. ANSWER 2: Yes. DISCUSSION: The referenced paragraph (9.4.4) is misleading. The entire I/O list is not necessarily expected to be processed in the presence of an error. EDIT: For Fortran 95: In section 9.4.4, [150:32], in list item (5), change "or namelist" to "or namelist, until one of the end/error conditions described in 9.4.3 occurs, or until the entire input/output list or the namelist group has been processed" For 99-007r2: In Section 9.5.4, [203:36], in list item (6) of the first list, change "or namelist" to "or namelist, until one of the end/error conditions described in section 9.5.3 occurs, or until the entire input/output list or the namelist group has been processed" and in section 9.6.2 (WAIT Operation), second paragraph [214:5], insert the following after the first sentence. "If an end/error condition described in section 9.5.3 occurs during the data transfer, any remaining list items or namelist data objects are not processed." SUBMITTED BY: Henry Zongaro HISTORY: J3/99-177 m150 submitted J3/99-212 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000067 TITLE: Writing zeros KEYWORDS: list-directed output, namelist output DEFECT TYPE: Erratum STATUS: Passed by J3 meeting The standard currently requires a real zero to be written in exponential form when using list-directed or namelist output. QUESTION: Is this requirement intentional or an oversight? ANSWER: The requirement is an oversight. DISCUSSION: The G edit descriptor was changed in Fortran 90 to format a real zero as if an F edit descriptor were provided in most cases. The same change was not made for list-directed or namelist output, but should have. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 10.5.4.1.2, 10.8.2, and 10.9.2.1 EDITS: | For Fortran 95: | In section 1.5.1, after the last paragraph, add the following as list | item (3): | (3) List directed and namelist output statements produce a real | literal constant zero for a real value that is zero, and | for the real or imaginary part of a complex value that is zero. | In Fortran 95, these real literal constants are produced with | the effect of an F edit descriptor, instead of an E edit descriptor. and in section 10.8.2 (List-directed output), fifth paragraph, [177:41], change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" and in section 10.9.2.1 (Namelist output editing), third paragraph, [182:33], change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" For 99-007r2 (Fortran 2000): In section 1.5.2 (Fortran90 compatibility), add the following sentence to the end of the first paragraph. | "The following Fortran 90 features have different interpretations | in this standard." and in section 1.5.2, turn the 2nd paragraph into list item (1), and add the following after the 2nd paragraph as list item (2). | (2) List directed and namelist output statements produce a real | literal constant zero for a real value that is zero, and | for the real or imaginary part of a complex value that is zero. | In Fortran 2000, these real literal constants are produced with | the effect of an F edit descriptor, instead of an E edit descriptor. and in section 10.9.2 (List-directed output), fifth paragraph, [246:10], change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" and in section 10.10.2.1 (Namelist output editing), third paragraph, [251:4], change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" SUBMITTED BY: Robert Corbett HISTORY: J3/99-193 m150 Submitted J3/99-213r1 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Question: 1. Does the Fortran 95 standard require the external unit corresponding to the I/O unit identified by an asterisk for input or output to be the same as the external unit identified by some fixed nonnegative integer value? 2. Can the I/O unit identified by an asterisk for input or output correspond to more than one external unit? 3. If the external unit identified by an integer value that corresponds to the I/O unit identified by an asterisk for input or output is closed, does that cause the I/O unit identified by an asterisk to become disconnected? Answer: 1. No. 2. No. 3. Yes. Discussion: The submitter states: At least one Fortran 95 implementation uses -1 as the value of the I/O unit identified by an asterisk. A carefully constructed INQUIRE statement can expose this value to the user. Many users expect I/O to the units identified by asterisks to continue to work even after the corresponding units identified by integer values have been closed. 1. There is no requirement in the standard that the asterisk correspond to an external-file-unit. 2. For the units identified by the asterisk, the text of section 9.3.2 does not allow two or more units to be connected simultaneously to the same external device or file [139:8-9]. An edit is supplied to clarify this situation. 3. There might not be an external-file-unit that corresponds to the io-unit specified by an asterisk, as clarified by the edit below. If there is, it is permissible to execute a CLOSE statement on them as on any other unit. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2 EDITS: For Fortran 95: Add the following text to the end of the last paragraph before section 9.3.1 [138:34+]: "An asterisk used in an input statement may identify the same io-unit as a particular external-file-unit. An asterisk used in an output statement may identify the same io-unit as another particular external-file-unit." There are no edits required for Fortran 2000. SUBMITTED BY: Robert Corbett HISTORY: 99-192 m150 Submitted 99-215r1 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000069 TITLE: What is a numeric character? KEYWORDS: list-directed input DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Section 10.8.1 of the Fortran 95 standard states If the next effective item is of type default character and ... (4) The leading characters are not numeric followed by an asterisk, ... The standard does not define what a numeric character is. QUESTION: What is a numeric character? ANSWER: A numeric character is a digit. REFERENCES: ISO/IEC 1539-1:1997(E), Section 10.8.1 EDITS: In Fortran 95, section 10.8.1, list item (4), [176:17], replace the text (4) The leading characters are not numeric followed by an asterisk with (4) The leading characters are not digits followed by an asterisk In 99-007r2, section 10.9.1, list item (4), [244:32], replace the text (4) The leading characters are not numeric followed by an asterisk with (4) The leading characters are not digits followed by an asterisk SUBMITTED BY: Robert Corbett HISTORY: J3/99-191 m150 Submitted by Robert Corbett J3/99-214 m150 J3 draft response, approved uc ------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Asymmetry between constant specification and initialization expressions KEYWORDS: Initialization expressions; specification expressions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following programs. PROGRAM P1 REAL :: B = 4.0*ATAN(1.0) PRINT *, B END PROGRAM P1 PROGRAM P2 INTEGER :: A(INT(4*ATAN(1.0))) = 17 PRINT *, A END PROGRAM P2 According to 7.1.6.1 program unit P1 is not standard-conforming because of the reference to the intrinsic function ATAN which is not permitted in an initialization expression. According to 7.1.6.2 program unit P2 is standard-conforming; the reference to the intrinsic function ATAN is allowed by item (8) in the definition of a restricted expression. Expressions in the array bounds of an initialized entity are only required to be constant specification expressions, not initialization expressions. Was it the committee's intent to permit ATAN to appear in the array bounds of an initialized entity but not in the initialization value? ANSWER: No, this was not the intent. These expressions should have been described as initialization expressions instead of as constant expressions. This error also occurs for the definitions of an automatic entity, common block definitions and component definitions. The edits below change all of these to require initialization expressions instead of constant expressions. EDIT: [39:15] Change "a constant specification" to "an initialization". {Fix array components.} [39:23] Change "a constant specification" to "an initialization". {Fix character string components.} [40:30] Change "a constant" to "an initialization". {Fix note.} [48:47-48] Change "may be a nonconstant expression provided the specification expression" to "shall be an initialization expression unless it". [49:1-3] Delete "If a ... nonconstant expression." [49:4-5] Change "such a nonconstant expression" to "a that is not an initialization expression". {Fix definition of "automatic object".} [49:9] Change "a nonconstant expression" to "an expression that is not an initialization expression". {Fix evaluation time for character length.} [51:33] Change "a constant specification" to "an initialization". {Fix statement function character lengths.} [54:33] Change "nonconstant specification" to "not initialization". {Fix automatic array definition.} [54:34] Change "nonconstant specification" to "not initialization". {Fix evaluation time for explicit-shape array bounds.} [56:32] Change "nonconstant specification" to "not initialization". {Fix evaluation time for assumed-size array bounds.} [69:3-4] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix common block array-specs.} [192:26] Change "a constant" to "an initialization". {Fix characteristics of function results.} SUBMITTED BY: Henry Zongaro HISTORY: 99-178 m150 submitted 99-216r1 m150 approved uc 00-133 m152 additional edit, approved uc ------------------------------------------------------------------------------- NUMBER: 000071 TITLE: Character array constructors KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The f95 standard appears to leave the length of zero-sized character array constructors undefined. The penultimate paragraph of clause 4.5 says "The type and parameters of an array constructor are those of the expressions." If there are no elements, then the values of the type parameters might not be defined. The type and kind are always well defined at compile time. However, the length parameter for zero-sized character array constructors is not obviously well-defined, even at run-time. Zero-sized constructors are certainly allowed, as mentioned in the antipenultimate paragraph of clause 4.5: "An empty sequence forms a zero-sized rank-one array." Experimentation with different f90 compilers yields varying results. QUESTION 1: Is the following a valid program and, if so, what len value does it print. program zero write (*,*) len( (/ ('abc', i = 1 , 0) /) ) end QUESTION 2: Is the following a valid program and, if so, what value does it print. program zero_size integer :: n = 0 call sub('abcdefghij', n) contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:i+2), i = 1 , n) /) ) end subroutine end program zero_size QUESTION 3: Is the following a valid program and, if so, what values does it print for the lengths and for n_calls. program zero_size integer :: n = 0 integer :: n_calls = 0 call sub('abcdefghij', n) write (*,*) 'n_calls = ', n_calls contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) ) end subroutine sub integer function f(i) f = 2*i + 5 n_calls = n_calls + 1 end function f end program zero_size ANSWER: (1) Yes. The length is 3. Clause 4.5 says that "The type and type parameters of an array constructor are those of the expressions." There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information. The example array constructor has an that is the character literal 'abc'; this clearly has the character length of 3 and therefore the array constructor has a character length of 3. The description of how an that is an implied DO is handled confuses syntax and semantics: an edit is supplied to clarify this. (2) No. The edits below clarify this situation. (3) Yes. The length printed is 5, n_calls is still zero. Clause 4.5 says that "If the expressions are of type character, each expression in the shall have the same character length parameter." The example array constructor has an that is the character literal 'abcde'; this clearly has the character length of 5 and therefore the array constructor has a character length of 5. No references to the function F are executed because these appear within a zero-trip implied DO loop. EDITS: In clause 4.5, in the paragraph beginning "If an is a scalar expression" [46:1] replace: "an sequence" with "a sequence of elements". In clause 4.5, at the end of the paragraph which begins "If the expressions are of type character" [45:38+], insert: "A zero-sized character array constructor shall have at least one that is an initialization expression, a that does not contain a , or a containing a in which all expressions are initialization expressions." SUBMITTED BY: Richard Maine HISTORY: 98-101 m144 submitted 20 Nov 1997 99-207 m150 additional input 99-217r3 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000072 TITLE: Resolving generic procedure references KEYWORDS: generic, ELEMENTAL DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Consider INTERFACE generic ELEMENTAL SUBROUTINE sub_e(a) REAL,INTENT(INOUT) :: a END SUBROUTINE sub_3(a) REAL,INTENT(INOUT) :: a(:,:,:) END END INTERFACE This is legal (it obeys the restrictions in 14.1.2.3). This allows the ambiguous reference REAL x(10,20,30) CALL generic(x) However, the existing text in 14.1.2.4.1 does not explain which procedure is called, because the reference is consistent with two procedures. Note 14.6 indicates that the intent is to call the non-elemental procedure in this case. Is note 14.6 correct as to the intent of the standard? ANSWER: Yes, note 14.6 is correct; an edit is supplied to the resolution rules to implement this. EDIT: [278:41] After "with" insert "a non-elemental reference to". SUBMITTED BY: Malcolm Cohen HISTORY: 99-218 m150 submitted, approved uc ------------------------------------------------------------------------------- NUMBER: 000076 TITLE: INTENT(IN) dummy arguments and implied DO loops KEYWORDS: INTENT(IN), implied DO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The Fortran 95 standard [53:13-17] says "Constraint: A dummy argument with the INTENT(IN) attribute ... shall not appear as ... (3) A DO variable or implied-DO variable, ..." The apparent intent is to prevent any modification of the dummy argument; however, use in data-implied-do and array-constructor-implied-do would not modify the dummy argument. Is the constraint intentionally stronger than necessary? ANSWER: The constraint is only intended to apply to implied-DO variables in I/O lists. The following edit makes this clearer. EDIT: [53:17] Change "A DO variable or implied-DO variable" to "The in a or ". SUBMITTED BY: Malcolm Cohen HISTORY: 99-199 m150 submitted 99-199r1 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000077 TITLE: INTENT(IN) dummy arguments and NULLIFY KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: The Fortran 95 standard [53:13-17] says "Constraint: A dummy argument with the INTENT(IN) attribute, or a subobject of such a dummy argument, shall not appear as ... (2) The of a , ..." Consider: TYPE t REAL,POINTER :: value END TYPE ... SUBROUTINE s(x) TYPE(t),INTENT(IN) :: x IF (.FALSE.) x%value => NULL() ! (1) IF (.FALSE.) NULLIFY(x%value) ! (2) According to the constraint above, line (1) is illegal. However, there is no corresponding constraint for the NULLIFY statement, implying that line (2) is legal. Should subobjects of INTENT(IN) dummies also be constrained against appearing as the of a NULLIFY statement? ANSWER: Yes, there should be a constraint disallowing INTENT(IN) dummy arguments in a NULLIFY statement. The edit below corrects this omission. EDIT: [53:16] After "" insert "or ". SUBMITTED BY: Malcolm Cohen HISTORY: 99-200 m150 submitted 99-200r1 m150 approved uc ------------------------------------------------------------------------------- NUMBER: 000079 TITLE: Pointer Assignment and Allocatable Arrays KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider PROGRAM p REAL,ALLOCATABLE,TARGET :: x(:) POINTER p(:) p => x ALLOCATE(x(10)) PRINT *,SIZE(p) END This appears to be a legal program - there seems to be no prohibition against pointer assignment to an unallocated allocatable array and allocating the array does not seem to alter the association status of any pointer associated with an allocatable array. Should there be a prohibition against pointer assignment to an unallocated allocatable array? ANSWER: Yes; an edit is supplied to correct this oversight. EDIT: In clause 7.5.2, at the end of the paragraph that begins "The shall" [111:8+], insert: "If the is an allocatable array it shall be currently allocated." EDIT to 99-007r2: [156:7+] add to end of paragraph: "If the is allocatable it shall be currently allocated." SUBMITTED BY: Malcolm Cohen HISTORY: 99-223 m150 submitted, approved 6-4 ------------------------------------------------------------------------------- NUMBER: 000080 TITLE: Host association and the EXTERNAL attribute KEYWORDS: Host association, EXTERNAL DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Use of a (non-intrinsic) name as a procedure in a procedure reference implicitly confers the EXTERNAL attribute on the name. Does this happen when the name is host-associated? For example, f90 interp 143 established that MODULE m1 REAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END was invalid - 11.3.2 now says that a "procedure with implicit interface and public accessibility shall explicitly be given the EXTERNAL attribute in the scoping unit of the module". However, this text says nothing about private entities, so considering: MODULE m2 REAL,PRIVATE :: x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END This example does not violate 11.3.2 because X is PRIVATE. Is this example conforming? Further, considering: PROGRAM m3 REAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END This example is not of a module and so 11.3.2 does not apply. Is this example conforming? Further, considering PROGRAM m4 EXTERNAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END Does the invocation as a function in an internal procedure cause X to be implicitly typed, or is this not conforming? ANSWER: No, use of a host-associated name never confers attributes on the host entity. Examples M2, M3, and M4 are therefore invalid. Edits are supplied. EDIT: [188:28] Delete "and public accessibility". [188:31] Delete "with public accessibility". [283:16+] Add new paragraph "A procedure with an implicit interface that is accessed via host association shall explicitly be given the EXTERNAL attribute in the host scoping unit or be used as a procedure in that scoping unit; if it is invoked as a function in the inner scoping unit, its type and type parameters shall be explicitly declared in a type declaration statement in the host scoping unit. An intrinsic procedure that is accessed via host association shall explicitly be given the INTRINSIC attribute in the host scoping unit or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Malcolm Cohen HISTORY: 99-230 m151 submitted 99-230r1 m151 approved uc ------------------------------------------------------------------------------- NUMBER: 000082 TITLE: Usage of BOZ literal constants KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Consider: INTEGER X(10) DATA X(B"001")/42/ END This is apparently conforming, since the constraint at [32:15] says "A may appear only in a DATA statement." But this rules out X(B"001") = 42 Is this an error? ANSWER: Yes, BOZ literal constants should be restricted to being a . EDITS: [32:15] Replace text of constraint with "A may appear only as the in a DATA statement." SUBMITTED BY: Malcolm Cohen HISTORY: 99-275 m151 submitted 99-275r1 m151 approved uc ------------------------------------------------------------------------------- NUMBER: 000083 TITLE: Scope of array-constructor implied-DO variable KEYWORDS: Scope, implied DO, array constructor DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: 14.1.3 states that the scope of an implied-DO variable in an array constructor is "the implied-DO list". There is no such syntax term: what is meant? In particular, in the array constructor (/ (I,I=1,I) /) are all three I's references to the implied-DO variable, or is one of them a reference to a variable I in the enclosing scoping unit? ANSWER: All occurences of I within the implied-DO are references to the implied-DO variable, none of them can reference a variable in the enclosing scoping unit. The term "implied-DO list" is confusing in this context; "implied-DO" was intended. An edit is supplied for clarification. DISCUSSION: The term "implied-DO list" is used in several places where the context is that of the values produced by the implied-DO. This is an inappropriate term to use for specifying scope. Also, the second and third occurrences of "I" in the example shown are part of the syntax item . It would be unreasonable to read "implied-DO list" as meaning (for array constructors) " and the in but not the s in ." Note that the problem does not arise for because variables other than implied-DO variables are not permitted in the limit expressions. With this interpretation the example array constructor supplied is not valid Fortran, as it is not permissible to reference the value of an variable in one of its limit expressions. EDITS: [280:41] Replace "implied-DO list" with "implied-DO". SUBMITTED BY: Malcolm Cohen HISTORY: 00-124 m152 Submitted 00-124r1 m152 approved uc ------------------------------------------------------------------------------- NUMBER: 000084 TITLE: Events that cause variables to be defined KEYWORDS: Definition status, INTENT(OUT) DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Item (6) of 14.7.5 says "A reference to a procedure causes the entire dummy argument to become defined if the entire corresponding actual argument is defined with a value that is not a statement label. A reference to a procedure causes a subobject of a dummy argument to become defined if the corresponding subobject of the corresponding actual argument is defined." For an INTENT(OUT) dummy this appears to conflict with 14.7.6 item (13)(b) "When a procedure is invoked ... (b) A dummy argument with INTENT(OUT) is undefined except for any nonpointer direct components of the argument for which default initialization is specified." So in X = 3 CALL S(X) ... SUBROUTINE S(A) INTENT(OUT) A ... Is A defined (with the value 3) in accordance with 14.7.5, or undefined in accordance with 14.7.6? Similarly, for subobjects of INTENT(OUT) dummies, does 14.7.5 take precedence or 14.7.6? ANSWER: A is undefined in accordance with 14.7.6. An edit is supplied to remove the conflict. Similarly, 14.7.6 takes precedence for subobjects. EDITS: To Fortran 95: [289:9] Before "entire" insert "dummy argument does not have INTENT(OUT) and the". [289:12] Before "corresponding" insert "dummy argument does not have INTENT(OUT) and the". To draft Fortran 2002: No edits required (above fixes already incorporated). SUBMITTED BY: Malcolm Cohen HISTORY: 00-141 m152 submitted, approved uc -------------------------------------------------------------------------------