-------------------------------------------------------------------------------- NUMBER: 000150 TITLE: Undefinition of implied-DO variables in I/O statements KEYWORDS: i/o statement, implied-DO variable, defined, definition, undefined DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 9.4.3 (in two places) states that when a condition such as an error condition, an end-of-file condition, or an end-of-record condition occurs, execution of the I/O statement terminates and "any implied-DO variables become undefined". Section 14.7.6, item (6) states that when any of these conditions occur, "some or all of the implied-DO variables may become undefined" and references 9.4.3. It appears the intent of the standard was that all implied-DO variables in an I/O statement in which such a condition occurs become undefined. Is that the intent of the standard? ANSWER: Yes. An edit is supplied to make the wording express this intent in both sections 9.4.3 and 14.7.6. Discussion: In several of the draft versions of Fortran 90, specifiers appeared in various I/O statements with values that depended on knowing exactly how an I/O list had been processed prior to the occurence of an error condition. Late in the development of the standard, the committee realized that no value can be relied upon when an error occurs, and no assumptions can be made about how the I/O list has been processed. Such specifiers were removed but some related text was apparently overlooked. The standard can make no assumptions about how an implementation will process an I/O statement so it can not make any assumptions about which implied-DO variables could conceivably be still defined. Consider the following READ statement: READ *, (A(I), I = 1, 5), (B(J), J = 1, 5) If J was defined prior to the READ statement and if one of the cited conditions occurred while the first implied-DO was "active", the standard could not make the assumption that J remained defined because it could be impossible for the program or I/O system to determine that it was the first implied-DO that was active. REFERENCES: EDITS: 1. Section 9.4.3, second paragraph following the numbered list [124:44], change any implied-DO variables become undefined to if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 2. Section 9.4.3, second-to-last paragraph [125:7-8], change any implied-DO variables become undefined to if the input statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 3. Section 14.7.6, item (6) [251:43-45], change input/output statement, some or all of the implied-DO variables may become to input/output statement and the statement contains any implied-DOs, all of the implied-DO variables in the statement become SUBMITTED BY: Larry Rolison LAST SIGNIFICANT CHANGE: 93-12-20 000150 ballot approved HISTORY: 93-243 m127 submitted 93-300 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 -------------------------------------------------------------------------------- NUMBER: 000151 TITLE: Defined Operators with POINTER Operands KEYWORDS: defined operator, pointer DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Is it the intent of the standard that operators with pointer operands are disallowed or is this an oversight that requires correction? Consider the program below. Here a user has tried to define an operator .in. that returns true if a value is found in a tree and false if not. Unfortunately one of the arguments to listmember is a pointer. This is rejected by the compiler because according to the standard, section 12.3.2.1.1 [169:17-18], the dummy arguments must have intent IN but pointers must not have this intent, section 5.2.1 [49:3]. It appears then that an operator with pointer operands is not allowed in Fortran-90. MODULE LIST TYPE NODE INTEGER VALUE TYPE (NODE), POINTER :: NEXT END TYPE NODE INTERFACE OPERATOR (.IN.) ! check for membership in tree MODULE PROCEDURE LISTMEMBER END INTERFACE CONTAINS ! -------------------- IS A MEMBER ? -------------------- FUNCTION LISTMEMBER(VALUE,ROOTNODE) ! If ROOTNODE is given INTENT (in) then the compiler complains that ! intent may not be given to a variable with the POINTER attribute. ! If INTENT(IN) is not ! given then the compiler complains that the dummy argument rootnode must ! have an intent (when compiling the interface definition for .IN. above). TYPE (NODE), POINTER :: ROOTNODE TYPE (NODE), POINTER :: N INTEGER, INTENT(IN) :: VALUE LOGICAL LISTMEMBER LISTMEMBER = .FALSE. N => ROOTNODE DO WHILE(ASSOCIATED(N)) IF( N%VALUE == VALUE ) THEN LISTMEMBER = .TRUE. EXIT ELSE N => N%NEXT END IF END DO END FUNCTION LISTMEMBER END MODULE LIST ANSWER: Fortran 90 does not allow defined operators with pointer operands. Dummy arguments to a defined operator must have the INTENT(IN) attribute, but pointers are not allowed to have this attribute (5.2.1, 12.3.2.1.1). REFERENCES: EDIT: None. SUBMITTED BY: Graham Barber LAST SIGNIFICANT CHANGE: 93-12-20 000151 ballot approved HISTORY: 93-247 m127 submitted 93-315 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 -------------------------------------------------------------------------------- NUMBER: 000152 TITLE: Processor dependent values for list and namelist directed output KEYWORDS: i/o list-directed, i/o namelist DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In Fortran 90, section 10.8.2 [150:36-37], it states For numeric output, reasonable processor-dependent integer values of w, d, and e, are used for each of the numeric constants output The previous paragraph in the section discusses the choice of 0PFw.d or 1PEw.dEe edit descriptors based on d1 and d2 processor dependent integers. This would seem to suggest that d1 and d2 are chosen once and then used for all output values. Namelist formatting, section 10.9.2.1 [154:35-40], has similar text. Question: are w, d, e, d1, and d2 chosen once and then used for all values or can different values be chosen for each numeric constant? For each numeric constant kind? If the answer is "once", then a tabular presentation results, as in the following example for a sequence of integers. 1 234 56 789 3 1000 If the answer is "chosen for each constant" then a more efficient, compact, presentation could result. 1 234 56 789 3 1000 ANSWER: All of the selection methods described in the question above are allowed. The processor is free to choose the values for w, d, e, d1, and d2 based on the value or kind of the value being printed. The processor is also free to choose permanent (fixed) values for w, d, e, d1, and d2. REFERENCES: EDIT: None. SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-12-20 000152 ballot approved HISTORY: 93-248 m127 submitted 93-301 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 -------------------------------------------------------------------------------- NUMBER: 000153 TITLE: Defined Operations, dummy arguments INTENT(IN) KEYWORDS: INTENT(IN) attribute, defined operator DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 12.3.2.1.1 states If OPERATOR is specified in a generic specification, all of the procedures specified in the interface block must be functions that may be referenced as defined operations ..... The dummy arguments must be nonoptional dummy data objects and must be specified with INTENT(IN) .... In section C.11.4, "Example of a Module", "OPERATOR" is specified for interface blocks that specify the following procedures: ELEMENT, SUBSET, UNION, DIFFERENCE, INTERSECTION Looking at those procedures, is the example correct? ANSWER: The INTENT(IN) attribute must be explicitly specified in an operator function for each dummy argument; the attribute is not "implied". Thus, the example is incorrect. Edits are provided to correct the example. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.3.2.1.1 and C.11.4. EDITS: 1. Section C.11.4, in function ELEMENT [286:16,17], change INTEGER X to INTEGER, INTENT(IN) :: X and change TYPE (SET) A to TYPE (SET), INTENT(IN) :: A 2. Section C.11.4, in function UNION [286:21], change TYPE (SET) A, B, UNION to TYPE (SET) UNION TYPE (SET), INTENT(IN) :: A, B 3. Section C.11.4, in function DIFFERENCE [286:37], change TYPE (SET) A, B, DIFFERENCE to TYPE (SET) DIFFERENCE TYPE (SET), INTENT(IN) :: A, B 4. Section C.11.4, in function INTERSECTION [287:2], change TYPE (SET) A, B, INTERSECTION to TYPE (SET) INTERSECTION TYPE (SET), INTENT(IN) :: A, B 5. Section C.11.4, in function SUBSET [287:5], change TYPE (SET) A, B to TYPE (SET), INTENT(IN) :: A, B SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-12-20 000153 ballot approved HISTORY: 93-262 m127 submitted 93-325 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 -------------------------------------------------------------------------------- NUMBER: 000154 TITLE: EQUIVALENCE and zero-sized sequences KEYWORDS: EQUIVALENCE statement, zero-sized sequences DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 5.5.1 and its subsections discuss equivalence association and zero-sized sequences, but not in detail sufficient to answer the following questions: Given the following CHARACTER (LEN=4) :: A, B, C Question 1: are the following equivalence statements valid? COMMON /X/ A COMMON /Y/ B EQUIVALENCE (A, C(10:9)), (B, C(10:9)) ! the same zero-sized object is ! equivalenced to two different ! common blocks. EQUIVALENCE (A, C(10:9)), (B, C(100:90)) ! two different zero-sized objects ! are equivalenced to two different ! common blocks Question 2: is the following equivalence valid EQUIVALENCE (C, C(10:9)) Question 3: Is the following valid? EQUIVALENCE (C(10:9), C(100:90)) Question 4: It is generally the case that given CHARACTER (LEN=4) :: D, E, F then EQUIVALENCE (D, E) EQUIVALENCE (F, E) and EQUIVALENCE (D, E, F) both specify that D is equivalenced to F. Do the following specify the same storage associations? EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(2:1)) and EQUIVALENCE (D, E(2:1), F) EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(3:1)) ! E(3:1) is also zero-sized and EQUIVALENCE (D, E(2:1), F) Question 5: is E(2:1) a subobject of E? ANSWER 1: Both equivalence statements are invalid. In section 5.5.1.1 [57:21-22], the standard states that all zero sized sequences in the are storage associated with each other, and with the first storage unit of any non-zero sized sequences. In section 14.6.3.2, the standard states that two storage units that are associated with the same zero sized storage sequence are the same storage unit. In the first equivalence statement in question 1, both A and B are storage associated with the same zero sized storage sequence, namely C(10:9), therefore, A and B are storage associated, which is prohibited, since they are declared in different common blocks. In the second equivalence statement in question 1, the standard is unclear about whether C(10:9) and C(100:90) are the same zero-sized storage sequence. An edit is supplied to clarify this case. Since C(10:9) and C(100:90), are the same zero-sized storage sequence, the second equivalence statement in question 1 is illegal because the equivalence statement declares A and B to be storage associated, but they are declared in different common blocks. ANSWER 2: Yes. ANSWER 3: Yes. ANSWER 4: Yes. ANSWER 5: Yes. REFERENCES: EDIT: In section 14.6.3.2 [248:15], after the last sentence in the second paragraph, add "Two zero-sized subobjects of the same object are the same zero sized storage sequence.". SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-12-20 000154 ballot failed HISTORY: 93-264 m127 submitted 93-323 m127 response approved 14-5 94-034 m128 X3J3 ballot failed 10-18 -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 11.3.2 states: (with some formatting to better show logic, tags added to assist references): R1109 only is access-id or [local-name =>] use-name Constraint: Each access-id must be a public entity in the module. Constraint: Each use-name must be the name of a public entity in the module. ...... More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, (a) all public entities in the module are accessible and (b) the rename-lists and only-lists are interpreted as a single concatenated rename-list. Questions: 1. Is the syntax ambiguous? Note: R1107 use-stmt is USE module-name [,rename-list] or USE module-name, ONLY: [only-list] R1109 only is access-id or [local-name =>] use-name R522 access-id is use-name or generic-spec Thus use-name in an only-list can parse either as R1109 use-name or R1109 access-id -> R522 use-name. 2. Can rename-lists and only-lists be concatenated as a rename-list as specified in (b)? Only-lists permit "access-id", while rename lists require "local-name => use-name". ANSWER: 1. Yes. The syntax is ambiguous; "access-id" should be changed to "generic-spec" 2. No. Rename and only lists cannot be concatenated as a rename-list, however the "renames" in both lists can. REFERENCES: EDITS: 1. In section 11.3.2, R1109 [158:11] change "" to "" 2. In section 11.3.2, the first constraint following R1109 [158:13] change "" to "" 3. In section 11.3.2, paragraph beginning "A USE statement" [158:19] change "s" to "s" 4. In section 11.3.2, paragraph beginning "More than one" [158:22-23] change "s and s" to "s and renames in s" SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-12-20 000155 ballot approved HISTORY: 93-265 m127 submitted 93-305 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 -------------------------------------------------------------------------------- NUMBER: 000156 TITLE: Forward references to a derived type definition KEYWORDS: pointer, derived type, forward reference DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Consider the following declarations involving a reference to a derived type: Case 1: A structure declaration makes reference to a derived type definition. TYPE(def) :: s TYPE def INTEGER i, j END TYPE Case 2: A derived type definition makes reference to another derived type definition. TYPE one TYPE(two) substructure END TYPE TYPE two INTEGER k END TYPE Case 3: A pointer is declared to be of derived type. TYPE(thing), POINTER :: finger TYPE thing REAL skin, hand END TYPE Case 4: A pointer component is declared to be of derived type other than the derived type of which it is a component. TYPE one TYPE(two), POINTER :: link END TYPE TYPE two INTEGER i, j END TYPE Case 5: Two pointer components are declared to be of derived types other than the derived type of which they are a component and each pointer is of the other derived type, thus tightly linking the two derived types. TYPE one INTEGER :: int_field TYPE(two), POINTER :: link END TYPE TYPE two REAL :: real_field TYPE(one), POINTER :: link END TYPE Notice that in all of these cases, the initial derived type reference is a forward reference to the derived type's definition. For example, in Case 1, the definition of DEF follows its reference in the declaration of structure S. It seems that all of these declaration forms are prohibited by the standard because they involve forward references to derived type definitions. The relevant text is: Case 1: p. 43, lines 21-23 When a data entity is specified to be of a derived type, the derived type must have been defined previously in the scoping unit or be accessible there by use or host association. Case 2: p. 33, lines 22-23 Constraint: If the POINTER attribute is not specified for a component, a in the must specify an intrinsic type or a previously defined derived type. Case 3: Same as Case 1. Case 4: p. 33, lines 24-26 If the POINTER attribute is specified for a component, a in the must specify an intrinsic type or any accessible derived type including the type being defined. Case 5: Same as Case 4. However, the use of the word "accessible" in the paragraph cited from page 33 seems to be inexact. It could be construed to (a) be a shorthand way of saying "accessible by use association or host association" so the sentence would properly read ... or any derived type accessible by use association or host association including ... or (b) mean "available anywhere in the current scoping unit" so the sentence would properly read ... or any derived type defined in the current scoping unit or accessible by use association or host association, including ... The first case would mean that none of the cited forward reference forms are standard conforming. The second case would mean that the reference to a derived type from a pointer component of a structure (and only this case) could be a forward reference to another derived type. Did the standard intend to allow a forward reference to a derived type definition in none of the above declaration forms, in some of the above forms (which ones?), or in all of the above forms? ANSWER: Of the declaration forms shown above, the standard intended to allow a forward reference to a derived type only in forms exemplified by Case 5. Discussion: The second supposition above about the meaning of the word "accessible" in the sentence cited from page 33 is the correct one. Note that in all declaration forms shown except Case 5, the forward reference can be removed by moving the derived type definition to precede the reference to it. Case 5 demonstrates a declaration form where the two derived types are tightly linked via the two pointers. Forward referencing can not be avoided in this form. This form and the forward referencing that goes with it needs to be allowed since a number of applications use linked list forms where a "parent" node points to a "child" and each "child" node points back at the "parent" node. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison LAST SIGNIFICANT CHANGE: 93-11-12 000156 submitted HISTORY: 93-269 m127 submitted 94-048 m128 proposed response -------------------------------------------------------------------------------- NUMBER: 000157 TITLE: LBOUND and UBOUND return values KEYWORDS: LBOUND intrinsic, UBOUND intrinsic, zero-sized dimension, return value DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The LBOUND intrinsic function returns the value 1 for a zero-sized dimension of an array and the UBOUND intrinsic function returns the value 0 for a zero-sized dimension of an array. X3J3 has stated a number of times in responses to public comments and in other public forums that zero-sized arrays were specifically designed into the language with all the rights and privileges of nonzero-sized arrays; that is, zero-sized arrays were not supposed to be treated like "second-class citizens". Given this informal approach and the formal way in which zero-sized arrays have been integrated into the language (see Chapters 6 and 7), it seems counterintuitive for the LBOUND and UBOUND intrinsics to special-case zero-sized dimensions. For example, if a user declares an array as INTEGER array(10:3) the value 1 returned by LBOUND is no more meaningful than the value 10 that the user specified. In order for a program to know at run time whether or not an array or a dimension of an array has zero size, the program must still compare the lower bound to the upper bound or, better yet, use the SIZE intrinsic. Note that the same holds true for bounds that are calculated, like in ALLOCATE statements; that is, LBOUND should return the calculated value in these cases. The current descriptions of LBOUND and UBOUND seem to be incorrect with respect to zero-sized dimensions. Questions: (1) Are the descriptions of LBOUND and UBOUND, in fact, defective with respect to zero-sized dimensions (that is, should they return the lower and upper bounds as specified by the user)? (2) If the answer to the first question is No, what is the technical reason for LBOUND returning 1 and UBOUND returning 0 for a zero-sized dimension? ANSWER: (1) No. (2) There are three characteristics of each dimension of an array: the lower bound, the upper bound, and the extent. An implementation can calculate the address of an array element by maintaining the lower bound and upper bound or by maintaining the lower bound and the extent. If the standard were to require that the UBOUND intrinsic function return the declared or calculated upper bound, it would preclude implementations from maintaining dimension information via the lower bound and extent. REFERENCES: ISO/IEC 1539:1991 (E) Sections 13.13.52 and 13.13.111. EDIT(S): None. SUBMITTED BY: L. R. Rolison LAST SIGNIFICANT CHANGE: 93-11-12 000157 submitted, approved LAST SIGNIFICANT CHANGE: 93-12-20 000157 ballot approved HISTORY: 93-270 m127 submitted 93-324 m127 response approved uc 000124 HELD 94-034 m128 X3J3 ballot passed 25-2 -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: In many computers today the range of values for integer types is non-symmetric. Consider, for example, a machine with 8-bit integer arithmetic (to keep the numbers small). The integer range would typically be -128 to +127 Given an implementation that specifies an integer type with that range, do the following statements conform to Fortran 90? data i /-128/ i = - 128 ANSWER: The data statement is valid. r530 data-stmt-set is ... / data-stmt-value-list / r532 data-stmt-value is ... data-stmt-constant r533 data-stmt-constant is ... signed-int-literal-constant and -128 is a signed integer constant in the integer range. The assignment statement is NOT VALID. r735 assignment-stmt is variable = expr following the expr syntax, we eventually find r710 add-op is ... - r701 primary is constant r305 constant is literal-constant ... r306 literal-constant is int-literal-constant Thus the - is an operator, 128 is an int-literal constant, but is out of range and, therefore, the statement is not valid. Constraining of constants to the range of values is described in 4.0. "Intrinsic data types are parameterized. In this case the set of values is constrained by the value of the parameter ..." and "An example ... is the integer data type. This data type has a processor-dependent set of integer numeric values, each of which is denoted by ..." REFERENCES: EDIT: SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-11-12 000158 submitted HISTORY: 93-277 m127 submitted -------------------------------------------------------------------------------- NUMBER: 000159 TITLE: May undefined expressions be used as arguments to INQUIRY functions KEYWORDS: inquiry functions DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 13.7.2 Numeric inquiry functions contains the phrase "The value of the arguments to these functions need not be defined", and section 13.8.5 Array inquiry functions contains the similar phrase "The values of the array arguments to these functions need not be defined" One intent is to allow inquiries about the "static" properties of variables, for example: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA)) CHARACTER*(DIGITS(AA)) CC ... where the properties of BB and CC don't depend on the numerical values of AA. However, since the arguments to functions can also be expressions, may the expressions be undefined in the more traditional sense of not having a defined result value? Consider programs like: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA + 1.0)) CHARACTER*(DIGITS(AA + 1.0)) CC ... where the expression "AA + 1.0" is undefined in the normal sense of the word since AA is undefined. Must a processor accept programs where actual argument expressions (involving one or more operators or functions references, as opposed to expressions consisting of a single variable reference) would, if evaluated, use undefined variables or produce undefined results? ANSWER: No, the committee's intent was only to include inquiries about the attributes of undefined variables in the set of allowed inquiries. Discussion: That the resulting text applies to all expressions was unintended and edits are provided to correct this. Note that 'variable name' does not permit substrings or section-subscripts. Edits are not provided for the PRESENT or ASSOCIATED inquiry functions; neither of these permit expressions as arguments. REFERENCES: EDITS: 1. In section 13.5.4 Character Inquiry Function [184:18-19] replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined." 2. In section 13.5.7 Bit Manipulation and Inquiry Procedures [185:4-5] In the paragraph beginning "An inquiry ..." replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined, if a pointer it may be disassociated, and if allocatable need not be allocated." 3. In section 13.7.2 Numeric Inquiry Functions [186:7-8] replace the last sentence "The value of ...." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined, if a pointer it may be disassociated, and if allocatable need not be allocated." 4. In section 13.8.5 Array Inquiry Functions [187:12] replace the second paragraph "The values of ..." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined." SUBMITTED BY: Dick Hendrickson LAST SIGNIFICANT CHANGE: 93-11-12 000159 submitted HISTORY: 93-279 m127 submitted 94-017 m128 proposed response -------------------------------------------------------------------------------- NUMBER: 000160 TITLE: Variables with the TARGET attribute in EQUIVALENCE groups KEYWORDS: TARGET attribute, EQUIVALENCE statement, optimization DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The intent of the TARGET attribute is to aid in optimization. Section C.5.3 states: The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. It is also true that pointers may point only to variables with the same type and kind type parameters. However, there are no restrictions on variables with the TARGET attribute in EQUIVALENCE statements. EQUIVALENCE statements can fully or partially storage associate variables of the same or different types and kind type parameters. It appears that variables with the TARGET attribute may become associated with variables without the TARGET attribute, or with variables which have different types. Such storage association seriously inhibits the usefulness of the TARGET attribute in optimization, be it load/store optimization or parallel optimization. This problem appears to be even more severe than that of the C language's pointer aliasing problems in that C pointers can be assumed to alias only objects with matching types. Was it the intent of the committee to allow the storage association of target variables with nontarget variables and variables of different data types? ANSWER: No, this was not the intent of the standard. Discussion: The TARGET attribute was intended to specifically identify those variables which could be associated with pointers of the same type and type parameters. It was the intent to prohibit definition or reference of a nontarget variable through a pointer. An edit is provided to clarify the intent of the standard. REFERENCES: EDIT: After the sixth constraint of section 5.5.1 add [57:17+] Option 1 (preferred): -------- Constraint: An must not have the TARGET attribute. Option 2: -------- Constraint: If an has the TARGET attribute, all s in the must have the TARGET attribute. SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 93-11-12 000160 submitted HISTORY: 93-293 m127 submitted 94-049 m128 proposed response -------------------------------------------------------------------------------- NUMBER: 000161 TITLE: Modules and private derived types KEYWORDS: module, private DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: In compiling Bert Buckley's Fortran-90 algorithms that he made available recently the following issue came up : Section 4.4.1 (p 34) states that : The accessibility of a derived type may be declared explicitly by an access-spec in its derived-type-stmt or in an access-stmt (5.2.3). The accessibility is the default if it is not declared explicitly. If a type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. Applying this to the following code : module m1 private type fred integer f1,f2 endtype fred type(fred),public,parameter :: y=fred(1,2) type(fred),public :: x end it can be seen that entities x and y are accessible only within module m1. Therefore specifying the public attribute for x and y is an error. So far so good? Now what about this code : module m2 type fred integer f1,f2 endtype fred end module m3 use m2 private type(fred), public :: x end In module m3, the public type fred imported from m2 becomes private. Is the declaration of x illegal here? I think the text in 4.4.1 is inadequate to cover this scenario. I believe the declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. I think the standard was thinking of the m1 case not the m3 case. The problem as I see it is that module m2 contains the definition of the public type fred and the module m3 contains the "definition" of the private type fred. ANSWER: REFERENCES: EDIT: SUBMITTED BY: G. Barber LAST SIGNIFICANT CHANGE: 93-11-12 000161 submitted HISTORY: 93-... m127 submitted -------------------------------------------------------------------------------- NUMBER: 000162 TITLE: Pointer expression "(i)" KEYWORDS: expression, pointer DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Given the specifications integer, pointer :: i, j integer :: k are the following statements equivalent? j => i j => (i) are the following statements equivalent? k = i k = (i) ANSWER: REFERENCES: EDIT: SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-11-12 000162 m127 submitted HISTORY: 93-280 m127 submitted -------------------------------------------------------------------------------- NUMBER: 000163 TITLE: pointer assignment of a disassociated pointer KEYWORDS: pointer, expression DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: consider the following example from page 92 pointer_object => pointer_function (arg_1, arg_2) and suppose that the pointer returned by pointer_function is disassociated. What happens is described in section 7.5.2, page 92:17 If the target is a pointer that is disassociated, the pointer-object also becomes disassociated. However, noting that, in the example, 'pointer_function ...' is an expression, and that it is a primary, this is not valid per 7.1.4.1, page 76:20-22 If the pointer is not associated with a target it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer. Also see section 7.1.7, page 79:41-42 If the operand is a pointer, it must be associated ... Note that, per 7.1, page 70:7 An expression is formed from operands, operators, and parentheses. Thus in an expression consisting of a single primary as in the example above, that primary is an operand. Question: are pointer functions allowed to return disassociated pointers? ANSWER: Yes, pointer functions are allowed to return disassociated pointers. The text in section 7.1.4.1 is in error in appearing to disallow the result to be used in a pointer assignment statement; an edit is supplied to correct this. Section 7.1.7 applies to operands only in the context of evaluation of operations, so is not applicable to the target of a pointer assignment statement (or when the operand appears as an actual argument corresponding to a pointer dummy argument). REFERENCES: ISO/IEC 1539:1991 section 7.1.4.1 EDIT: In the final sentence of section 7.1.4.1, insert before the terminating period ", or as the target in a pointer assignment statement." [76:22] SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-11-12 000163 submitted HISTORY: 93-281 m127 submitted 94-044 m128 proposed response -------------------------------------------------------------------------------- NUMBER: 000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE mod INTEGER, PARAMETER :: max_size = 100 INTEGER, DIMENSION(max_size) :: array END MODULE PROGRAM main USE mod, ONLY: array ... END PROGRAM Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE mod TYPE inner INTEGER i END TYPE TYPE outer INTEGER k TYPE(inner) comp END TYPE END MODULE PROGRAM main USE mod, ONLY: outer ... END MODULE The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? If it is not valid, is it only an error if something in the main program actually tries to use OUTER? Can you write a structure constructor for OUTER in the main program? If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE mod TYPE def INTEGER k REAL r END TYPE TYPE(def) var END MODULE PROGRAM main USE mod, ONLY: var ... END MODULE In this example, only the variable VAR from the module is accessible; its type is not. Is this valid? If it is valid, can only the structure name VAR be referenced or can its components also be referenced? If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE mod INTEGER, PARAMETER :: max_size = 100 INTEGER, DIMENSION(max_size) :: array PRIVATE max_size END MODULE PROGRAM main USE mod ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: Discussion: REFERENCES: EDIT(S): SUBMITTED BY: Larry Rolison LAST SIGNIFICANT CHANGE: 94-02-11 000164 submitted HISTORY: email: Thu, 9 Dec 93 14:16:45 PST maine@altair.dfrf.nasa.gov email: Fri, 10 Dec 1993 09:18:28 jls@liverpool.ac.uk email: Fri, 10 Dec 1993 09:28:50 jls@liverpool.ac.uk email: Fri, 10 Dec 93 9:51:53 CST lrr@juniper email: Mon, 13 Dec 1993 10:19:19 jls@liverpool.ac.uk email: Mon, 13 Dec 93 10:57:59 malcolm@num-alg-grp.co.uk 93-349 m128 submitted (includes full text of above email msgs) -------------------------------------------------------------------------------- NUMBER: 000165 TITLE: Vector subscripts in Namelist input KEYWORDS: vector subscript, i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Can a namelist input record include vector subscripts? Section 10.9.1.1 indicates that if a namelist group object is an array then the input record can include a subobject of that array. ANSWER: No, vector subscripts are not allowed in a namelist input record. An edit to clarify this is included. REFERENCES: ISO/IEC 1539:1991 (E) sections 10.9.1, 10.9.1.1 EDIT(S): Add the following phrase in section 10.9.1, second paragraph, after "zero-sized array section," [152:4]: 'an array subscript with a vector subscript,' SUBMITTED BY: Janice C. Shepherd LAST SIGNIFICANT CHANGE: 93-12-20 000165 ballot failed HISTORY: 93-... m127 submitted 93-311r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 18-10 94-015 m128 proposed changing meaining of 'subscript' in f95 -------------------------------------------------------------------------------- NUMBER: 000166 TITLE: Array named constant is a constant expression? KEYWORDS: array constant DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: p63:30-31 A whole array named constant is the name of a constant expression that is an array. p44:6 has the example integer, dimension(3), parameter :: order = (/ 1, 2, 3 /) now the array constructor is a constant expression, p38:15-16, but why is 'order' a constant expression (as opposed to just 'constant')? Consider the following 1 integer, dimension(3), parameter :: order = (/ 1, 2, 3 /) 2 integer, dimension(3), parameter :: chaos = order 3 integer, dimension(3), parameter :: kaos = (order) If order is the name of a constant expression, as page 63 states, then -- order is not a constant expression per 7.1.6.1 as it doesn't meet any of (1) through (7) -- (order) is a constant expression per 7.1.6.1, meeting (7) "a constant expression enclosed in parentheses" -- neither order nor (order) are initialization expressions as neither meets 7.1.6.1 requirements for initialization expressions (1) through (7) and thus statements 2 and 3, above, are both invalid. ANSWER: Expressions do not have names; an edit is provided to correct this. REFERENCES: EDIT: Section 6.2.1, second paragraph: change "name of a constant expression (5.1.2.1 and 5.2.10)" to "name of a constant" [63:30-31] SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-11-12 000166 submitted HISTORY: 93-282 m127 submitted -------------------------------------------------------------------------------- NUMBER: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Can an initialization expression include arbitrary expressions for subscript or substring values if that subscript or substring value is not needed to evaluate the initialization expression? Consider the following example subroutine xx() character *10 text(20) integer, parameter:: i = len(text(b+i+fnc(r))) integer b, fnc allocatable r(:) .... end subroutine The subscript of 'text' is not relevant to the evaluation of the inquiry 'len'. There appears to be no restrictions in the standard against specifying such an arbitrary expression for the subscript. Note that with the definition of 'restricted expression' there are lines (79:17-18) that indicate that any subscript must be a restricted expression. It would seem advisable to have an equivalent statement with the definition of an initialization expression. Section 7.1.6.1 indicates that with a subobject of a constant any subscript, must be an initialization expression (77:36-37). This restriction does not apply to this example as 'text' is not a constant, so 'text(b+i+fnc(r))' is not a subobject of a constant. ANSWER: Discussion: REFERENCES: ISO/IEC 1539:1991 (E) sections 7.1.6.1, 7.1.6.2 EDIT(S): SUBMITTED BY: Janice C. Shepherd LAST SIGNIFICANT CHANGE: 93-11-12 000167 submitted HISTORY: 93-... m127 submitted -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: Use ONLY and Namelist KEYWORDS: use association, i/o namelist DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: If a scoping unit accesses a namelist group name by use association must all the namelist group items also be accessible in the scoping unit? Consider the following example MODULE M1 NAMELIST /N/ I,J,K END MODULE USE M1, ONLY: N, I ... WRITE(10,N) The section in the standard on the NAMELIST statement (5.4) indicates that a namelist group name must not be PUBLIC if any of its namelist group items have the PRIVATE attribute. But in this example the NAMELIST group name and each of its namelist group items have the PUBLIC attribute. Within the program only the namelist group name and one of its three namelist items are accessible. ANSWER: Discussion: REFERENCES: ISO/IEC 1539:1991 (E) sections 5.4 EDIT(S): SUBMITTED BY: Janice C. Shepherd LAST SIGNIFICANT CHANGE: 93-11-12 000168 submitted HISTORY: 93-... m127 submitted -------------------------------------------------------------------------------- NUMBER: 000169 TITLE: End of Namelist Input KEYWORDS: i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: What is supposed to be printed by the following? NAMELIST /NNN/ I, J INTEGER :: A(2) = 1 READ (*,NML=NNN) or NAMELIST /QQQ/ A PRINT *, I READ (*,NML=QQQ) END PRINT *,A(2); END if the input file is: &NNN I=1, J=2, &QQQ A(1)=2, I=3/ A(2)=3/ The following set of quotes from the standard leads me to believe the answer is 1, which at least is surprising and possibly not intended. Section 9.4.6 [128:22-29]: "Termination of an input/output data transfer statement occurs when any of the following conditions are met: . . . (3) Name... input reaches the end of a record after having processed a name-value subsequence for every item in the namelist-group- object-list." In the example above, after reading I=1 and J=2, condition (3) appears to be satisfied and when the end of the record (line) is reached, the I/O should terminate. A possible reaction to this is that "record" should mean everything up to and including the "/", but a) that is NOT the definition of record generally given, and b) in section 10.9.1 [152:1], item (5) it states that "A slash to terminate the namelist input statement." This is very peculiar use of the term "statement", which does not correspond to the usage elsewhere in the standard, but I must assume that this word was used deliberately because the word "record" is not correct (being a "line"). The other thing to consider is the position of the file after completion of the READ statement. The standard states (last sentence of 9.2.1.3.3) it should be at the end of the current record, which means that if you do another READ, you would read the line "I=3/". A slight bit of evidence that all this was not intended appears in the sentence in section 10.9.1.2 [152:47-48]. "Successive namelist records are read by namelist input until a slash is encountered; ..." (10.9.1.2 Namelist Input values) or perhaps this sentence is missing the exception listed in section 9.4.6 "Termination of data transfer statements" [128:22-29]. ANSWER: The intent of the standard was that "3" should be printed for both examples. Corrections to the standard are provided. Discussion: The sentence in section 9.4.6 item 3 [128:27-28] is wrong. For namelist input, the input data transfer statement is terminated when the terminating "/" is encountered, as discussed by item 6 in the same section. REFERENCES: EDIT(S): In section 9.4.6, item 3 [128:27-29] delete "or namelist input reaches the end of a record after having processed a name-value subsequence for every item in the " SUBMITTED BY: Janice C. Shepherd (for Walt Brainerd) LAST SIGNIFICANT CHANGE: 93-12-20 000169 ballot failed HISTORY: 93-284 m127 submitted 93-313 m127 response approved uc 94-034 m128 X3J3 ballot failed 26-1 -------------------------------------------------------------------------------- NUMBER: 000170 TITLE: Argument Keywords and Intrinsic Procedures KEYWORDS: argument keyword, intrinsic procedure DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 14.1.2.6 'Argument Keywords' makes no mention of argument keywords associated with intrinsic procedures. Should it not include text such as the following? "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it." ANSWER: Yes. An edit is supplied. REFERENCES: EDIT(S): In section 14.1.2.6 add a new paragraph after the current paragraph. [245:14+] "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it. As an argument keyword, it may appear only in a procedure reference for the procedure of which it is a dummy argument." SUBMITTED BY: Hideo Wada, IPSJ/ITSCJ SC22/Fortran LAST SIGNIFICANT CHANGE: 93-12-20 000170 ballot approved HISTORY: 93-... m127 submitted 93-309r1 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 -------------------------------------------------------------------------------- NUMBER: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Given A of type integer, real, or complex, must the expression DBLE (A) == REAL (A, KIND(0.0D0)) always evaluate to .TRUE. for each type and kind? ANSWER: Yes. This result, however, is not specified in the 'Result Value' text of the two functions. Where DBLE specifies 'as much precision ... as a double precision real datum can contain.', REAL specifies a 'processor-dependent approximation'. An edit is provided. REFERENCES: EDIT: In 13.13.27 DBLE, replace the text of the 'Result Value' section with: The result has the value REAL (A, KIND (0.0D0) ). [205:7-11] SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 94-02-11 000171 submitted HISTORY: 94-018 submitted --------------------------------------------------------------------------------