11-129 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #22 Date: 2011 January 27 Here are the results of J3 letter ballot #22 on Fortran interpretations that officially closed 19-Nov-2010. The ballot is in J3 paper 10-254 for meeting #193. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F08 030 048 085 091 096 105 110 121 123 124 128 006 Robert Corbett N Y Y Y N Y Y C C N Y Y Bill Long C Y Y Y Y Y C Y Y Y Y Y Jeanne Martin/Malcolm Cohen no ballot received Dan Nagle no ballot received Toon Moene (*) Y Y Y Y Y Y C Y Y Y Y Y John Reid comment - - - - - - - - - - - - Van Snyder C C Y Y C C C c C N Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Jim Xia Y Y Y Y Y Y Y Y Y Y Y Y J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 040 041 042 043 044 045 046 047 048 049 Robert Corbett Y Y Y Y Y Y Y Y Y Y Bill Long Y C Y Y Y Y Y Y N C Jeanne Martin/Malcolm Cohen no ballot received Dan Nagle no ballot received Toon Moene (*) Y Y Y Y Y Y Y Y Y Y John Reid comment C N - - - - - - N - Van Snyder Y N C Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Jim Xia Y N Y Y Y N Y Y N Y * Toon is a voting alternate for Craig Rasmussen 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: F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F08 F08 F08 F08 F08 F08 030 048 085 091 096 105 110 121 123 124 128 006 040 041 042 043 044 C C Y Y C C C Y Y F Y Y C F Y Y Y F08 F08 F08 F08 F08 045 046 047 048 049 F Y Y F Y Y = passed C = passed as amended F = Failed J3 letter ballot The interps marked "C" pass with some minor fixes, as noted below. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F03/0030 IEEE divide by zero Robert Corbett's No vote on F03/0030: The proposed edits should be rejected because they do not have the desired meaning. The edits assume that if IEEE_SUPPORT_DATATYPE is true for the type of the operands of a real intrinsic operation, the operation will have the exception semantics of the corresponding operation defined by IEC 60559:1989. That is not the case. The definition of IEEE_SUPPORT_DATATYPE in Section 14.11.24 of 10-007 [417:8-17] might appear to specify the desired semantics. Nonetheless, the amplified specification given in the first paragraph of Section 14.9 [406:11-19] does not specify the desired semantics. Even if IEEE_SUPPORT_DATATYPE is true for a given argument, operations on real data with the same kind type parameter value need not have the exception semantics specified by IEC 60559:1989. The first paragraph of Section 14.9 does not specify the semantics of division, so it does not specify the exception semantics of division as defined by IEC 60559:1989. It specifies the semantics of addition, subtraction and multiplication only for operands and results that are normal numbers. Because an operation that signals an overflow or divide-by-zero exception does not produce a normal result, real addition, subtraction and multiplication are not required to have the exception semantics of the corresponding operations in IEC 60559:1989. The rules given in Clause 14 of 10-007 for determining when a real operation is assured to have the semantics of the corresponding operations in IEC 60559:1989 are complicated. Unless certain unstated assumptions are made, those rules are also incomplete. Those rules can be made rigorous, but Section 14.3 "The exceptions" is not where it should be done. I suggest replacing the definitions of the exceptions in Section 14.3 with proper definitions of the exceptions. I suggest specifying when the exceptions are signaled elsewhere. The definitions of the exceptions given in Clause 14 of 10-007 assume that the representable real values are symmetric about zero. While that is true for modern floating-point formats, it has not always been so. Definitions of the overflow and underflow exceptions that are correct for asymmetric floating-point formats will be longer than those currently provided. Bill Long's Comment on F03/0030: In the History section, 10-nnn should be 10-238r1. Van Snyder's Comment on F03/0030: Change "not true" to "false" because "not true" includes "undefined". This leaves the program non-conforming (presumably because the processor is defective) if the result is undefined. After [403:10-11] insert "14.3p1, second bullet". After [462:24+] insert "A.2p1". Malcolm replied to Van: > Change "not true" to "false" because "not true" includes "undefined". No it doesn't. > This leaves the program non-conforming (presumably because the > processor is defective) if the result is undefined. Being undefined is a property of a variable. IEEE_SUPPORT_DATATYPE is not a variable, it is a function. A function reference (other than a pointer-valued function) returns a value of the type. That does not include the concept of being undefined. Van replied to Malcolm: The "result variable" of a function is a variable. I found where the standard requires a value to be assigned to a function's result variable. I suspect you're right that there is not a standard-conforming way to do that, and leave the result undefined. Malcolm replied to Van: > The "result variable" of a function is a variable. However, we are talking about a function reference, not a reference to the result variable. According to the definition of "defined" (or indeed "undefined"), it is a concept that applies only to a data object, that is "constant, variable, or subobject of a constant". That is conspicuously lacking any mention of "function reference". And since these are supplied by the compiler (being part of an intrinsic module), there isn't any "result variable" anyway. > I found where the standard requires a value to be assigned to a > function's result variable. I suspect you're right that there is > not a standard-conforming way to do that, and leave the result > undefined. Not only is there no standard-conforming way, there is no way at all since *the result of evaluating a function reference is not a data object* by definition. result of ballot on F03/0030: Only Bill's change will be made as a result of these comments => F03/0030 passes as amended F03/0048 Control edit descriptors in UDDTIO Van Snyder's Comment on F03/0048: Change reference in the question to 9.6.4.8p26. In edits for [227:15], replace "section 9.6.4.8, in" by "9.6.4.8p25," or insert ", 25th paragraph," after "9.6.4.8". In edits for [227:17] and [227:18], replace "section 9.6.4.8" by "9.6.4.8p26" or insert ", 26th paragraph" after "9.6.4.8". In edits for [487:28] maybe replace "section C.6.2, first paragraph" by "C.6.2p1". result of ballot on F03/0048: Van's change will be made as a result of these comments => F03/0043 passes as amended F03/0085 Finalizing targets of pointer or allocatable actual arguments F03/0091 Array components cannot depend on length type parameters F03/0096 Can a read statement change the unit value? Robert Corbett's No vote on F03/0096: The new sentence The value of an or of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier shall not depend on any or . is problematic. For example, it will be unusual for the value assigned to a SIZE= specifier not to depend on any . I understand that the problem exists in the current text. I suggest splitting the specifiers into four categories, and treating each separately. The four categories are IN-specifiers, OUT-specifiers, IN/OUT-specifiers and run-time format expressions. The UNIT= specifier for an internal WRITE statement is the only IN/OUT-specifier in the current version of the language. The OUT-specifiers should be excluded from the text given in paragraph 5 of Section 9.12 [243:3-5]. The restrictions given in paragraphs 7-9 of Section 9.12 together with the restrictions on the side effects of expressions within a statement appear to be sufficient, but I might have missed something. Van Snyder's Comment on F03/0096: In the ANSWER, change "n the specifier" to "in the specifier". result of ballot on F03/0096: Only Van's change will be made as a result of these comments => F03/0096 passes as amended F03/0105 SIZE= specifier and UDDTIO Van Snyder's Comment on F03/0105: In the Discussion, change "9.5.1.14 [191:21-26]" to "9.6.2.15 [216:32-36]". Change "using list-directed" to "using a list-directed" result of ballot on F03/0105: Van's change will be made as a result of these comments => F03/0105 passes as amended F03/0110 Restoring dropped restriction on ENTRY Bill Long's Comment on F03/0110: I assume the title should be "Restoring dropped restriction on ENTRY " - at least that is what is in 10-248 and in 10-254 where the full interp is included. In the ANSWER section, the reference in 10-007 should be 310:5-8 (not 10:5-8). Toon Moene's Comment on F03/0110: Title is wrong, s/b: Restoring dropped restriction on ENTRY. Van Snyder's Comment on F03/0110: Change the title here to "Restoring dropped restriction on ENTRY" Stan Whitlock's remark about F03/110 in 10-254: Just FYI - Van is correct. The title of interp F03/0110 is incorrect in the vote summary in 10-254. It should be "Restoring dropped restriction on ENTRY" which is the title of interp F03/0110. result of ballot on F03/00110: The title of interp F03/0110 is "Restoring dropped restriction on ENTRY". Bill's change will be made as a result of these comments => F03/0110 passes as amended F03/0121 Precise FP semantics of the REAL intrinsic Robert Corbett's Comment on F03/0121: I agree with Van Snyder that users expect different semantics from those specified in the interpretation. I understand that the interpretation is how the members of the committee have interpreted the standard since the FORTRAN 77 standard. Van Snyder's Comment on F03/0121: This question keeps coming up, and the committees keep avoiding the most useful answer, i.e., the one the submitter (that is, a real user with a real problem) always asks for. Although the answer correctly interprets the standard, the result is to force the programmer to use a mysterious kludge. Hopefully, some future revision of the standard actually will require REAL with a KIND argument to produce a result of the specified kind, not one of whatever representation the processor happens to find handy. result of ballot on F03/0121: No change will be made as a result of these comments => F03/0121 passes unchanged F03/0123 Implicit typing in derived types Robert Corbett's Comment on F03/0123: When I began investigating the issue described in the request for interpretation, I compiled and ran my examples using eight different compilers. All eight compilers successfully compiled my code. Four of the compilers moved the implicit declaration to the enclosing scoping unit. Four of the compilers restricted the scope of the implicit declaration to the scoping unit that is the derived type definition. Oracle's implementation works as specified in the interpretation, so I voted for the interpretation. Nonetheless, I think the interpretation misses an opportunity to improve the language. Implicit typing should have been banned in derived type definitions. The standard states The data entity is treated as if it were declared in an explicit type declaration in the outermost inclusive scope in which it appears. An explicit type declaration is not allow in a derived type definition. Therefore, under a strict interpretation of the standard, the code would be considered not to be standard conforming. Van Snyder's Comment on F03/0123: Does this beg for another interpretation request with IMPLICIT NONE in the main program? result of ballot on F03/0123: No change will be made as a result of these comments => F03/0123 passes unchanged F03/0124 definition is poorly defined Robert Corbett's No vote on F03/0124: I agree with Malcolm Cohen that the new text is a big improvement over the existing text. However, I also take Van Snyder's point that there is further room for improvement. I think with a bit more work in Section 16.6 of 10-007, an interpretation that covers all the cases that should be allowed could be achieved. Van Snyder's No vote on F03/0124: The answer implied by the edits is too restrictive. It should be something like "When a component of a structure of numeric sequence type or character sequence type becomes defined as a result of partially associated objects becoming defined, associated components of the same type that are components of an object of different type do not become undefined." (This is ugly and will need some polishing, but you get the idea.) Malcolm replied to Van: The answer is less restrictive than the text currently in the standard, in that it adds another exception to the blanket requirement. It would help if you supplied an example you think remains non-conforming after this change but that you think should be conforming. Reading your proposed replacement text I am at a loss to see how the effect of it differs from that in the interp. (If there is a difference, I'm sure I could work it out eventually, but you must have something in mind already, right?) Van replied to Malcolm: I had in mind the case of common block declarations resulting in partial and overlapping storage associations of numeric sequence type objects in such a way that their ultimate storage-associated components have the same types and kinds. That is, defining any component wouldn't undefine anything. Suppose for example that in one scoping unit there is a common block with two numeric sequence type objects, each having two default integer components. In another there is the same common block with a default integer, a sequence type object with two default integer components, and another default integer. Assigning to any of the numeric sequence objects shouldn't undefine anything. result of ballot on F03/0124: /interp will take this back for more work to solve the closely-related problem raised by Van. We probably will be editing the same text to solve Van's extra problem => F03/0124 fails. F03/0128 Subobjects in namelist output F08/0006 generic resolution with banned argument combinations F08/0040 MOVE_ALLOC for coarrays John Reid's Comment on F08/0040: The edit that I suggested in 10-200 was [372] In 13.7.118 MOVE_ALLOC (FROM, TO), paragraph 3. In line 1, after "It shall be allocatable." add "It shall not be a coarray." In line 2, after "It shall be allocatable." add "It shall not be a coarray." This was carefully worded to be suitable for a future corrigendum, except for "[372]" which can be removed. I think the replacement In 13.7.118 MOVE_ALLOC (FROM, TO), paragraph 3: [372:18] After "It shall be allocatable." add "It shall not be a coarray." [372:19] After "It shall be allocatable." add "It shall not be a coarray." is less satisfactory since it relies on line numbers in the J3 document. result of ballot on F08/0040: 006 is a J3 document and it uses line numbers. We have started adding section and paragraph indications to make WG5 corrigenda easier to construct. Improvements are made to the edit wording as a result of these comments => F08/0006 passes as amended F08/0041 Segment ordering rules Bill Long's Comment on F08/0041: In PROGRAM example1, the declaration of the p component of type t2 should be TYPE(t1),POINTER :: P, and not TYPE(T2)... I suspect this is just a typo. The current version results in errors later (y%p => x has mismatched types.) John Reid's NO vote on F08/0041: There are errors in both examples. In example (1), the component of type t2 should have type t1. In example (2), the PRINT statement should reference x on another image, e.g. PRINT *, x(1)[2]. More seriously, the edit proposed in 10-201 has been removed. While it is not necessary for allocation, it is needed for pointer association. This means that it is desirable to rewrite the questions and answers. Here is my suggestion QUESTION: (1) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in nordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,x(1)[2] ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). (2) Was it intended to allow a pointer assignment to a pointer that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t REAL,POINTER :: p END TYPE REAL,TARGET :: a=0.0, b=1.0 TYPE(t) :: y[*] y%p => a ! y[n]%p => a for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN y%p => b ! y[1]%p => b ELSE y[1]%p = 999 ! Defines a[1] or b[1]? END IF END PROGRAM ANSWER: (1) No. This case has been overlooked in the segment ordering rules. An edit is supplied to correct this. (2) No. This case, too, has been overlooked in the segment ordering rules. An edit is supplied to correct this. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and". Van Snyder's No vote on F08/0041: "is defined" is a static concept. The requirement should always have been "becomes defined". Therefore the edit should be to replace "variable is defined" to "variable becomes defined or undefined" -- or do we need another interp to repair this? Jim Xia's No vote on F08/0041: The first example should be fixed to have t2 contains a pointer component of type t1. The second example is perfectly legal. Seems we need to rework on this interp. result of ballot on F08/0041: In example (1), the component of type t2 is changed to type t1. However, more work is needed on this interp as a result of these comments => F08/0041 fails. The edit in 10-201 referred to above is: [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and" F08/0042 SOURCE= questions Van Snyder's Comment on F08/0042: To avoid future questions of the type "how many times is ... evaluated?" can we specify that the values of specifiers are considered to be actual arguments to subroutines, so that the execution semantics of CALL statements, i.e., the actual arguments are evaluated before the invocation, apply everywhere? result of ballot on F08/0042: No change will be made as a result of these comments => F08/0042 passes unchanged F08/0043 Executing a type-bound procedure on a coindexed object F08/0044 Resolving the type of a coarray or coindexed object F08/0045 constraints on entities of type LOCK_TYPE Jim Xia's No vote on F08/0045: The edits makes it illegal to specify LOCK_TYPE as if the coarray itself is of LOCK_TYPE. For example, type(lock_type), allocatable :: locks[*] The edits make the following allocate statement illegal ALLOCATE (LOCK_TYPE: locks[*]) result of ballot on F08/0045: /interp will take this back for more work since we think that Jim has a valid complaint => F08/0045 fails Perhaps the edit should be changed to [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", or a type with a direct component of type LOCK_TYPE (13.8.2.16) that is not a direct component of the declared type of any ,". [127:7+] Insert new constraint "C641a (R626) If an is unlimited polymorphic, shall not specify the type LOCK_TYPE (13.8.2.16)." F08/0046 VALUE attribute restrictions F08/0047 public generic with same name as private type F08/0048 Sequence association for coarrays Bill Long's No vote on F08/0048: The proposed restriction on coarrays as actual arguments sequence associated with a contiguous dummy makes yet another exception to ordinary array behavior for coarrays. In this case, there seems to be no justification other than the view that sequence association of arguments is archaic. I think that the confusion introduced by making another case where coarrays are different from ordinary arrays is less desirable that allowing coarrays to behave like "old" arrays. John Reid's NO vote on F08/0048: Sequence association is allowed for array coarrays, so I can see no reason for disallowing it for a scalar coarray that is an element of a simply contiguous array. 12.5.2.4 para 13 says: "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array." As the standard stands, I believe that this applies. It is made not to apply by the new edit: "If the dummy argument is a coarray that is an array, the actual argument shall be an array." I think this is a technical change that contradicts one of our design principles: wherever possible, coarrays should behave just like variables that are not coarrays. I suggest that we go back to 10-226 which contains the edit In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:9], add "or an element of a simply contiguous array". Jim Xia's No vote on F08/0048: I believe this restriction might be a bit surprising to users who regularly use sequence associations. Also there isn't an apparent technical difficulties in support this. result of ballot on F08/0048: More work is needed on this interp as a result of these comments => F08/0048 fails. F08/0049 ELEMENTAL functions with nonconstant type parameters Bill Long's Comment on F08/0049: In the example code, the function gcd(..) is type REAL, but a reference to it is used later to be the len parameter value in a character(gcd(..)) declaration. The function gcd should be modified to return an integer result. If there is interest, this is an executable version of the test case: MODULE ex1 INTEGER :: mylen CONTAINS ELEMENTAL CHARACTER(mylen) FUNCTION f(a) INTEGER,INTENT(IN) :: a f = REPEAT(CHAR(a),mylen) END FUNCTION END MODULE ELEMENTAL FUNCTION ex2(a,b) CHARACTER(*),INTENT(IN) :: a,b CHARACTER(LEN(a)+LEN(b)) :: ex2 ex2 = a//b END FUNCTION MODULE ex3 INTEGER,ALLOCATABLE :: x(:) CONTAINS PURE FUNCTION gcd(a) INTEGER,INTENT(IN) :: a(:) integer :: gcd gcd = sum(a) END FUNCTION ELEMENTAL FUNCTION f(y,z) CHARACTER(*),INTENT(IN) :: y,z CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f f = "1234567890" END FUNCTION END MODULE program test call test1 call test2 end program test subroutine test1 use ex1 mylen=10 print *, f(ichar("x")) end subroutine test1 subroutine test2 use ex3 allocate(x(3)) x = [1,1,1] print *, f("11","222") end subroutine test2 with output: > ./a.out xxxxxxxxxx 12345678 result of ballot on F08/0049: Only Bill's change to declare gcd a INTEGER will be made as a result of these comments => F08/0006 passes as amended ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS: Page and line numbers refer to 10-007. [403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW), Replace with "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the result of the operation or conversion, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. It occurs in an intrinsic real exponentiation as determined by the processor. It occurs in a complex operation, or conversion by the intrinsic function CMPLX, if it is caused by the calculation of the real or imaginary part of the result." [403:10-11] Replace with "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the result of the division, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. It is processor-dependent whether it occurs in a real exponentiation with a negative exponent. It occurs in a complex division if it is caused by the calculation of the real or imaginary part of the result." [462:24+] Insert new bullet points "- the conditions under which IEEE_OVERFLOW is raised in a calculation involving non-IEC 60559:1989 floating-point data; - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are raised in a floating-point exponentiation operation; - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a calculation involving non-IEC 60559:1989 floating-point data;" SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 F03/0030 submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 10-238r1 m193 Revised answer - Passed J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i = 0 CONTAINS PROCEDURE, PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE CONTAINS RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, '(i1, /)') dtv%i WRITE(unit, '(t1, a2)') 'AB' END SUBROUTINE pwf END MODULE PROGRAM foo USE m IMPLICIT NONE TYPE(t) :: a a%i = 3 PRINT *, 'xyz', a end program 9.6.4.8p26 [227:17] states A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. The term "record position" is used, but it doesn't appear to be defined anywhere. Depending on the interpretation, the above program might be standard-conforming, or it might not be. If "record position" is taken to mean "the position within the current record", regardless of which record is the current record, then the record position at the beginning of the UDDTIO procedure is before the fourth character of the record. The first child data transfer statement begins a new record, and the second child data transfer statement writes to the first character of the new record. This would be before the "record position" at the time the UDDTIO procedure was invoked, and the program would not be standard-conforming. If "record position" is taken to mean a combination of the record and the position within that record (essentially making it mean the same thing as "file position"), then the above program is standard- conforming, since the control edit descriptor doesn't cause the file to be positioned before the record position when the UDDTIO procedure was invoked. What is the meaning of "record position", and is the above program standard-conforming? ANSWER: The term "record position" is not well defined. The intent of 9.6.4.8 was to prohibit a child data transfer statement from possibility overwriting or re-reading any characters in the current record that an active parent I/O statement had previously written or read. 9.6.4.8 should have used the term "file position" instead of "record position". Therefore, the program is standard-conforming, and prints xyz.3 AB where the first record starts with a space and the "." represents a value separator. Edits are supplied to clarify the intent of 9.6.4.8 and remove the phrases "record position" and "record positioning" from the standard. EDITS: In 10-007 [227:15] In section 9.6.4.8p25, in the paragraph that begins with "Because a child data transfer statement does not position the file prior to data transfer," replace "effective item or record positioning edit descriptor" with "effective item or edit descriptor" [227:17] In section 9.6.4.8p26, replace the phrase "A record positioning edit descriptor, such as TL and TR," with "The edit descriptors T and TL" [227:18] Change "record position" to "file position" twice. [487:28] In section C.6.2p1, delete "record positioning" SUBMITTED BY: Rob James HISTORY: 05-139 m171 F03/0048 submitted 05-139r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-167 06-366r2 m178 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 10-241 m193 Draft answer for F2008 10-241r1 m193 Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0085 TITLE: Finalizing targets of pointer or allocatable actual arguments KEYWORDS: Finalization, pointer actual argument, allocatable actual argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program program Finalize type :: T ... contains final :: ... end type T type(t), pointer :: TV allocate ( TV ) call sub ( TV ) contains sub ( A ) type(t), intent(out) :: A end sub A end program Finalize The eighth paragraph of 10-007, section 4.5.6.3 [76:30-31], says "When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument corresponding to an INTENT(OUT) dummy argument is finalized.'' Q1. Is the target of TV finalized when SUB is invoked? Q2. If TV were allocatable instead of a pointer, would it be finalized? ANSWER: A1. Yes A2. Yes It was intended that an allocatable actual argument or the target of a pointer actual argument that is associated with an INTENT(OUT) dummy argument be finalized when the procedure is invoked. Edits are provided to correct the error. EDITS: In 10-007 Replace the eighth paragraph of 4.5.6.3 [76:30-31] with: "When a procedure is invoked, an object that becomes argument associated with a nonpointer, nonallocatable INTENT(OUT) dummy argument of that procedure is finalized." SUBMITTED BY: Van Snyder HISTORY: 06-374 m178 F03/0085 submitted 10-242 m193 Draft answer for F2008 - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t(n) INTEGER,LEN :: n REAL v(n) END TYPE END Is the example intended to be standard-conforming? ANSWER: Yes, the example is standard-conforming in F2008. C531 in section 5.3.8.2 [94:15-16] of 10-007 says: "C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, BLOCK construct, or interface body." EDITS: None SUBMITTED BY: Van Snyder HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen) 10-243 m193 Draft answer for F2008 - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is it allowed to change the value of a variable which supplies the unit number to an read statement? 10-007 [243:3-5] says the value of any input/output specifier shall not depend on any input-item. UNIT= is a specifier in a READ statement. Note 9.40 on page 221 gives the example READ(N) N, X(N) and discusses how the changes to N work. ANSWER: Yes, the example was intended to be allowed as long as N is not an internal unit. Edits will limit the restriction to "output items" in the specifier list and the Format. EDITS: In 10-007 In 9.12, paragraph 5, [243:3-4] Delete "on any , , or", Making that sentence read: "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." [243:5] Append new sentence to paragraph "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier shall not depend on any or ." SUBMITTED BY: Dick Hendrickson HISTORY: 07-266 m181 F03/0096 submitted 07-266r1 m181 Draft answer - withdrawn, no reason, no vote 10-246 m193 Draft answer for F2008 10-246r1 m193 Revised edit - Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot DISCUSSION: 9.6.2.15p1 [216:32-36] says that when SIZE= specifier is used in a formatted input statement with explicit format specifications, the variable specified in the SIZE= specifier is determined by the data edit descriptors during the input statement. These rules, however, did not take into account the following situation where a parent READ statement with a DT edit descriptor invokes a user-defined DTIO formatted read subroutine that reads input data using a list-directed or namelist READ statement. Consider the following example: module example type A integer x(10) contains procedure :: readArray generic :: read(formatted) => readArray end type contains subroutine readArray (dtv, unit, iotype, v_list, iostat, iomsg) class(A), intent(inout) :: dtv integer, intent(in) :: unit character(*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(*), intent(inout) :: iomsg read (unit, fmt=*, iostat=iostat, iomsg=iomsg) dtv%x end subroutine end module program test use example type(A) :: v integer countChar open (1, file='example.input', form='formatted') read (1, fmt='(DT)', advance='no', size=countChar) v end program test Note that there is no data edit descriptor in the UDDTIO subroutine, readArray, to count the total number of characters transferred during the child read. QUESTION: Is this example intended to be standard conforming? ANSWER: Yes, the example is standard-conforming. The definition of SIZE= in [10-007 216:31] section 9.6.2.15 does not restrict SIZE= if a child I/O is present. The description of how SIZE= works in [219:25] section 9.6.4.1p22 item (9) clearly indicates that SIZE= should be set even if child I/O occurs (items (5) and (6)). EDITS: None SUBMITTED BY: Jim Xia HISTORY: 07-302 m182 F03/0105 submitted 07-302r1 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 10-247 m193 Draft answer for F2008 - Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: It appears that a hard restriction found in ANSI X3.9-1978 was dropped when we published Fortran 90. The restriction on page 15-13 of the FORTRAN 77 standard says >In a function subprogram, a variable name that is the same >as an entry name must not appear in any statement that >precedes the appearance of the entry name in an ENTRY >statement, except in a type-statement. so FUNCTION S() T = 13.0 ENTRY T() END is not standard-conforming. The restriction appears to be missing from Fortran 90, 95, 2003. Should it still be in force ? ANSWER: No, for whatever reason, the restriction was dropped a long time ago and is not in F2008. The above program does not violate the standard with the placement of the assignment to T. [10-007 310:5-8] Section 12.6.2.6 specifies that the results S and T in the above example share the same memory so S() returns 13.0. As is, the example is not standard- conforming since no return value is set for T(). EDITS: None SUBMITTED BY: Michael Ingrassia HISTORY: 07-341 m182 F03/0110 submitted 10-248 m193 Draft answer for F2008 - Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Must the intrinsic function REAL with KIND parameter wp return a value that is a REAL (KIND=wp) floating point number? RATIONALE FOR THE QUESTION: Computer hardware may use a wider floating-point format for registers than for memory; e.g., 80 bits for registers and 64 bits for memory for the case of standard double precision floating point numbers. Some algorithms require a high level of control over floating point semantics. If the intrinsic function REAL with KIND parameter wp is guaranteed to return a REAL (KIND=wp) result then a programmer can use this to force intermediate results into main memory format, never mind that the optimizing compiler may have placed the intermediate in a register. I am interested in a J3 interpretation of this matter, especially a loud and clear affirmative interpretation, because it appears that some present Fortran compilers optimize away my explicit use of the REAL intrinsic. The context is code for compensated summation (Kahan summation). I appreciate that parentheses are inviolable courtesy of the Fortran standard, but in order to have code that cannot be broken by an optimizing compiler I seem to need also a language mechanism to force intermediate results into main memory format. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANSWER: Yes, the result of the intrinsic function REAL with KIND argument wp returns a value that is of type REAL(KIND=wp). However, the description of REAL says that in this case "the result is equal to a processor-dependent approximation to A". Furthermore, if it is used within an expression involving intrinsic operations, "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." and "mathematically equivalent expressions of numeric type may produce different computational results", which means that it is unlikely to serve your purpose. Intermediate results can be rounded to storage format by using assignment to a VOLATILE variable. EDIT: None. HISTORY: 08-208r1 m185 F03/0121 submitted 10-240 m193 Draft answer for F2008 - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Consider the program PROGRAM MAIN TYPE T INTEGER :: I = BIT_SIZE(J) END TYPE ! J = 0 CALL SUBR1 CONTAINS SUBROUTINE SUBR1 J = 1 CALL SUBR2 PRINT *, J END SUBROUTINE SUBROUTINE SUBR2 J = 2 END SUBROUTINE END Q1. Is this program standard-conforming? (In particular, is it permitted to have the first, or only, appearance of a local variable name appear within a type definition. The definition of implicit typing says that J is explicitly declared within T.) Q2. (a) If not, is it standard-conforming if the comment "! J = 0" is turned into the assignment statement "J = 0"? (b) If it is standard-conforming, what does it print? (If J is a local variable of MAIN, it should print 2.) ANSWER: A1. Yes, the program is standard-conforming. The definition of implicit typing is erroneous - J is a local entity of MAIN. An edit is supplied to correct this error. A2. (a) Not applicable. (b) The program will print the value 2. EDITS to 10-007: [109:22-23] In 5.5p4, After "The data entity is treated as if it were declared in an explicit type declaration" replace "in" with "; if", then after "the outermost inclusive scope in which it appears" insert "is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". Note: This makes the whole sentence read "The data entity is treated as if it were declared in an explicit type declaration; if the outermost inclusive scope in which it appears is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-268 m185 F03/0123 submitted 10-244 m193 Revised answer - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: definition is poorly defined KEYWORDS: definition DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the program: PROGRAM MAIN TYPE T1 SEQUENCE INTEGER I, J END TYPE TYPE T2 SEQUENCE INTEGER I, J END TYPE TYPE(T1) X TYPE(T2) Y EQUIVALENCE (X, Y) X%I = 1 X%J = 2 PRINT *, X, Y END Is this program standard-conforming, and if so, what does it print? According to items (1) and (12) of 16.6.5, the assignment to X%I causes both X%I and Y%I to become defined. Similarly, the assignment to X%J causes both X%J and Y%J to become defined. Then, according to item (15) of 16.6.5, both X and Y become defined. However, according to 4.5.2.4, X and Y are types with different names, and therefore are of different type, thus according to 16.6.6 item (1) when X becomes defined Y becomes undefined, and vice versa. This appears to be a contradiction. ANSWER: The program was intended to be standard-conforming. An edit is supplied to remove the apparent contradiction. The program should print something like " 1 2 1 2". EDITS: [455:14+] In 16.6.6 item (1), insert new sub-list item "(c) When all components of a structure of a numeric sequence type or character sequence type become defined as a result of partially associated objects becoming defined, an associated variable of a different type does not become undefined." SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted 10-245 m193 Draft answer - Passed by J3 meeting 11-xxx m194 Failed J3 letter ballot #22 10-254 ** start negative comments Robert Corbett's No vote on F03/0124: I agree with Malcolm Cohen that the new text is a big improvement over the existing text. However, I also take Van Snyder's point that there is further room for improvement. I think with a bit more work in Section 16.6 of 10-007, an interpretation that covers all the cases that should be allowed could be achieved. Van Snyder's No vote on F03/0124: The answer implied by the edits is too restrictive. It should be something like "When a component of a structure of numeric sequence type or character sequence type becomes defined as a result of partially associated objects becoming defined, associated components of the same type that are components of an object of different type do not become undefined." (This is ugly and will need some polishing, but you get the idea.) Malcolm replied to Van: The answer is less restrictive than the text currently in the standard, in that it adds another exception to the blanket requirement. It would help if you supplied an example you think remains non-conforming after this change but that you think should be conforming. Reading your proposed replacement text I am at a loss to see how the effect of it differs from that in the interp. (If there is a difference, I'm sure I could work it out eventually, but you must have something in mind already, right?) Van replied to Malcolm: I had in mind the case of common block declarations resulting in partial and overlapping storage associations of numeric sequence type objects in such a way that their ultimate storage-associated components have the same types and kinds. That is, defining any component wouldn't undefine anything. Suppose for example that in one scoping unit there is a common block with two numeric sequence type objects, each having two default integer components. In another there is the same common block with a default integer, a sequence type object with two default integer components, and another default integer. Assigning to any of the numeric sequence objects shouldn't undefine anything. result of ballot on F03/0124: /interp will take this back for more work to solve the closely-related problem raised by Van. We probably hwill be editing the same text to solve Van's extra problem => F03/0124 fails. ** end negative comments ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended to disallow vendors to provide namelist output that includes a subobject designator followed by a value? ANSWER: Yes. The processor is required to produce output in the form specified by 10.11.4.3 "Namelist output records". 10.11.4.3 paragraph 2 states "The name of each namelist group object list item is placed in the output record followed by an equals and a list of values of the namelist group object list item." This unambiguously states that each namelist group object list item (these are the ones listed in NAMELIST statements) have their names placed in the output record followed by an equals sign and the list of their values. Subobject designators do not appear in NAMELIST statements. EDIT: None. SUBMITTED BY: John Reid HISTORY: 09-115 m187 F03/0128 submitted 09-115r1 m187 Passed by J3 meeting + F2008 fix {pulled} 09-187r2 m188 Failed J3 letter ballot #18 09-155: accept edit line number change, F2008 fix from m187 does not appear in 09-007r1; 10-239 m193 Revised answer - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0006 TITLE: Generic resolution, intrinsic procedures, and host association KEYWORDS: intrinsic, generic, host association DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The specifications of some intrinsic functions and subroutines explicitly ban certain combinations of arguments, even though those combinations are included in the title and the argument portion of the specification of the function or subroutine. Examples include CMPLX and RANDOM_SEED. Other requirements include being a valid KIND type parameter value (e.g. INT) or having having character length 1 (e.g. ICHAR). Consider the program fragment PROGRAM p INTERFACE cmplx LOGICAL FUNCTION mycmplx(a,b) COMPLEX a REAL b END END INTERFACE INTERFACE random_seed SUBROUTINE my_random_seed(get,put,size) INTEGER,OPTIONAL :: get(:),put(:),size END SUBROUTINE END INTERFACE INTERFACE int INTEGER FUNCTION myint(i,j) END END INTERFACE COMPLEX :: z = (1,2) REAL :: r = 3 CALL check CONTAINS SUBROUTINE check INTRINSIC int,cmplx,random_seed PRINT *,cmplx(z,r) ! Reference (1). CALL random_seed(GET=a,PUT=b) ! Reference (2). PRINT *,int(3,17) ! Reference (3). END SUBROUTINE END PROGRAM Are the procedure references (1), (2), and (3) invalid references to the intrinsic procedures CMPLX, RANDOM_SEED, and INT, or are they valid references to the user procedures mycmplx, my_random_seed, and myint respectively? ANSWER: Reference (1) is a valid reference to the user procedure. Both references (2) and (3) are invalid references to the intrinsic procedures; however, no constraints are violated so a standard- conforming processor may do anything, including treating them as references to the user procedures. DISCUSSION: 12.5.5.2 paragraph 4 explains that the reference is to the intrinsic procedure if it is "consistent with the interface of that intrinsic procedure". The interface to an intrinsic procedure consists of its name, characteristics, and dummy argument names. The characteristics of a procedure as defined by 12.4.1 do not include arbitrary restrictions such as those for RANDOM_SEED which are on argument presence (an execution time concept). Nor are requirements such as an actual argument being required to be a constant expression part of an interface. In the case of CMPLX however, there is no specific version whose interface has an X argument of type COMPLEX and any Y argument. 13.7.36 describes this by "If X is of type complex, no actual argument shall correspond to Y". Therefore the reference to CMPLX with such arguments is not consistent with the intrinsic. EDITS to 10-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-153 m192 F08/0006 submitted 10-153r1 m192 Draft answer 10-153r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Amended by J3 letter ballot 10-199; failed J3 letter ballot 10-199 10-236 m193 Revised answer for F2008 10-236r1 m193 Revised example - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: No. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray; therefore MOVE_ALLOC would need to be an image control statement for consistency with the DEALLOCATE statement. An edit is supplied to clarify this. EDIT: In 10-007 In 13.7.118p3 MOVE_ALLOC (FROM, TO): [372:18] After "It shall be allocatable." in FROM, add "It shall not be a coarray." [372:19] After "It shall be allocatable." in TO, add "It shall not be a coarray." SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0041 TITLE: Segment ordering rules KEYWORDS: segment, allocation DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) Was it intended to allow the allocation of a variable that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t1 REAL,ALLOCATABLE :: c(:) END TYPE TYPE t2 TYPE(t1),POINTER :: p END TYPE TYPE(t1),TARGET :: x TYPE(t2) :: y[*] y%p => x ! y[n]%p => x[n] for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN ALLOCATE(x%c(1000)) ! Allocates x[1]%c. ELSE y[1]%p%c(THIS_IMAGE()) = 999 ! Defines some part of x[1]%c. END IF END PROGRAM (2) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in unordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,SUM(x) ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). ANSWER: (1) No, this example violates the requirement of the first bullet in paragraph 3 of 8.5.2, which says: "if a variable is defined on an image in a segment, it shall not be referenced, defined, or become undefined in a segment on another image unless the segments are ordered". x[1]%c is defined in segment 2 by images 2-N, but is made undefined on image 1 (allocation makes a variable undefined except when default initialization occurs). (2) No, this example was not intended to be standard-conforming. An edit is supplied to clarify the intent. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). {Forbid uncoordinated undefinings of variables.} SUBMITTED BY: John Reid HISTORY: 10-201 m193 F08/0041 submitted 10-201r1 m193 Revised - Passed by J3 meeting 11-xxx m194 Failed J3 letter ballot #22 10-254 ** start negative comments John Reid's NO vote on F08/0041: There are errors in both examples. In example (1), the component of type t2 should have type t1. In example (2), the PRINT statement should reference x on another image, e.g. PRINT *, x(1)[2]. More seriously, the edit proposed in 10-201 has been removed. While it is not necessary for allocation, it is needed for pointer association. This means that it is desirable to rewrite the questions and answers. Here is my suggestion QUESTION: (1) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in unordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,x(1)[2] ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). (2) Was it intended to allow a pointer assignment to a pointer that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t REAL,POINTER :: p END TYPE REAL,TARGET :: a=0.0, b=1.0 TYPE(t) :: y[*] y%p => a ! y[n]%p => a for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN y%p => b ! y[1]%p => b ELSE y[1]%p = 999 ! Defines a[1] or b[1]? END IF END PROGRAM ANSWER: (1) No. This case has been overlooked in the segment ordering rules. An edit is supplied to correct this. (2) No. This case, too, has been overlooked in the segment ordering rules. An edit is supplied to correct this. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and". Van Snyder's No vote on F08/0041: "is defined" is a static concept. The requirement should always have been "becomes defined". Therefore the edit should be to replace "variable is defined" to "variable becomes defined or undefined" -- or do we need another interp to repair this? Jim Xia's No vote on F08/0041: The first example should be fixed to have t2 contains a pointer component of type t1. The second example is perfectly legal. Seems we need to rework on this interp. result of ballot on F08/0041: In example (1), the component of type t2 is changed to type t1. However, more work is needed on this interp as a result of these comments => F08/0041 fails. The edit in 10-201 referred to above is: [189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by "if the allocation or the pointer association status of a variable is changed on an image in a segment, that variable shall not be referenced or defined in a segment on another image unless the segments are ordered, and" ** end negative comments ---------------------------------------------------------------------- NUMBER: F08/0042 TITLE: SOURCE= questions KEYWORDS: ALLOCATE, SOURCE= DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program PROGRAM example1 REAL,ALLOCATABLE :: x(:),y(:) ALLOCATE(x(10),y(10),SOURCE=3.14159265) PRINT *,x,y END This program does not conform to Fortran 2003 due to constraint C631 which stated "If SOURCE= appears, ... shall contain only one ...". The corresponding constraint in Fortran 2008, C638, is missing this requirement, so apparently the program is now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention this as a new feature. Furthermore, 6.7.1.1 paragraph 4 begins "If is a coarray, shall not have a dynamic type of ..." which implies that there is only one for a (at least when the is a coarray). Similarly, the wording of constraint C639 implies a one-to-one correspondence between and . Q1. Is the omission of the single allocation requirement of Fortran 2003 an oversight? (i.e. is example1 non-conforming?). Also, consider the program PROGRAM example2 REAL,ALLOCATABLE :: x[:] ALLOCATE(x) x = 3 END The ALLOCATE statement appears not to conform to Fortran 2008 because of 6.7.1.1 paragraph 4; since does not appear, it cannot satisfy any condition about its dynamic type. Q2. Is an ALLOCATE statement for a coarray required to have SOURCE=? (i.e. is example2 non-conforming?). Also, if multiple allocations with SOURCE= are permitted, consider the program PROGRAM example3 INTEGER,ALLOCATABLE :: x,y ALLOCATE(x,y,SOURCE=f()) PRINT *,x,y CONTAINS INTEGER FUNCTION f() INTEGER,SAVE :: n = 1 f = n n = n + 1 END FUNCTION END PROGRAM The execution semantics of SOURCE= in 6.7.1.2 paragraph 7 do not state whether the is evaluated once per statement or once per allocation. If the processor evaluates per statement execution, something like " 1 1" will be printed, but if it evaluates it per allocation, something like " 1 2" could be printed. Q3. How many times may be evaluated in an ALLOCATE statement with multiple allocations? Also, consider the program PROGRAM example4 REAL,ALLOCATABLE :: x(:) ALLOCATE(x,SOURCE=[0.5,1.5]) PRINT *,x END PROGRAM The Introduction implies that this program should be standard- conforming, but it violates constraint C633, which begins "(R631) If is an array either shall appear or shall appear ..." The requirements of C633 are not satisfied because R631 is and does not appear in R631. Q4. Is example4 intended to be standard-conforming? ANSWER: The answer to question 1 is No. This feature was deliberately added to the Fortran 2008 standard. Edits are supplied to correct its exposition. The answer to question 2 is No. An edit is supplied to correct paragraph 4 of 6.7.1.1. The answer to question 3 is once. An edit is supplied to clarify paragraph 7 of 6.7.1.2. The answer to question 4 is Yes. An edit is supplied to correct constraint C633. EDITS: {to 10-007} [xiii] Introduction, bullet "Data usage and computation", Before "MOLD=" Insert "Multiple allocations are permitted in a single ALLOCATE statement with SOURCE=." {(Q1) Add new feature to the feature list.} [126:31-33] Replace C633 entirely with the constraints "C633 (R626) If an is an array, either shall appear in its or shall appear in the ALLOCATE statement. C633a (R631) If is scalar, shall not appear." {(Q4) Fix broken constraint.} [127:5] Constraint C639, replace entirely with "C639 (R626) If appears, the kind type parameters of each shall have the same values as the corresponding type parameters of ." {(Q1) Fix singular implication. Avoid introducing any implication that each has the same set of kind type parameters or that any has the same set of kind type parameters as the - the relationship is a subset.} [127:18] 6.7.1.1 paragraph 4, replace entirely with "If has a dynamic type of C_PTR, C_FUNPTR, LOCK_TYPE, or has a subcomponent whose dynamic type is LOCK_TYPE, no in that statement is permitted to be a coarray." {(Q2) Fix implied requirement of SOURCE= appearance for coarrays.} [128:26] 6.7.1.2 paragraph 7, append new sentence "The is evaluated exactly once for each execution of an ALLOCATE statement." {(Q3) Clarify number of evaluations.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-211 m193 F08/0042 submitted - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: module m type :: foo integer :: i = 0 contains procedure, pass :: op end type contains subroutine op(this, i) class(foo) :: this this%i = i end subroutine end module m program p use m class(foo), allocatable :: o_foo[:] integer :: me allocate(foo :: o_foo[*]) me = this_image() if (me == 1) then call o_foo[2]%op(1) ! Type-bound call. end if sync all if (me == 2) write(*,*) o_foo%i end program p This program is not standard-conforming, as it violates one of the requirements of 12.5.2.4p2, viz "If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic." However, if the type-bound call were replaced by SELECT TYPE(o_foo) TYPE IS (foo) CALL o_foo[2]%op(1) END SELECT appears to be standard-conforming. The example program appears to be harmless, so the requirement appears to be unnecessary. It is conjectured that the requirement is misworded and should instead be "If the actual argument is a polymorphic subobject of a coindexed object, the dummy argument shall not be polymorphic."? Q1. Is this requirement intentional? Furthermore, constraint C1229 says of a that is the object for a type-bound procedure reference, that it "shall not be a polymorphic subobject of a coindexed object"; however, C617 already prohibits any from being a polymorphic subobject of a coindexed object except as the subject of a type parameter inquiry or as the actual argument in an intrinsic inquiry function reference, so C1229 appears to be completely redundant. Q2. Is constraint C1229 redundant? ANSWER: A1. The requirement is intentional, and needed to avoid a potential type enquiry of an object on another image. Consider TYPE,EXTENDS(foo) :: badfoo CLASS(*),ALLOCATABLE :: badcomponent(:) END TYPE If the dynamic type of object "o_foo" were "badfoo", the call to the type-bound procedure cannot be resolved without enquiring the type of o_foo%badcomponent on image 2 (because it needs to know how much to copy, and how); this type is not necessarily the same type as that of o_foo%badcomponent on image 1. A2. Yes, constraint C1229 is redundant. An edit is supplied to remove this unnecessary redundancy. EDITS to 10-007: [290:1] Delete C1229. SUBMITTED BY: R. Bader HISTORY: 10-208 m193 F08/0043 submitted 10-208r1 m193 Revised - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0044 TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Consider the following code: module m type :: foo integer :: i = 0 end type end module m program p use m class(foo), allocatable :: o_foo[:] integer :: j allocate(foo :: o_foo[*]) if (this_image() == 1) then select type(a => o_foo[2]) ! 1 type is(foo) j = a%i end select select type(a => o_foo) ! 2 type is(foo) j = a[2]%i end select select type(o_foo) ! 3 type is(foo) j = o_foo[2]%i end select end if end program p (1) Is the first SELECT TYPE block standard-conforming? (2) Is the second SELECT TYPE block standard-conforming? (3) Is the third SELECT TYPE block standard-conforming? ANSWERS: References are to 10-007 (1) No. is in the definition of in R847 [184:10]. is defined in R805 [170:17]. C803 [170:22] disallows a coindexed object if is a . C803 constrains in both and . (2) Yes. This is implied by 8.1.3.3 para 1 [171:2]. (3) Yes. EDITS: None SUBMITTED BY: R. Bader HISTORY: 10-209 m193 F08/0044 submitted 10-209r1 m193 Proposed answer - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0045 TITLE: constraints on entities of type LOCK_TYPE KEYWORDS: lock, polymorphism DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: Program example Use Iso_Fortran_Env, Only:lock_type type :: m class(*), allocatable :: lock end type type(m) :: om[*] allocate(lock_type :: om%lock) call inner(om) ! Problem call. Contains Subroutine inner(omm) Type(m),Intent(Out) :: omm Print *,Allocated(omm%lock) End Subroutine End Program Constraint C1304 attempts to prohibit a variable with a LOCK_TYPE subobject from appearing in a variable definition context, such as the call to inner, but the dynamic type of om%lock cannot be determined statically. Is this program standard-conforming? ANSWER: The example was not intended to be standard-conforming. An ALLOCATE statement with a should not have been permitted to add components of type LOCK_TYPE; an edit is supplied to correct this error. EDITS to 10-007: [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", LOCK_TYPE (13.8.2.16), or a type with a direct component of type LOCK_TYPE that is not a direct component of the declared type of any ,". {Fix condition to prohibit LOCK_TYPE and any type with a LOCK_TYPE direct component. Note that we only want to prohibit "new" lock_type components from appearing in the , we don't want to forbid ones that are already in the declared type.} [127:8] After "LOCK_TYPE" delete "(13.8.2.16)". {Reference now appears one line earlier, so is unnecessary.} SUBMITTED BY: R. Bader HISTORY: 10-210 m193 F08/0045 submitted 10-210r1 m193 Revised - Passed by J3 meeting 11-xxx m194 Failed by J3 letter ballot #22 10-254 ** start negative comments Jim Xia's No vote on F08/0045: The edits makes it illegal to specify LOCK_TYPE as if the coarray itself is of LOCK_TYPE. For example, type(lock_type), allocatable :: locks[*] The edits make the following allocate statement illegal ALLOCATE (LOCK_TYPE: locks[*]) result of ballot on F08/0045: /interp will take this back for more work since we think that Jim has a valid complaint => F08/0045 fails Perhaps the edit should be changed to [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", or a type with a direct component of type LOCK_TYPE (13.8.2.16) that is not a direct component of the declared type of any ,". [127:7+] Insert new constraint "C641a (R626) If an is unlimited polymorphic, shall not specify the type LOCK_TYPE (13.8.2.16)." ** end negative comments ---------------------------------------------------------------------- NUMBER: F08/0046 TITLE: VALUE attribute restrictions KEYWORDS: VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program unit SUBROUTINE s(x,y,n) REAL,VALUE :: x(:) CHARACTER(n),VALUE :: y DO i=2,SIZE(x) x(i) = x(i) + x(i-1) END DO PRINT *,y,x END SUBROUTINE This is not valid in Fortran 2003 as it violates constraint C527 "If the VALUE attribute is specified, the ... DIMENSION ... attribute shall not be specified." and also violates constraint C528 "If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions." The corresponding constraint to F2003/C527 for Fortran 2008, C558, does not prohibit the DIMENSION attribute. There does not appear to be any constraint in F2008 corresponding to F2003/C528. Therefore this program unit is apparently now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention these as new features. Is the omission of these requirements an oversight? ANSWER: No, these are deliberate additions to the language. An edit is supplied to clarify the Introduction. EDITS: {to 10-007} [xiii] Introduction, bullet "Data declaration", append "The VALUE attribute is permitted for an array, and for an object with a nonconstant length type parameter." SUBMITTED BY: Malcolm Cohen HISTORY: 10-212 m193 F08/0046 submitted - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0047 TITLE: public generic with same name as private type KEYWORDS: generic, accessibility DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot Consider the following code: module m implicit none private public :: foo ! A type, private :: foo ! B integer :: i = 0 end type type(foo), public :: o_foo interface foo module procedure foo_proc end interface contains function foo_proc(i) result(this) integer, intent(in) :: i type(foo) :: this this%i = i write(*, *) 'Hello' end function end module m program p use m implicit none o_foo = foo(2) end program QUESTION: Is this program standard conforming? ANSWER: No. DISCUSSION: The PUBLIC statement at A contradicts the PRIVATE attribute at B which violates the standard. SUBMITTED BY: R. Bader HISTORY: 10-213 m193 F08/0047 submitted 10-213r1 m193 Proposed answer - Passed by J3 meeting 11-xxx m194 Passed by J3 letter ballot #22 10-254 ---------------------------------------------------------------------- NUMBER: F08/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Was the text in 12.5.2.8: "If the dummy argument is an array coarray that has the CONTIGUOUS attribute or is not of assumed shape, the corresponding actual argument shall be simply contiguous." intended to disallow sequence association for coarrays, as illustrated by the example interface subroutine sub (x) real x(10)[*] end subroutine end interface ... real :: x(100)[*] ... call sub (x(10)) 12.5.2.4 paragraph 13 seems to imply that this ought to be valid. ANSWER: Yes, passing an array element to a dummy coarray was not intended to use sequence association. There is no contradiction with 12.5.2.4 paragraph 13 (which as is simply doesn't apply), but it is confusing so an edit is supplied to clarify it. EDIT: [294:33] Append new sentence to 12.5.2.4 paragraph 13, "If the dummy argument is a coarray that is an array, the actual argument shall be an array." SUBMITTED BY: John Reid HISTORY: 10-226 m193 F08/0048 submitted 10-226r1 m193 Revised answer 10-226r2 m193 Passed by J3 meeting 11-xxx m194 Failed J3 letter ballot #22 10-254 ** start of negative comments Bill Long's No vote on F08/0048: The proposed restriction on coarrays as actual arguments sequence associated with a contiguous dummy makes yet another exception to ordinary array behavior for coarrays. In this case, there seems to be no justification other than the view that sequence association of arguments is archaic. I think that the confusion introduced by making another case where coarrays are different from ordinary arrays is less desirable that allowing coarrays to behave like "old" arrays. John Reid's NO vote on F08/0048: Sequence association is allowed for array coarrays, so I can see no reason for disallowing it for a scalar coarray that is an element of a simply contiguous array. 12.5.2.4 para 13 says: "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array." As the standard stands, I believe that this applies. It is made not to apply by the new edit: "If the dummy argument is a coarray that is an array, the actual argument shall be an array." I think this is a technical change that contradicts one of our design principles: wherever possible, coarrays should behave just like variables that are not coarrays. I suggest that we go back to 10-226 which contains the edit In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:9], add "or an element of a simply contiguous array". Jim Xia's No vote on F08/0048: I believe this restriction might be a bit surprising to users who regularly use sequence associations. Also there isn't an apparent technical difficulties in support this. ** end of negative comments ---------------------------------------------------------------------- NUMBER: F08/0049 TITLE: ELEMENTAL functions with nonconstant type parameters KEYWORDS: ELEMENTAL, type parameter DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Interpretation F03/0119, which became part of the Fortran 2008 standard, added as constraint the requirement of an elemental function that its result variable "shall not have a type parameter that is defined by an expression that is not a constant expression". This makes a number of valid Fortran 95 programs invalid, for no apparent technical reason. Moreover, no text was added to clause 1 to indicate this incompatibility with Fortran 95. Here are several examples of non-problematic Fortran 95 elemental procedures that are apparently not valid Fortran 2008. MODULE ex1 INTEGER :: mylen CONTAINS ELEMENTAL CHARACTER(mylen) FUNCTION f(a) INTEGER,INTENT(IN) :: a f = REPEAT(CHAR(a),mylen) END FUNCTION END MODULE ELEMENTAL FUNCTION ex2(a,b) CHARACTER(*),INTENT(IN) :: a,b CHARACTER(LEN(a)+LEN(b)) :: ex2 ex2 = a//b END FUNCTION MODULE ex3 INTEGER,ALLOCATABLE :: x(:) CONTAINS PURE FUNCTION gcd(a) INTEGER :: gcd INTEGER,INTENT(IN) :: a(:) gcd = ... code to calculate this omitted ... END FUNCTION ELEMENTAL FUNCTION f(y,z) CHARACTER(*),INTENT(IN) :: y,z CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f f = ... END FUNCTION END MODULE Was this incompatibility with Fortran 95 an oversight? ANSWER: Yes, this was an oversight; requiring the type parameter values to be constant is unnecessarily onerous. An edit is supplied to correct this defect in the standard. EDITS: {to 10-007} [314:6-7] 12.8.1, C1290, delete ", and shall not ... expression". {Delete erroneous constraint.} [314:7+] Insert new constraint "C1290a In the that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry, and that specification enquiry shall not depend on a property that is deferred." SUBMITTED BY: Malcolm Cohen HISTORY: 10-231 m193 F08/0049 submitted - Passed by J3 meeting 11-xxx m194 Passed as amended by J3 letter ballot #22 10-254 ----------------------------------------------------------------------