From JANSHEP@torolab2.vnet.ibm.com Wed Sep 21 10:56:46 1994 Received: from vnet.ibm.com by dkuug.dk with SMTP id AA17958 (5.65c8/IDA-1.4.4j for ); Wed, 21 Sep 1994 21:03:17 +0200 Message-Id: <199409211903.AA17958@dkuug.dk> Received: from TOROLAB2 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1081; Wed, 21 Sep 94 15:02:57 EDT Date: Wed, 21 Sep 94 14:56:46 EDT From: "Janice Shepherd" To: sc22wg5@dkuug.dk Subject: Defect Items X-Charset: ASCII X-Char-Esc: 29 Hi, Here are the 21 defect items that were processed at meeting 130 and were given the status "X3J3 draft response". They will be part of an X3J3 letter ballot that will start shortly. Comments from non-X3J3 members on these defect items are also welcome. Janice C. Shepherd janshep@torolab2.ibm.com -------------------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for pointers and target association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: Any of the above conditions except for f) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. In determining whether a pointer and a target are associated, the bounds are not relevant, but the extents are. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). If TGT is zero sized, ASSOCIATED (PTR, TGT) returns .FALSE.. Discussion: There are only three means by which a pointer may become pointer associated: via the ALLOCATE statement (6.3.1), via pointer assignment (7.5.2), or via argument association (12.4.1.1). -- In an ALLOCATE statement, the object created inherits its type, type parameters, rank, shape, size and bounds from those declared for, or specified with, the pointer name. -- In a pointer assignment, the type, type parameters, and rank of the pointer and target must conform, and the shape, size, and order of elements of the target determine those of the pointer. -- When a pointer actual argument is passed to a pointer dummy argument, the pointer dummy argument becomes pointer associated with the same target as the pointer actual argument. In all three of these cases, array elements of the pointer and the target correspond with one another in array element order. Thus, since there is no other way for two objects to become pointer associated, their type, type parameters, rank, size, shape, and order of elements must be the same. REFERENCES: ISO/IEC 1539:1991 (E) 5.1.2.4.3, 6.3.1, 7.5.2, 12.4.1.1, & 14.6 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022) HISTORY: 120-LJM-3A (120.081A) m121 Original response proposed 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 92-093A m121 Approved 92-329 (jw note) m123 Approval rescinded at m123 (uc) 93-099r1 m124 Revised response adopted (15-2) 93-111 m125 ballot failed, returned to subgroup 93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. 93-255r1 m127 ballot failed 17-7 94-289 m130 revised answer, approved u.c. ------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, is defined to be an or an . Since an may be an expression, a substring is a valid . Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1 is yes. Each character literal constant in an must be the same length. Both examples are nonstandard conforming. The answer to question 3 is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an . Since the length cannot always be determined at compile time, that part of the constraint must be changed to prose. EDITS: 1. In the second constraint following R435 [38:3-4] change: "the same type and type parameters." to: "the same type and kind type parameter." 2. Add the following paragraph after the constraints in 4.5. [38:4] If the expressions are of type character, each expression in the must have the same length type parameter. SUBMITTED BY: (Questions 1 and 2) Larry Rolison in 120-LRR-1 (120.026) (Question 3) Larry Rolison in X3J3/93-070 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - 93-070 m124 Question 3. submitted as 93-100 m124 proposed response, adopted by unanimous consent 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot, failed; 94-179 m129 minor edit changes 94-225r1 m130 adjust EDITS, as per WG5 ballot, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with target dummy argument requires explicit interface KEYWORDS: argument - dummy, interface - explicit, TARGET attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. The supplied edit corrects the error. Discussion: Defect item 000125 supplies edits to make it clear that: If the dummy argument has the TARGET attribute 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. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. In this case, the simple argument association mechanism that involves supplying only the location of the first storage unit of the argument or of a copy of the argument (see C.12.5) is not adequate at the point of reference. In particular, the location of the actual argument and details of its layout in storage may need to be available within the called routine to ensure that the pointer association works as described. EDIT: Section C.5.3, second sentence, change "solely" to "primarily". [269:21] SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) 92-070 m121 Approved m123 Approval rescinded (uc) 93-101 m124 Revised response adopted by uc 93-111 m125 ballot approved m128 Status changed to "consideration in progress" as this refers to edits in 000121 that no longer exist 94-235 m130 draft revision, approved uc -------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 Draft response QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraicly equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. ------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: X3J3 Draft response QUESTION: Section 12.5.2.9, Restrictions on entities associated with dummy arguments, clearly states that if there is partial or complete overlap between actual arguments associated with two different dummy arguments of the same procedure, the overlapping portions may not be defined, redefined, or undefined during the procedure execution. It continues: This restriction applies equally to pointer targets. For example, in REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) B (3:5) cannot be defined because it is part of the actual argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument. Unfortunately, this example does not contain an explicit interface for the called subroutine, nor are there sufficient words to clearly state what is meant by the words and example provided. Question 1: Do the above restrictions hold when both dummy arguments are non-pointers? In this case the following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y END SUBROUTINE END INTERFACE Question 2: Same as question 1, only add the TARGET attribute to one or both of the dummy arguments. The following interfaces may describe SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), TARGET :: X, Y END SUBROUTINE END INTERFACE or INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y TARGET X END SUBROUTINE END INTERFACE Question 3: Do the above restrictions hold *upon entry* when both dummy arguments are pointers? That is, *upon entry* to SUB, is it safe to assume that pointer dummy arguments do not have overlapping elements which may get defined during execution of SUB? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), POINTER :: X, Y END SUBROUTINE END INTERFACE Question 4: Same as question 3, but one dummy argument is a pointer, one has the target attribute. *Upon entry* to SUB, is it safe to assume a pointer dummy argument does not point to any elements of a target dummy argument which may get defined during execution of SUB, but during the execution of SUB such an association may come to exist? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y POINTER X TARGET Y END SUBROUTINE END INTERFACE Question 5: Two derived type dummy arguments each have a subobject (or a subobject of a subobject etc.) which are pointers with the same type, kind type parameter, and rank. *Upon entry* to the subroutine, is it safe to assume such pointer subobjects do not have overlapping targets which may get defined? That is, in the following fragment, *upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 cannot have overlapping target elements which get defined during execution of SUB? SUBROUTINE SUB (X, Y) TYPE A SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_1 END TYPE TYPE B SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_2 END TYPE TYPE (A) :: X TYPE (B) :: Y ANSWER: There is a deficiency in the standard. The restrictions always apply to the allocation status or exact pointer association status of the entities, but do not apply to the values when (1) the dummy argument or a subobject of the dummy argument has the POINTER attribute or (2) the dummy argument has the TARGET attribute and does not have INTENT(IN) and the actual argument is a target other than a vector-valued array section. Edits are supplied to correct this. The answers to the specific questions are: Answer 1: Yes for the interface specified. Answer 2: Yes for the allocation status or exact pointer association status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status or exact pointer association status of the entities. No for the values. Overlapping elements of dummy arguments may be defined during execution of SUB. Answer 4: Yes for the allocation status or exact pointer association status of the entities. No for the values except when (2) holds. Upon entry to SUB, a pointer dummy argument may point to an element of a target dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status or exact pointer association status of the entities. No for the values. Overlapping elements of pointer components of dummy arguments may be defined during execution of SUB. Discussion: The restrictions of Section 12.5.2.9 on entities associated with dummy arguments are intended to allow a processor to translate a procedure on the assumption that each dummy argument is as distinct from any other entity accessible in the procedure as if it were a local entity other than a dummy argument. This allows a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument without the TARGET attribute is maintained in a register or in local storage. The latter mechanism is usually known as "copy-in/copy-out". The text assumed that the rules applied to an actual argument with the TARGET attribute, too, but defect item 125 has made it clear that this is not the case and edits are needed in 12.5.2.9. The present text is correct with respect to the "availablity" of an entity associated with a dummy argument. Neither pointer assignment nor any of the statements ALLOCATE, DEALLOCATE, NULLIFY may be applied other than through the dummy argument. For example, in the code INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP => J ! Illegal the pointer assignment is not allowed because it is changing the pointer association of the actual argument. In the case of a dummy argument with the attribute POINTER or TARGET, the implementation can assume that its descriptor is distinct from any other entity accessible in the procedure. The present text is incorrect for the value of a pointer dummy argument. Here, the implementation must allow for the value to be altered through another pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP = 0 ! OK. This alters the value of iargp, too. It is also incorrect where the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than a vector-valued array section. Here the implementation must allow for the value to be altered through a pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of iargt, too. EDITS: 1. In section 12.5.2.9, [180:3-4] Replace the first two lines of item (1) by The <> of a pointer is affected by execution of a pointer assignment, ALLOCATE, DEALLOCATE, or NULLIFY statement. Action that affects the allocation status or exact pointer association status of the entity or any part of it must be taken through the dummy argument. Action that affects the value of the entity or any part of it must be taken through the dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than a vector-valued array section. For example, in 2. In section 12.5.2.9, [180:32] in the line following the line "DEALLOCATE (A)" change 'availability' to 'pointer association status'. 3. In section 12.5.2.9, [180:36-38] in the second to last paragraph on page 180, after "execution of the procedure" add "and the dummy arguments have neither the POINTER nor the TARGET attribute". 4. In section 12.5.2.9, [181:8] in line 8 of page 181, after "CALL SUB(B,C)" add "! The dummy arguments of SUB are neither pointers nor targets". 5. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by If the allocation status or exact pointer association status of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument. If the value of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than a vector-valued array section. For example, in 6. In section C.12.7, [291:40-42] Replace lines 3 to 5 by accessible in the procedure as if it were a local entity other than a dummy argument. This allows a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument without the TARGET attribute is maintained in a register or in local storage. SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 94-248 m130 Revised response and edits. 94-282r1 m130 Clarified terminology, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following code fragment standard conforming? INTERFACE SIN REAL FUNCTION MY_SIN(X) REAL, INTENT(IN) :: X END FUNCTION END INTERFACE Section 14.1.2.3 contains the following sentence: "When an intrinsic procedure, operator, or assignment is extended, the rules apply as if the intrinsic consisted of a collection of specific procedures, one for each allowed combination of type, kind type parameter, and rank for each argument or operand." This sentence indicates that there is a "hidden" generic interface for the intrinsic SIN that looks something like : INTERFACE SIN REAL FUNCTION DEFAULT_REAL_SIN(X) REAL, INTENT(IN) :: X END FUNCTION REAL FUNCTION REAL_DIFFERENT_KIND_SIN(X) REAL(KIND=), INTENT(IN) :: X END FUNCTION ... COMPLEX FUNCTION CSIN(X) COMPLEX, INTENT(IN) :: X END FUNCTION ... END INTERFACE Section 11.3.2 indicates that if a user supplies a generic interface SIN such as in the first example, the user interface will be treated as a single interface with the "hidden" generic intrinsic interface. However, according to the rules of section 14.1.2.3 the MY_SIN specific interface and the "hidden" DEFAULT_REAL_SIN specific interface are ambiguous. Therefore users must not write generic interfaces unless they are sure that the generic name they select and the arguments to the specific interfaces they specify will not conflict with any "hidden" generic interfaces implied by the generic intrinsics. ANSWER: The code fragment ought to be standard conforming. Edits are provided to reflect this. Discussion: As the standard is currently written, if a generic interface were written an ambiguity as described in the rules of 14.1.2.3 could not be avoided without knowledge of all intrinsics. Requiring such knowledge is a severe hindrance to the useability of generic interfaces. An edit is supplied so that the rules in 14.1.2.3 do not apply to the specific procedures represented by a generic intrinsic. The rules for resolving procedure references to names established to be generic are given in section 14.1.2.4.1. Section 12.3.2.3 describes the semantics of the INTRINSIC statement. An edit is supplied for this section to clarify that the name of a generic intrinsic function with the INTRINSIC attribute can also be the name of a generic interface. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 13, 14.1.2.3 EDITS: 1. In section 12.3.2.3 add to the end of the first paragraph after the constraint [171:12]: "The appearance of a generic intrinsic procedure name in an INTRINSIC statement does not mean that the name cannot also appear as the name of a generic interface (14.1.2.3)." 2. In section 14.1.2.3 in the third sentence [242:28]: change "When an intrinsic procedure, operator, or" to "When an intrinisc operator or" SUBMITTED BY: Larry Rolison HISTORY: 92-210 m123 submitted 93-180 m125 Response, approved 19-1 93-255r1 m127 ballot failed 21-3 94-163r1 m129 Clarified answer and added another edit. withdrawn as new edit needs rewording. 94-241 m130 Sorted edits. Revised edit 1. Add edit 3. 94-290r1 m130 Revised edit 2 and deleted edit 3. Simplified discussion. Approved u.c. -------------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and host association KEYWORDS: use association, host association, generic interface, EXTERNAL statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups in a module. Host association, 12.1.2.2.1 states An internal subprogram, a module subprogram, or a derived-type definition has access to the named entities from its host via host association. The accessed entities are known by the same name and have the same attributes as in the host and are variables, constants, procedures including interfaces, derived types, type parameters, derived-type components, and namelist groups. Question 1: Do use and host association access the same entities? What entities does each access? Question 2: For both use and host association, what entities are not accessed? Question 3: For host and use association, if the host or module referenced contains an EXTERNAL statement for ABC, is ABC an accessed entity that has the EXTERNAL attribute? Note that an EXTERNAL statement is not a "named entity" (the statement has no name) and the procedure named in the statement is not in the host or module (that is the reason for the EXTERNAL statement). The answer to question 1 or 2 should also answer this question. Question 4: Given the following PROGRAM A MODULE M USE X USE Y CONTAINS SUBROUTINE B USE M is subprogram B associated in some way with X? What way? Note that A, the host of B, "accesses" entities in X by use association; the entities in X are not "in" B's host. Question 5: In the same example is subprogram B associated in some way with Y? What way? As with question 4 note that the entities in Y are "accessed" from M; the entities in Y are not in M and use association refers to the entities "in the module". Question 6: Given the following: MODULE A ! level 1 host USE AA INTERFACE F ... CONTAINS SUBROUTINE B ! module subroutine, level 2 host USE BB INTERFACE F .... CONTAINS SUBROUTINE C ! internal subprogram USE CC INTERFACE F ... .... = F(X) ! an invocation of the generic name F and where modules AA, BB, and CC all contain a generic interface for F: How is the invocation of the generic name F resolved? (in what sequence are the host scopes and the modules used considered?) Note the levels of nesting: A contains B contains C. Section 14.1.2.4.1, "Resolving procedure references to names established to be generic", (3), seems to consider only B, the host of C, and not A. ANSWER: Answer 1: Entities declared PRIVATE are potentially accessible by host association but not by use association. Otherwise, it was intended that the classes of entities made accessible by these two forms of association be the same. These are named data objects (including both constants and variables), derived types, derived type components, procedures (both those defined in the host or module and those declared there and defined elsewhere; both those identified by names and those identified by other generic identifiers), and namelist groups. See sections 12.1.2.2.1 and 11.3.2. While the words used to describe the classes of accessible entities are not identical the meaning behind the words is the same. Future versions of the standard should endeavor to use the same words for these two lists. Answer 2: Entities not in the list in 12.1.2.2.1 and 11.3.2 are not made accessible. For example, FORMAT statement labels, construct names, and common block names are not made accessible. Answer 3: In such an example, ABC would be accessible. Section 12.3.2.2 indicates that the EXTERNAL statement specifies a list of names that are procedures. In the host or module, ABC is the name of a procedure and thus is the name of a potentially accessible entity; it is not necessary that the definition of ABC be present in the host or module. Answer 4: The entities of module X made accessible in A by use association are made accessible in B by host association. Note that each such entity has a local name (or other identifier) in A. See Section 11.3.2. Answer 5: The entities of module Y made accessible in M by use association are made accessible in B by use association. Note that each such entity has a local name (or other identifier) in M. See Section 11.3.2. Answer 6: In effect, first C and CC are checked for a consistent specific interface, then B and BB, then A and AA, and finally (if F were the generic name of an intrinsic function) the intrinsics are checked. In applying 14.1.2.4.1 to a reference in C, item (1) provides the check of interfaces in C (including those made accessible from CC), and item (3) provides for a recursive application of 14.1.2.4.1 to B. In this recursive application, (1) checks B (and BB), and (3) results in a further recursive application of 14.1.2.4.1 to A. In this application, (1) checks A (and AA), (3) is not applicable, and (4) checks the intrinsics. 14.1.2.3 establishes that there must be no ambiguity in distinguishing the interfaces declared in C from those made accessible from CC. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-214 Submitted 92-281 m123 Response proposed (11-7 was insufficient for approval) 93-030r1 Revised response proposed m124 Approved (15-1) 93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits 93-234 m126 edit replaced by that in item 82, approved uc Note: cannot go forward until 000082 does. 94-034 m128 Relying on edit in 000082 that has been removed, status changed to X3J3 consideration in progress 94-240r1 m130 Revised response with no edit, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Erratum STATUS: X3J3 Draft response QUESTION: What is the behavior of the ASSOCIATED intrinsic function for zero-sized arguments? Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero-sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWERS: Answer 1: The one-argument form of ASSOCIATED returns a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. Answer 2: No; if either argument is zero sized the result is false. The following edits clarify the intent. Answer 2a: The result is false because P1 and P2 each are zero sized. Answer 2b: The result is false because the arrays are of zero size. Discussion: The reasons for having the ASSOCIATED function return false for zero-sized arrays is based on an analogy with sharing storage and how assignment works. In normal English we understand the concept of "totally associated" and "partially associated". If two things are totally associated then doing something to one of them does the exact same thing to the other. If two things are partially associated then doing something to one of them does something to the other. Section 14.6.3.3 hints at this by discussing "totally associated" in terms of "the same storage sequence". After executing assignment statements like I = values J = different_values we would call I and J associated if it were no longer true that I == values. Zero-sized arrays are the end case where doing "something" to them is equivalent to doing nothing to them. And in the example above we would still have I == values after the assignment if both I and J were zero-sized but would otherwise appear to be associated. We could also conclude that after the pair of assignment statements above executed we would have I == different_values if I and J were zero sized, since the comparison operators return true for zero-sized objects. However, on balance it seems better to view the comparison with the initial conditions, not the potential changed conditions. As a practical matter sensible use of the ASSOCIATED function with zero-sized arrays will usually require user special casing of the results. EDITS: 1. Section 13.13.13 Case (ii) [198:37], replace by "If TARGET is present and is a target, the result is true if TARGET does not have size zero and POINTER is currently associated with TARGET. Otherwise, the result is false." 2. Section 13.13.13 Case (iii) [199:1], replace by "If TARGET is present and is a pointer, the result is true if both POINTER and TARGET are currently associated with the same nonzero-sized target. Otherwise the result is false." SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 WG5 ballot, failed 94-253r3 m130 revised response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) ; P = Q The phrase "partial statements" used in sections 3.3.1.2 and 3.3.2.2 would suggest that they are legal code fragments. It was likely the intention that the semicolon be permitted after a complete statement and (possibly) before the start of a subsequent statement. ANSWER: None of the cases are conforming. DISCUSSION: The phrase "partial statements" used in 3.3.1.2 and 3.3.2.2 was intended to describe the strictly lexical entity resulting when a line is continued in mid-statement. A statement interrupted by continuation, and the associated portion on the subsequent line, are two partial statements. Thus it was intended that breaking a statement into two partial statements be accomplished by continuation only, and not also by the ";" separator. Edits are provided to avoid the use of the phrase "partial statements" while making more concise the intention of the standard committee. With these edits, the following are conforming examples, and cases (1), (2) and (3) are nonconforming. F = & G ; P = & ! conforming Q F = & G ; P = Q ! conforming F = G ; P = & ! conforming Q EDITS: 1. Section 3.3.1.2 [22:44-45], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context or in a comment. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line.' 2. Section 3.3.1.2 [23:1-2], eliminate the last sentence of this section (it becomes redundant with edit 1). 3. Section 3.3.2.2 [23:36-37], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context, in a comment or in character position 6. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line, except in character position 6.' 4. Section 3.3.2.2 [23:39-40], eliminate the last sentence of this section (it becomes redundant with edit 3). SUBMITTED BY: Paul St. Pierre, 119-PSP-1 HISTORY: 119-PSP-1 (initial submission) ui 94 (jw note) 92-284 m123 considered 94-072r1 m128 new response approved uc 94-116 m129 X3J3 ballot failed 13-10 94-243r1 m130 Revised 3rd edit and revised question to be closer to original question. Approved u.c. -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=-3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character" The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,- 1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. Similar corrective edits are included for the definitions of constant and restricted expressions. EDITS: 1. In section 7.1.6.1, in the first list, in item 2 [77:20], change: "either constant expressions or implied-DO variables," to: "constant expressions," 2. In section 7.1.6.1, in the first list, in item 6 [77:28], delete the last "or" 3. In section 7.1.6.1, in the first list, add as item 7 and renumber the rest [77:28+]: "(7) An implied-DO variable where the bounds and strides of the corresponding implied-DO are constant expressions, or" 4. In section 7.1.6.1, in the second list, in item 2 [77:39], change: "either initialization expressions or implied-DO variables," to: "initialization expressions," 5. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 6. In section 7.1.6.1, in the second list, add as item 7 and renumber the rest [78:10+]: "(7) An implied-DO variable where the bounds and strides of the corresponding implied-DO are initialization expressions, or" 7. In section 7.1.6.2, in the list, in item 5 [79:4], change: "either restricted expressions or implied-DO variables," to: "restricted expressions," 8. In section 7.1.6.1, in the list, in item 9 [79:15], delete the last "or" 9. In section 7.1.6.1, in the second list, add as item 10 and renumber the rest [79:15+]: "(10) An implied-DO variable where the bounds and strides of the corresponding implied-DO are restricted expressions, or" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-027 Submitted 93-088 Draft response approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. 94-221 m130 X3J3 ballot failed 22-1 94-244 m130 Edits revised. Approved u.c. -------------------------------------------------------------------------------- NUMBER: 000135 TITLE: INTENT(IN) conformance KEYWORDS: INTENT(IN) attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 1.4, Conformance, states "An executable program (2.2.1) is a standard-conforming program if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this International Standard." Consider the following fragment: SUBROUTINE A (X) INTENT(IN) :: X IF (expr) X = 1.0 The intent attribute (5.1.2.3) specifies that X must not be redefined or become undefined during the execution of the procedure. Does the use of X in this fragment meet both conformance requirements -- using only those forms and relationships described herein -- the executable program has an interpretation (assume that "expr" is false) according to this International Standard? If "yes", was it the intent of the standard that a conforming processor not reject this program until X=1.0 is executed? ANSWER: No, the use of X in this fragment does not meet the conformance requirements of using only forms and relationships described in the standard. However, the existing wording of the standard could be interpreted to imply that the fragment was conforming if "expr" were always false. The edits below clarify that the fragment is non-conforming whether or not "X=1.0" is executed, and apply equally to the INTENT attribute in a type declaration statement and the INTENT statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.1 and 14.7.5 EDITS: 1. Section 5.1.2.3 following R511 - add the following constraint after the existing constraint [44:24+]: "Constraint: A dummy argument with the INTENT(IN) attribute, or subobject of such a dummy argument, must not appear in the following contexts: As the of an ; As a DO variable or implied-DO variable; As an in a ; As a in a if the appears in a NML= specifier in a ; As an in an ; As an IOSTAT= or SIZE= specifier in an input/output statement; As a definable variable in an INQUIRE statement; In an ; As a in an or ; or As an actual argument in a reference to a procedure with an explicit interface when the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute." SUBMITTED BY: Dick Weaver HISTORY: 93-156 m125 initial submission 93-191 m126 proposed response 93-208 m126 revised response, approved uc 93-255r1 m127 ballot failed 21-3 93-326 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-091 m128 additional edit supplied, approved 16-1 94-116 m129 X3J3 ballot failed 10-13 94-274r1 m130 Revised response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: R536 states that an can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A(2), I = 1,1) is conforming while (A(2), I = 1,2) is not conforming Is there a constraint missing, along the lines of s and s that are s must each have at least one subscript whose value is a function of the . ANSWER: No. There is no constraint missing. Discussion: The first implied-DO was standard conforming in FORTRAN 77, and continues to be in Fortran 90. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 94-291 m130 alternate response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 5.1.2.11 "INTRINSIC attribute" states The INTRINSIC attribute specifies that an object name in a declaration containing this attribute must be the specific or generic name of an intrinsic function... Section 5.1.2.10 "EXTERNAL attribute" has similar wording Question 1: Given REAL, INTRINSIC :: SIN REAL, EXTERNAL :: ABC Are SIN and ABC object names? If so, of what objects? Question 2: Given LOGICAL, INTRINSIC :: SIN What entity is being declared with the type 'LOGICAL'? ANSWER: Answer 1: SIN and ABC are not object names. The standard should not have used 'object name' in sections 5.1.2.10 and 5.1.2.11, but the name of the appropriate syntactic class. The edits below correct these sections. Answer 2: No entity is being declared with the type LOGICAL. Specifying a data type for a generic intrinsic function does not, in itself, remove the generic property from that function (section 5.1, [40:36-38]). There is no requirement for the data type specified in such a case to be one of the return types of the generic intrinsic. REFERENCES: 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'object name' with '' [48:26] 2. Section 5.1.2.11 Replace 'object name' with '' [48:30] SUBMITTED BY: Dick Weaver X3J3/93-160 HISTORY: 93-160 m125 Submitted 93-183 m125 response withdrawn 93-314r1 m127 response withdrawn 94-209 m129 minor changes to response, failed 9-10 Current version is 93-314r1. 3rd and 4th edits should be dropped. 94-292 m130 reversed answer 2 and reduced to 2 edits; approved u.c. -------------------------------------------------------------------------------- NUMBER: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure, external procedure DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: In Fortran programs it is sometimes the way an entity is referenced that partially determines what the entity is. For example given the following specification section: INTEGER X it is not clear until X is referenced as to whether X is the name of a function or the name of a variable. If such a specification statement appears in the scope of a module, can a reference to the entity by use association partially determine what the entity is? Section 11.3.2 indicates that the local name of an entity made accessible by use association may appear in no other specification that would cause any attribute of the entity to be respecified in the scoping unit (except the local name can appear in a PUBLIC or PRIVATE statement if the scoping unit is a module). But this section does not comment on the following example: MODULE M1 IMPLICIT INTEGER(A) INTEGER UNCLEAR1, UNCLEAR2 EXTERNAL ALSO_UNCLEAR ! Could be a subroutine or a function INTEGER SIN ! Could be a variable or an intrinsic CONTAINS SUBROUTINE XX(I) I = UNCLEAR1() ! Indicates UNCLEAR1 ! is a function not a variable. END SUBROUTINE END MODULE USE M1 WRITE(6,*) UNCLEAR1(), UNCLEAR2(), ALSO_UNCLEAR() END ANSWER: No. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider the classification of a procedure as a function or a subroutine as can be specified by executable statements. It was the intent that attributes of all use associated entities and the classification of use associated procedures be specified within the scope of the module. An exception was made for the PUBLIC and PRIVATE attributes. An edit is provided to clarify the intent. EDIT: In section 11.3.2, ahead of "Examples:" add 2 new paragraphs [158:41+]: "A procedure with an implicit interface and public accessibility must explicitly be given the EXTERNAL attribute in the scoping unit of the module; if it is a function, its type and type parameters must be explicitly declared in a type declaration statement in that scoping unit. An intrinsic procedure with public accessibility must explicitly be given the INTRINSIC attribute in the scoping unit of the module or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 94-242r1 m130 revised text and edit; approved u.c. -------------------------------------------------------------------------------- NUMBER: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following program : PROGRAM EX1 INTERFACE SQRT REAL FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC SQRT WRITE(*,*) SQRT(16) END SUBROUTINE TEST END According to the standard (section 14.1.2.4) the name SQRT is both generic in TEST (since it is a generic intrinsic) and in the host scope EX1 since it is a generic user procedure. According to 14.1.2.4.1 the reference to SQRT(16) should resolve to USERSQRT i.e. even though the user specifies intrinsic for SQRT he ends up with a reference to a user procedure. Contrast that with the following example where SQRT has been replaced by CSQRT: PROGRAM EX2 INTERFACE CSQRT COMPLEX FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC CSQRT WRITE(*,*) CSQRT(16) END SUBROUTINE TEST END In this case CSQRT is the name of a specific intrinsic procedure and the reference CSQRT(16) is according to 14.1.2.4.2 to that procedure, which since the argument type is integer, is invalid. By changing from a generic to a specific intrinsic name, the call resolution changes drastically which a user could find very confusing - it seems that the intrinsic attribute confers different properties in the two cases. Is this interpretation of the standard correct? If so, was this the intended behaviour? ANSWER: Yes, the interpretation of the standard is correct. Yes, it was the intended behaviour. Discussion: In the first example, SQRT is established to be a generic name. The resolution of a reference to a generic name is specified in 14.1.2.4. In the second example, CSQRT is established to be a specific intrinisc name within the internal procedure. In a reference to a specfic intrinsic, any arguments specified must match those expected by the specific intrinsic. EDITS: None. SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted 94-294 m130 response approved u.c. -------------------------------------------------------------------------------- NUMBER: 000177 TITLE: Structures in EQUIVALENCE lists KEYWORDS: derived type, EQUIVALENCE statement, SEQUENCE, pointer DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 5.5.1 "EQUIVALENCE statement" contains the following constraint [57:1-5]: Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects. It seems that each of the phrases in the constraint is intended to be an independent phrase such that one could rewrite the constraint in columnar form: Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects. When written in this form it seems that the phrase an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, is disallowing an object of nonsequence derived type that contains a pointer at any level of component selection as well as an object of sequence derived type that contains a pointer at any level of component selection. However, at least two existing Fortran 90 processors declare ANY object of a nonsequence derived type in an EQUIVALENCE list as being in error, obviously because the implementers split the above phrase into an object of a nonsequence derived type, an object of a sequence derived type containing a pointer at any level of component selection, What is the intent of the standard? ANSWER: The intent was for the latter. If the former had been intended, the wording would have been "an object of a derived type containing a pointer at any level of component selection". This is confirmed in C.5.5, line 4 [270:9]: "Structures that appear in EQUIVALENCE statements must be sequence structures.". Note that for COMMON there is a very clear restriction in 5.5.2 [58:33]: "Constraint: If a is of a derived type, it must be a sequence type (4.4.1)". An edit is supplied to make the intention clearer. EDIT: On page 57, line 2, [57:2] change "derived type or" to "derived type, an object" SUBMITTED BY: Larry Rolison HISTORY: 94-156 m129 submitted 94-287r1 m130 response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The first constraint following rule R822 states: Constraint: The must be a named scalar variable of type integer, default real, or double precision real. The definition of loop initiation (8.1.4.4.1) states: (2) The DO variable becomes defined with the value of the initial parameter 1. The definition of the execution cycle of a DO loop (8.1.4.4.2) states: (3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3. Consider the following program: INTEGER, POINTER :: ptr INTEGER, TARGET :: lcv ptr => lcv DO ptr = 1, 3 PRINT *, lcv END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: ptr INTEGER, TARGET :: lcv1, lcv2 lcv1 = 1 lcv2 = 4 ptr => lcv1 DO ptr = 1, 3 IF (...) ptr => lcv2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Did the standard mean to allow a DO variable to have the POINTER attribute? ANSWER: No. This oversight has been remedied by an edit. Discussion: The description of the iterative form of the DO loop was essentially carried forward from the previous standard. It was an oversight to prohibit the DO variable from having the POINTER attribute. Prohibiting the POINTER attribute prevents the confusion that can arise as demonstrated by the example programs given above. EDIT(S): Section 8.1.4.1.1 following the first constraint following rule R822 [100:39+] insert the new constraint: Constraint: The must not have the POINTER attribute. SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 -------------------------------------------------------------------------------- NUMBER: 000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Consider the following example: SUBROUTINE S() INTERFACE GEN1 FUNCTION F1(I) END FUNCTION FUNCTION F2(I,J) END FUNCTION END INTERFACE INTERFACE GEN2 FUNCTION G1() END FUNCTION FUNCTION G2(I) END FUNCTION END INTERFACE CALL SS() CONTAINS SUBROUTINE SS() INTERFACE GEN1 FUNCTION F3(I,J,K) END FUNCTION FUNCTION F4(II) END FUNCTION END INTERFACE INTERFACE GEN2 SUBROUTINE G3() END SUBROUTINE END INTERFACE A = GEN1(1,2,3) ! CALL TO F3 A = GEN1(1,2) ! CALL TO F2 A = GEN1(1) ! CALL TO F4 CALL GEN2() ! CALL TO G3 END SUBROUTINE END There are rules in section 14.1.2.3 that determine within a scoping unit what procedures can have the same generic specification. These rules directly mention access of a generic procedure via use association, but they make no mention of generic names accessed via host association. There is evidence that the rules in section 14.1.2.3 were not intended to apply to generic interfaces accessed by host association. Section 14.1.2.4.1 indicates that a call to a generic name can be resolved to a generic name in the host if the scoping unit and the host scoping unit both agree that the generic name is the name of a function or a subroutine. This indicates that in the example above, the definition of 'GEN2' is valid, even though 'G1' and 'G2' are functions while 'G3' is a subroutine. If the rules set out in 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. Do the rules in 14.1.2.3 apply to generic procedures accessed via host association? ANSWER: No. The rules in 14.1.2.3 were intended to apply to only those specific procedures declared to be generic in a scoping unit and those accessed via use association. Edits are included to clarify this. EDITS: 1. Add to the end of the first sentence of section 14.1.2.3 [242:27] "when the generic interfaces for each of the specific procedures are declared in the same scoping unit or accessed via use association." 2. Add to the end of the first paragraph of section 14.1.2.3 [242:32] "When a generic procedure is accessed from a host scoping unit, the steps for resolving a procedure reference as described in 14.1.2.4.1 have the same effect as if the rules restricted which specific versions from the host scoping unit can be accessed via the generic reference." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000181 TITLE: in STOP and PAUSE statements KEYWORDS: STOP, PAUSE DEFECT TYPE: Interpretation STATUS: X3J3 Draft response QUESTION: Was it an oversight to allow named character constants in addition to character literals as the (R843) of STOP (section 8.4) and PAUSE (section 8.5) statements? ANSWER: No. It was intended that the be expanded from the forms allowed in FORTRAN 77. EDITS: None. SUBMITTED BY: Linda O'Gara HISTORY: 94-251 m130 submitted with suggested answer 94-271 m130 alternate answer proposed, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000182 TITLE: Intrinsics in statement functions KEYWORDS: statement function, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Item 52 contains an edit to section 12.5.4 to add the following after the first sentence of the first constraint: [184:4] "If contains a reference to a function or a function dummy procedure, the reference must not require an explicit interface, the function must not require an explicit interface or be a transformational intrinsic, and the result must be scalar. If an argument to a function or a function dummy procedure is array valued, it must be an array name." This new text appears to disallow statement functions that were valid in FORTRAN 77. Consider the following code fragment which references the intrinsic INT. PROGRAM SF ISF(A) = INT(A) ... WRITE(6,*) ISF(2.3) END In Fortran 90 INT has an optional argument and thus must have an explicit interface (which it does have as it is an intrinsic and all intrinsics have explicit interfaces). The edited constraint, which indicates "the function must not require an explicit interface", means that this is a not a valid Fortran 90 statement function. Should the statement function shown be a valid Fortran 90 statement function? ANSWER: Yes. The statement function in the code fragment is a valid Fortran 90 statement function. Discussion: The edit in item 52 was included with the intent of limiting the definition of statement functions to mostly that which was provided by FORTRAN 77. By indicating that a function referenced in a statement function must not require an explicit interface, the intent was to prohibit the use of such functions as ones that have dummy arguments that are pointers or results that are pointers. Such functions did not exist in FORTRAN 77. It was not the intent to prohibit statement functions that were valid in FORTRAN 77. An edit is provided that corrects the edit from item 52. EDITS: Section 12.5.4., in the second sentence, as supplied in corrigendum 1 [182:4] change "the function must not require an explicit interface or be a transformational intrinsic," to "the function, if it is not an intrinsic, must not require an explicit interface, the function must not be a transformational intrinsic," SUBMITTED BY: Janice C. Shepherd HISTORY: 94-263r1 m130 submitted with suggested answer, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The standard considers (14.1.2.3) the following example to be ambiguous: INTERFACE BAD SUBROUTINE S1(A) END SUBROUTINE SUBROUTINE S2(B,A) END SUBROUTINE END INTERFACE ! BAD because it requires a single argument which disambiguates both by position and by keyword (A of S2 disambiguages by position but not by keyword; B of S2 disambiguates by keyword but not by position). Note that the above is the simplest example of unambiguous overloading which the standard disallows; other cases exist where the number of nonoptional arguments is the same, e.g. INTERFACE DOUBLE_PLUS_UNGOOD SUBROUTINE S1(I,P,A) END SUBROUTINE SUBROUTINE S2(J,A,I) END SUBROUTINE END INTERFACE where S2 takes two nonoptional INTEGER arguments to S1's one, but there is still no single argument which disambiguates between them. A third example shows an (apparently forbidden) unambiguous overloading where the number of arguments of each datatype are the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,B) END SUBROUTINE SUBROUTINE S2(J,I,B,A) REAL I INTEGER A END SUBROUTINE END INTERFACE Was the overly strict nature of the disambiguation rules an unintentional oversight? ANSWER: Yes. Two changes are needed to the rules in 14.1.2.3 to avoid rejecting reasonable programs. The first is to allow a difference in the number of arguments of each data type to disambiguate overloads. The second is to relax the matching rules for dummy argument disambiguators to allow the positional disambiguator to differ from the keyword disambiguator so long as it precedes it. If the positional disambiguate does not appear in the reference (because the actual argument list switches to keyword arguments prior to the position of the postional disambiguator), the presence of the keyword disambiguator with a keyword resolves the ambiguity. Discussion: The following example shows why the ordering relationship between positional disambiguators and keyword disambiguators can be necessary: INTERFACE AMBIGOUS SUBROUTINE S1(I,B,J,A) END SUBROUTINE SUBROUTINES S2(K,I,A,J) REAL:: I END SUBROUTINE END INTERFACE CALL AMBIGOUS(3, 0.5, A=0.5, J=0) ! Cannot tell which of S1 or S2 to ! call EDITS: 1. In section 14.1.2.3, in the third paragraph [242:38] change "and at least one of them must have an nonoptional dummy argument that" to "and (A) one of them has more nonoptional dummy arguments of a particular data type, kind type parameter, and rank than the other has dummy arguments (including optional dummy arguments) of that data type, kind type parameter, and rank; or (B) at least of one of them must have both:" and indent numbers (1) and (2) following to be a sublist of list item (B). 2. In section 14.1.2.3, in the third paragraph, after "(1)" [242:39] change "Corresponds" to "A nonoptional dummy argument that corresponds" 3. In section 14.1.2.3, in the third paragraph, after "(2)" [242:42] change "Corresponds" to "A nonoptional dummy argument that corresponds" 4. In section 14.1.2.3, in the third paragraph, add a new paragraph after list (2) in list item (B) [242:44] "Further, either the dummy argument which disambiguates by position is the same as the one which disambiguates by keyword or occurs earlier in the dummy argument list than the dummy argument which disambiguates by keyword." SUBMITTED BY: Malcolm J. Cohen HISTORY: 94-281r1 m130 submitted with proposed response, approved u.c. --------------------------------------------------------------------------------