08-163 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #16 Date: 2008 April 27 Here are the results of J3 letter ballot #16 on Fortran interpretations that officially closed 11-Apr-2008. The ballot is in J3 paper 08-141 for meeting #184. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 099 102 109 111 112 113 114 Michael Ingrassia no ballot received Shivarama Kokrady no ballot received Bill Long Y Y C C N Y Y Jeanne Martin no ballot received Dan Nagle Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y Y Matthijs van Waveren * Y Y Y Y N Y Y Stan Whitlock Y Y Y Y Y Y Y Jim Xia Y Y Y Y N Y C * ballot from alternate Toon Moene where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: Y = passed C = passed as amended N = needs further consideration F03 F03 F03 F03 F03 F03 F03 099 102 109 111 112 113 114 Y Y C c N Y C The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" will be reconsidered at J3 meeting #184 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". The edited interps in their DRFAT form are attached for use at meeting #184. /Stan ********************************************************************** F03/0109 Referencing deferred binding via absent dummy argument YES Comment for F03/0109 from Bill Long: I'm not sure at what point we made the change, but in f08 a has a rather than a . (Compare R741 on page 157 of 08-007r2 with [143:35] of 04-007.) In the edits section of the interp, for list item (12) we still have . If there is a different interp to fix this in f03, then this edit should be coordinated with that interp. Otherwise, it might be a good idea to include a "Note to the editor" that the edit should say when applied to f08, since this text is not near Clause 7 where this change occurred. Resolution for F03/0109: passed with change: Add the following at the end of the HISTORY: Note to Editor: The edit for bullet (12) should say "" instead of "" when applied to Fortran 2008. Compare R741 on page 157 of 08-007r2 with [143:35] of 04-007. F03/0111 Is defined assignment to a vector subscripted array allowed? YES Comment for F03/0111 from Bill Long: In the first paragraph following the QUESTION, "I does" should be "It does" at the beginning of the first sentence. Resolution for F03/0111: passed with change: Fix the typo. F03/0112 attributes allowed for dummy arguments in defined assignments NO Comment for F03/0112 from Bill Long: I find multiple problems with this interp answer. 1) At the end of the first paragraph of the ANSWER, the reference [363:6...] should be [263:6...]. 2) While the examples all use the POINTER attribute, the answer applies to both POINTER and ALLOCATABLE. I think the answer is wrong for the case of the ALLOCATABLE attribute for the second dummy variable. The corresponding actual argument is treated as "the right-hand side enclosed in parentheses" [263:11-12]. That is an expression, and does not have the allocatable attribute. But the rules for argument association at [269:25-26] unconditionally require that if the dummy is allocatable then the actual shall also be allocatable. Allowing allocatable on the second argument results in a contradiction. The ANSWER section reasoning, that "The standard places very few restrictions on the arguments to defined assignment subroutines..." is unconvincing. I agree that at the location cited (modulo fixing the page number) there are few requirements. That does not mean that all the other, general requirements for subroutines are somehow suspended just because they are not repeated there. For that matter, do we allow the dummy argument name to have 137 characters? It's not prohibited in the cited text. I think the ALLOCATABLE attribute should not be allowed, and is not allowed in the current f03 standard, for the second dummy variable. 3) The case for the POINTER attribute on the second dummy variable is slightly more interesting. This would be legal in f08. However, in f03 we still require that if the dummy is POINTER, the actual shall also have the POINTER attribute [269:14-15]. Since the interpretation is for f03, POINTER should be, and already is, disallowed for the second dummy variable. Therefore, I think the answer to question 1 should be no. I also think the NOTE: at the end of the interp should be deleted. In f08 we do allow POINTER, and I'm not convinced it is harmful. NO Comment for F03/0112 from Toon Moene: I agree with Bill Long's reasoning. NO Comment for F03/0112 from Jim Xia: I agree with Bill that POINTER/ALLOCATABLE attributes should not be allowed for the second dummy argument in declaration of a defined assignment. Resolution for F03/0112: Failed letter ballot Do make the change to correct [263:6...]. F03/0114 Inconsistent restrictions on i/o specifiers YES Comment for F03/0114 from Jim Xia: First of all, this is not really an interp because there is nothing ambiguous here. Also it would be helpful to list all the occurrences of the word in Clauses 6 and 9 so one can easily see what has been updated. Resolution for F03/0114: passed with change The references to are listed. ---------------------------------------------------------------------- NUMBER: F03/0099 TITLE: Clause 16 does not account for volatile variable KEYWORDS: volatile, defined, undefined DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 08-xxx m184 Passed by J3 letter ballot 08-141 ---------------------------------------------------------------------- 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 letter ballot 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 08-xxx m184 Passed by J3 letter ballot 08-141 ---------------------------------------------------------------------- NUMBER: F03/0109 TITLE: Referencing deferred binding via absent dummy argument KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 08-xxx m184 Passed by J3 letter ballot 08-141 Note to Editor: The edit for bullet (12) should say "" instead of "" when applied to Fortran 2008. Compare R741 on page 157 of 08-007r2 with [143:35] of 04-007. ---------------------------------------------------------------------- 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 letter ballot QUESTION: Is the assignment statement in subroutine cg1018 standard conforming? It 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 08-xxx m184 Passed by J3 letter ballot 08-141 ---------------------------------------------------------------------- NUMBER: F03/0112 TITLE: attributes allowed for dummy arguments in defined assignments KEYWORDS: defined assignment, dummy argument, attributes DEFECT TYPE: Clarification STATUS: J3 consideration in progress 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: [263: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 SUBMITTED BY: Jim Xia HISTORY: 08-120 m183 F03/0112 Submitted 08-120r1 m183 Create answer 08-120r2 m183 Passed by J3 meeting 08-xxx m184 Failed J3 letter ballot 08-141 NO Comment for F03/0112 from Bill Long and Jim Xia: POINTER/ALLOCATABLE attributes should not be allowed for the second dummy argument in declaration of a defined assignment. ---------------------------------------------------------------------- NUMBER: F03/0113 TITLE: Size and uniqueness considerations for ID= KEYWORDS: asynchronous I/O, ID=, size DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 08-xxx m184 Passed by J3 letter ballot 08-141 ---------------------------------------------------------------------- NUMBER: F03/0114 TITLE: Inconsistent restrictions on i/o specifiers KEYWORDS: I/O specifier, default logical DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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: Al edits are against 04-007. After the first paragraph in Clause 6, delete the BNF definition of and constraint for \si{default-logical-variable}: [103:17-18] delete R605 and C604 Replace every occurrence of \si{scalar-default-logical-variable} in clause 9 with \si{scalar-logical-variable}: [210:18] in 9.9.1 EXISTS= [210:25] in 9.9.1 NAMED= [210:28] in 9.9.1 OPENED= [210:30] in 9.9.1 PENDING= [212:24] in 9.9.1.10 EXISTS= [213:9 ] in 9.9.1.15 NAMED= [213:23] in 9.9.1.18 OPENED= [213:25] in 9.9.1.18 OPENED= {note: is not used in 9.9.1.20 PENDING= (page 214)] SUBMITTED BY: Malcolm Cohen HISTORY: 08-123 m183 F03/0114 Submitted 08-123r1 m183 make answer YES; Passed by J3 meeting 08-xxx m184 Passed by J3 letter ballot 08-141 ----------------------------------------------------------------------