08-141 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #16 - due 11-Apr-2008 Date: 2008 March 07 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 7 Fortran 2003 interpretations are currently "Passed by J3 meeting" after J3 meeting #183. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0099 Clause 16 does not account for volatile variable --- --- F03/0102 Evaluation of bound-expr in data pointer assignment --- --- F03/0109 Referencing deferred binding via absent dummy argument --- --- F03/0111 Is defined assignment to a vector subscripted array allowed? --- --- F03/0112 attributes allowed for dummy arguments in defined assignments --- --- F03/0113 Size and uniqueness considerations for ID= --- --- F03/0114 Inconsistent restrictions on i/o specifiers The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Friday, 11-Apr-2008, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0099 TITLE: Clause 16 does not account for volatile variable KEYWORDS: volatile, defined, undefined DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Should the various lists in clause 16 that describe definition and association be modified to include the effects of volatile variables? In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact that pointer association status can be volatile and change by other means. 16.5.4 says "all other variables are initially undefined.? Can a volatile variable be initially defined by other means? 16.5 (26) says volatile variables "become defined", but they also can become undefined, by other means. Allocatable volatile variables can become allocated or unallocated by other means also. ANSWER: Yes, the lists in clause 16 should be modified to include the effects of volatility. In addition, the effects of volatile on pointer objects are not completely specified in clause 5. The effect on allocatable objects is not complete in clause 6. EDITS: [85:10] In the paragraph between note 5.21 and note 5.22, change "association status and array bounds" to "association status, dynamic type and type parameters, and array bounds" [415:27] Add a new paragraph at the end of 16.4.2.1.4 "The association status of a pointer object with the VOLATILE attribute may change by means not specified by the program." [421:43] In 16.5.5 list item (26) change "becomes" to "might become". [423:28+] In 16.5.6 after the last list item insert a new list item "(19) An object with the VOLATILE attribute (5.1.2.16) might become undefined by means not specified by the program." SUBMITTED BY: Dick Hendrickson HISTORY: 07-269 m181 F03/0099 Submitted 07-269r2 m181 Passed by J3 meeting 07-279/07-321 Failed letter ballot 07-339 m182 Passed by J3 meeting 08-133r1 m183 Failed letter ballot #15 08-101 08-137 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0102 TITLE: Evaluation of bound-expr in data pointer assignment KEYWORDS: pointer, pointer assignment, bounds, expression DEFECT TYPE: Clarification STATUS: Passed by J3 meeting DISCUSSION: Currently there are no rules in 7.4.2.1 to prohibit changing of a pointer's association status during evaluation of bound expressions in a data pointer assignment (pointer with either bounds-spec or bounds-remapping specified). This may lead to ambiguous code with regard to the evaluation orders between the bound expression and the data pointer assignment itself. Consider the following code, integer, target :: tar2(100, 100) integer, target :: tar1(100) integer, pointer :: ptr(:,:) ptr(-2:, f1(ptr, tar1, 1, 1):) => tar2 print*, lbound(ptr) print*, ubound(ptr) print*, size(ptr) contains function f1(ptr, arr, i, j) integer :: i, j, f1 integer, pointer :: ptr(:, :) integer, target :: arr(:) ptr (i:j, i:j) => arr f1 = -1 end function end In 7.4.1.3 for interpretation of intrinsic assignments, there are rules explicitly requesting evaluation of all expressions in variable occurred before the variable is defined [139:14-19]. It appears that data pointer assignment should also follow similar rules. Note the similar problem also exists for evaluating the if it references a function that returns a data pointer. QUESTION: (a) Is this program intended to be standard conforming? (b) If it is standard conforming, then what would it print? ANSWER: This program does not conform to the Fortran Standard. The assertion that there are no rules about pointer association status is false because changes in pointer association status necessarily cause changes in definition status, as explained in the opening paragraph of "16.4.2 Pointer association status" which states "If a pointer is associated with a target, the definition status of the pointer is either defined or undefined, depending on the definition status of the target." The reference to F1(PTR,TAR1,1,1) executes the pointer assignment PTR(I:J,I:J)=>ARR; this causes its actual argument PTR to become undefined (using the quoted rule from 16.4.2). In 7.1.8 paragraph 3, it says "If a function reference causes definition or undefinition of an actual argument of the function, that argument or any associated entities shall not appear elsewhere in the same statement." However, PTR appears elsewhere in that statement (as the base object of the variable in the assignment), violating this requirement. Therefore the program is not standard-conforming. EDITS: None. NOTE: This would be clearer if the undefinition case were also added to the list of "Events that cause variables to become undefined" in clause 16, e.g. "(n) When a pointer becomes associated with a target that is undefined, the pointer becomes undefined." This is recommended for a future revision of the Standard. SUBMITTED BY: Jim Xia HISTORY: 07-297r1 m182 F03/0102 Submitted 07-297r2 m182 Passed by J3 meeting 08-133r1 m183 Failed J3 letter ballot 08-135 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0109 TITLE: Referencing deferred binding via absent dummy argument KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program program P type, abstract :: T contains procedure(sub), nopass, deferred :: deferred_proc end type T call sub contains subroutine Sub ( X ) class(t), optional :: X call x%deferred_proc end subroutine Sub end program P Is this a valid program? If not, what restriction of the standard does it violate? Since x%deferred_proc has the NOPASS attribute, this does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, the first item in the second list in 12.4.1.2 (at [04-007:272:32-33]) does not prohibit this. ANSWER: This was not intended to be a valid program. A type-bound procedure shall not be invoked through an absent dummy argument. An edit is supplied to clarify this situation. The same flaw is present for procedure pointer component invocation. EDITS: Add new items to the second list in 12.4.1.6, [273:12+] "(11) It shall not be supplied as the in a . (12) It shall not be supplied as the in a ." SUBMITTED BY: Van Snyder HISTORY: 07-338 m182 F03/0109 Submitted; Passed by J3 meeting 08-133r1 m183 Failed J3 letter ballot 08-136 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0111 TITLE: Is defined assignment to a vector subscripted array allowed? KEYWORDS: defined assignment, vector-valued subscripts, elemental DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Is the assignment statement in subroutine cg1018 standard conforming? I does an elemental defined assignment to an array with a vector valued subscript. Several compilers reject this assignment, claiming that an INTENT(OUT) argument can't be associated with a vector-valued actual argument. According to 142:6-7, this is a defined elemental assignment. Lines 26 to 30 of 142 are "The interpretation of a defined assignment is provided by the subroutine that defines it. If the defined assignment is an elemental assignment and the variable in the assignment is an array, the defined assignment is performed element-by-element, in any order, on corresponding elements of variable and expr." The first line looks like a general definition of defined assignment and the second line looks like a qualification for the specific case of elemental assignment. The qualification has to mean that the assignments are performed on an element-by-element basis and this surely must mean that the statement is processed as if it were expanded into something like TLA1L(7) = UDA1R(7) TLA1L(1) = UDA1R(1) TLA1L(3) = UDA1R(3) ... and then the assignment subroutine is invoked on an element-by-element basis following the rules in chapter 12. Page 140, lines 4-5 have essentially identical words for intrinsic assignment and intrinsic assignment to a vector valued array, including derived type arrays, is allowed (if not many-to-one). The processors that reject the test program apparently interpret the assignment as Call U_TO_T( TLA1L(NFV1), (UDA1R)) without doing the assignment on an element-by-element basis. If that interpretation is correct, then we have the unusual situation where TLA1L(NFV1) = TLA1L is standard conforming if the assignment is intrinsic and non-standard if the assignment is defined. MODULE c_TESTS integer, save :: nfv1(10) = [1,2,3,4,5,6,7,8,9,10] TYPE UNSEQ REAL R END TYPE UNSEQ TYPE SEQ sequence REAL R END TYPE SEQ INTERFACE ASSIGNMENT(=) MODULE PROCEDURE U_TO_T END INTERFACE ASSIGNMENT(=) CONTAINS ELEMENTAL PURE SUBROUTINE U_TO_T(T,U) TYPE(SEQ),INTENT(IN) :: U TYPE(UNSEQ), INTENT(OUT) :: T T%R = U%R END SUBROUTINE U_TO_T SUBROUTINE CG1018(TLA1L,UDA1R) TYPE(UNSEQ) TLA1L(10) TYPE(SEQ) UDA1R(10) TLA1L(NFV1) = UDA1R !??????? END SUBROUTINE END MODULE c_TESTS ANSWER: This is not standard conforming. According to [271:3-5] If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the INTENT (OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes. EDITS: None SUBMITTED BY: Dick Hendrickson HISTORY: 08-104 m183 F03/0111 Submitted 08-104r1 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0112 TITLE: attributes allowed for dummy arguments in defined assignments KEYWORDS: defined assignment, dummy argument, attributes DEFECT TYPE: Clarification STATUS: Passed by J3 ballot DISCUSSION: It seems the standard is quite loose in allowing various attributes declared for the dummy arguments used in a defined assignment (7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE can be declared for dummy arguments in the defined assignment. However the interpretations on their declarations need to be clarified. Consider the follow subroutines (assuming a derived type DT already defined) 1. POINTER/ALLOCATABLE on the second dummy argument interface ASSIGNMENT (=) subroutine defAssgn1 (dt1, dt2) type(DT), intent(out) :: dt1 type(DT), POINTER, intent(in) :: dt2 end subroutine end interface In 12.3.2.1.2 [263:10-12], the standard says the following "A defined assignment is treated as a reference to the subroutine, with the left-hand side as the first argument and the right-hand side enclosed in parentheses as the second argument." This statement seems to prohibit the use of subroutine defAssgn1 for defined assignment since a pointer enclosed in parentheses refers to its associated target not the pointer itself, as indicated by rules in 7.1.4.1 [123:39-124:3]. 2. POINTER/ALLOCATABLE on the first dummy argument interface ASSIGNMENT (=) subroutine defAssgn2 (dt1, dt2) type(DT), POINTER, intent(out) :: dt1 type(DT), intent(in) :: dt2 end subroutine end interface There are no rules in the standard disallow this declaration. However the use of POINTER/ALLOCATABLE attributes on the first dummy argument is very doubtful. Since POINTER/ALLOCATABLE attributes don't disambiguate generic declarations(16.2.3), their use will prevent the normal declarations of defined assignments, wherein dt1 is declared without POINTER or ALLOCATABLE attribute. QUESTIONS: 1. Are POINTER and ALLOCATABLE attributes allowed for the second dummy argument in defined assignment? 2. Are POINTER and ALLOCATABLE attributes allowed for the first dummy argument in defined assignment? ANSWER: Yes to both questions. The standard places very few restrictions on the arguments to defined assignment subroutines: [363:6...] Each of these subroutines shall have exactly two dummy arguments. Each argument shall be nonoptional. The first argument shall have INTENT (OUT) or INTENT (INOUT) and the second argument shall have INTENT (IN). ... Preventing the first argument from having the POINTER attribute violates F90. Such a restriction for the second argument has no effect since the right argument is treated as an expression enclosed in parentheses which would have neither attribute. EDITS: None NOTE: A future standard should disallow the POINTER and ALLOCATABLE attributes on the second argument to defined assignment subroutines. SUBMITTED BY: Jim Xia HISTORY: 08-120 m183 F03/0112 Submitted 08-120r1 m183 Create answer 08-120r2 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0113 TITLE: Size and uniqueness considerations for ID= KEYWORDS: asynchronous I/O, ID=, size DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The ID= specifier returns an identifier (or "handle") for an async i/o request. Must this fit inside the smallest integer kind supported by the processor? Consider: Integer(Selected_Int_Kind(1)) x(1000) Character(80) :: test(1000) = (/ ... /) ... Do i=1,1000 Write (17,'(a)',Asynchronous='Yes',Id=x(i)) test(i) End Do ... Do i=1,1000 Wait (17,Id=x(i)) End Do X is only guaranteed to have approximately 20 values available, and in practice will probably only have 256 such values, so we are certainly not going to have 1000 unique handles. Without loss of generality, suppose that one such duplicate value is 4. After WAIT(17,ID=4), the async i/o request with ID 4 is no longer pending. This means that the subsequent WAIT(17,ID=4) is not conforming to the standard since it requires that the ID= value is one that is pending. (1) Is the processor permitted to require a minimum size for ID= (e.g. such as default integer)? Clearly 1000 values do not fit into a 256-valued object, but apart from that, (2) Is the processor required to produce unique ID= values for each multiple asynchronous i/o operation? One might conjecture that if the processor returned ID=4 for two or more async i/o requests on the same unit, the first WAIT for ID=4 would wait for the first such async i/o request and the second one would wait for the second such async i/o request. (3) Does WAIT-ing on an ID= value wait for all async i/o operations that have that as the handle, or are these queued up? Unlike other i/o-related specifiers, there does not seem to be any constraint on the value returned for ID= (such as being non-zero or non-negative). In the case of the i/o being completed synchronously, there does not appear to be any way of returning a "non-handle" to the user program (one might have conjectured that zero was not a handle, but this is not supported by the text of the standard). (4) Was there intended to be a "non-handle" return for ID=? DISCUSSION: It is understood that resource considerations may limit the number of outstanding asynchronous i/o requests, but 19 (the limit implied by the minimum-size integer that follows the model in c13) seems awfully small; for that matter 256 seems pretty small for todays operating systems. ANSWER: (1) Yes, the standard should require the ID= specifier to be default integer or bigger. An edit is provided. (2) Yes, all pending data transfer operation identifiers on a particular unit are required to be unique. An edit is provided to clarify this. (3) ID= values are required to be unique, so this question does not arise. (4) Yes, the value zero should not be a handle but an indication the request was completed synchronously. An edit is provided to add this. EDITS: In 9.5.1 Control information list, [187:2] "ID = " -> "ID = " [187:10+] Insert new BNF rule and constraint "R913a <> C908a (R913a) shall be have a decimal range no smaller than that of default integer." {Require default integer or larger.} In 9.5.1.8 ID= specifier in a data transfer statement [190:17] Change "This value" to "If this value is zero, the data transfer operation has been completed. A nonzero value" {Zero = "it was done synchronously already" value.} [190:18] After "operation." insert "This identifier is different from the identifier of any other pending data transfer operation for this unit." {Require uniqueness.} [206:18] Before "the identifier" insert "zero or". [206:20] After "operation" insert ", if any,". {Make ID=zero do nothing in WAIT.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-122 m183 F03/0113 Submitted 08-122r1 m183 Draft answer 08-122r2 m183 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0114 TITLE: Inconsistent restrictions on i/o specifiers KEYWORDS: I/O specifier, default logical DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: All of the i/o specifiers that return INTEGER values permit any kind of integer to be used, even though this is likely to cause problems with small integers. But all of the i/o specifiers that return LOGICAL values require "full-size" (default) logical variables, even though every kind of LOGICAL can represent every LOGICAL value, viz .TRUE. and .FALSE.. Should these be consistent, i.e. should every kind of LOGICAL be allowed for EXIST=, NAMED=, OPENED=, and PENDING=? ANSWER: Yes, these should have been consistent. Edits are provided. EDITS: Replace every occurrence of \si{default-logical-variable} in clause 9 with \si{logical-variable}. Delete the BNF definition of and constraint for \si{default-logical-variable} in clause 6. SUBMITTED BY: Malcolm Cohen HISTORY: 08-123 m183 F03/0114 Submitted 08-123r1 m183 make answer YES; Passed by J3 meeting ----------------------------------------------------------------------