10-202r1 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #21 Date: 2010 August 26 Here are the results of J3 letter ballot #21 on Fortran interpretations that officially closed 30-Jul-2010. The ballot is in J3 paper 10-199 for meeting #192. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 001 002 003 004 005 006 007 008 009 010 011 012 Malcolm Cohen (1) Y Y Y Y Y C Y Y C Y Y Y Robert Corbett Y Y Y Y Y Y Y Y N Y Y Y Bill Long Y Y Y Y C C Y Y Y C C Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y C Y Y Y C Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Jim Xia Y Y C Y C Y Y Y Y Y Y Y J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 013 014 015 016 017 018 019 020 021 022 023 024 Malcolm Cohen (1) Y Y Y Y C C Y Y Y Y Y Y Robert Corbett Y Y Y Y Y Y Y Y Y C Y Y Bill Long Y Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y C C Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Jim Xia Y Y Y C Y Y Y Y Y Y Y Y J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 025 026 027 028 029 030 031 032 033 034 035 036 Malcolm Cohen (1) Y Y Y Y Y Y C C C Y Y Y Robert Corbett Y Y Y Y Y Y Y Y Y Y Y Y Bill Long Y Y Y Y Y Y Y C Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y C C C Y 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 037 038 039 Malcolm Cohen (1) Y Y Y Robert Corbett Y Y Y Bill Long Y Y Y Dan Nagle Y Y Y Craig Rasmussen Y Y Y Van Snyder Y Y C Stan Whitlock Y Y Y Jim Xia Y C Y (1) Malcolm Cohen is the voting alternate for Jeanne Martin 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: F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 Y Y Y Y Y F Y Y C C C Y Y Y Y C Y F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 Y Y Y Y Y Y Y Y Y Y Y Y Y Y C C Y F08 F08 F08 F08 F08 035 036 307 038 039 Y Y Y Y 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 ********************************************************************** F08/0003 Is a disassociated pointer allowed as an actual DIM argument? Jim Xia's Comment F08/0003: The edits missed the following intrinsics which have the same problem of optional DIM argument: COUNT, LBOUND, LCOBOUND, UBOUND, UCOBOUND Van replied to Jim: The edits did not miss these cases. They were handled by a different strategy from the others. See edits for 13.7.41p3, 13.7.90p3, 13.7.91p3, 13.7.171p3, and 13.7.172p3 in the text of the interp in 10-199 (a meeting 193 paper). Van further replied: One might think we have could handled them with signatures such as 13.7.41 COUNT ( MASK [,KIND] ) or COUNT ( MASK, DIM [, KIND] ) and made DIM non-optional, but that wouldn't work because both KIND and DIM are integers. In CALL COUNT ( [ .TRUE. ], J ) one cannot tell whether J corresponds to an optional KIND argument or to a nonoptional DIM argument, so the generic cannot be resolved. Jim answered Van: Right, it seemed I didn't go deep to see what would be the outcome if the DIM argument is made non-optional. result of ballot on F08/0003: No change will be made as a result of these comments => F08/0003 passes unchanged F08/0005* optional arguments and ASSOCIATED - subsumed by F08/0004 Van Snyder's Comment on F08/0005: Yes if F08/0004 fails, else irrelevant. Jim Xia's comment on F08/0005: The letter ballot says this interp number is also F08/0004 Bill Long's Comment on F08/0005: The first line is "NUMBER: F08/0004". I assume the 0004 should be 0005. Similarly, in the last line, "F08/0004 submitted" the 0004 should be 0005. result of ballot on F08/0005: The typos in F08/0005 will be fixed. F08/0004 passed so there will be no further processing on F08/0005 F08/0006 generic resolution with banned argument combinations Bill Long's Comment on F08/0006: The form of Q1 is "does A happen or does B happen?" The answer is basically "No, B happens". Answer A1 would be better worded if "No, generic" was replaced by "Generic". A3 looks backwards. It should be similar to A2. The question is worded like Q2 - should the compiler reject the intrinsic and look, instead for a user-provided intrinsic that had a matching signature. I think the answer should be: "Yes. The processor cannot resolve the reference to the intrinsic RANDOM_SEED since the definition of the intrinsic RANDOM_SEED requires exactly one or no arguments. Generic resolution would continue searching for another match in the generic definition if there are any. If no match is found, the CALL is illegal." Malcom Cohen's Comment on F08/0006: I think the answer to F08/0006 is perhaps subtly wrong. The bit where it says "the entire definition" implies that CHAR('xxx') should not resolve to the intrinsic but to a host-accessible user function (the user function has to be accessible only by host association, otherwise it overrides the intrinsic anyway). Worse, with CHAR(var) when LEN(var)/=1 at runtime, it calls the user function, but with LEN(var)==1 at runtime, it calls the intrinsic. This is obviously unworkable! This affects many of the intrinsic functions, not just CHAR. So it looks like F08/0006 needs more work. Possibly instead of "the entire description", "any explicit requirements on the presence or absence of arguments" would be ok, but it's a bit late to just drop totally new wording into it. Actually, getting this right (whatever "right" means) probably requires an edit to the standard to say what exactly has to be "consistent" with the reference to the intrinsic. Rather than raise this issue at the WG5 level, maybe we should fail it now. result of ballot on F08/0006: Both of Bill's rewordings are accepted, with "CALL" replaced by "reference" in A3. F08/0006 will be amended. Malcolm's comment needs to be investigated => F08/0006 fails. F08/0009 Is ABS ever required to be the optional IEC 60559 abs? Van Snyder's Comment on F08/0009: I support the spirit of the interp but the wording of the edit is troubling. "IEEE_SUPPORT_STANDARD (A)" is not a function, it is a function reference. Something like "If A is real and the result of invoking the IEEE_SUPPORT_STANDARD function from the IEEE_ARITHMETIC module as IEEE_SUPPORT_STANDARD (A) is true...." would be more precise, but a bit wordy. Malcolm Cohen's Comment on F08/0009: I agree with Van the wording could be better. Maybe inserting "the result of" before "IEEE_SUPPORT_STANDARD" would be sufficient. Bob Corbett's NO vote for F08/0009: The function abs defined in IEC 60559 is a recommended function, not a required function. Computers have been built that implement all of the required features of IEC 60559 in hardware but that do not implement IEC compliant floating-point absolute value in hardware. I have used one such computer. That computer would suffer a performance penalty for implementing IEC compliant abs for values that are in floating-point registers. Machines such as that should not be required to implement a version of ABS that conforms to the recommended function abs in IEC 60559 to claim IEC 60559 compliance through the function IEEE_SUPPORT_STANDARD. The proposed new text is out-of-place in Chapter 13. It would be better placed in Section 14.9, paragraph 1 [page 406]. It would be more consistent with the other recommended functions if the inquiry function IEEE_SUPPORT_DATATYPE were used instead of IEEE_SUPPORT_STANDARD. result of ballot on F08/0009: Bob's comment about the placement of the edit is accepted so the edit is changed from: In 13.7.2p5 [326:4+] add a new sentence to the end of the paragraph: "If A is real and IEEE_SUPPORT_STANDARD (A) function from the IEEE_ARITHMETIC intrinsic module is true, then the intrinsic function ABS (A) is compliant with the function abs described in IEC 60559." to: In 14.9p1 [406:15+] add a bullet after the second bullet of the list: "the IEEE function abs shall be provided by the intrinsic function ABS," With this change => F08/0009 passes as amended F08/0010 deallocating objects that are associated with other objects Bill Long's Comment on F08/0010: In the example code for Q1, the source line CALL SUBR(Q(1:100:11) is missing a closing ")" at the end. result of ballot on F08/0010: Bill's comment is accepted => F08/0010 passes as amended F08/0011 How many times are constructed values finalized? Bill Long's Comment on F08/0011: Very minor: in the line just above the EDITS, there is a NOTE that says this subsumes F08/0012 (10-159). The final paper in that interp is 10-159r1 rather than 10-159. result of ballot on F08/0011: Bill's comment is accepted => F08/0011 passes as amended F08/0012 Are constants finalized? result of ballot on F08/0012: F08/0011 passed so there will be no further processing on F08/0012 F08/0016 Can a vector-subscripted argument become undefined? Jim Xia'x Comment on F08/0016: A. The question part of the interp paper should be cleaned up 1.) 6.5.3.2.2 --> 6.5.3.3.2 2.) "As it happens, c12 already says it is not definable,..." what does c12 refer to? A sentence [295:8-9] in 12.5.2.4 seems to state the quoted restrictions. B. The edit proposes to remove two extra bullets that are not related to the original question and discussion. Should we at least add the references to prove the redundancy of these two items? 1.) C724 seems to cover data-target in a pointer assignment statement. 2.) [203:6-7] in 9.4 Internal files seems to cover internal file. result of ballot on F08/0016: Jim's comments are accepted => F08/0016 passes as amended F08/0017 Elemental subroutine restrictions Van Snyder's Comment on F08/0017: Since elemental requires explicit interface, the first sentence of the edit could be a constraint. I agree that the edit could be subsumed by the edit in F08/0018, since the final edit of F08/0018 deletes the text to which the edit in F08/0017 would apply. Malcolm Cohen's Comment on F08/0017: As the equivalents of these in F2003 were not constraints, I prefer to leave them as textual requirements. result of ballot on F08/0017: /interp agrees with Malcolm's comment => F08/0017 passes unchanged F08/0018 Impure elemental restrictions Van Snyder's Comment on F08/0018: Since elemental requires explicit interface, the first sentence of the first edit [314:7+ C1290+] could be a constraint. Malcolm Cohen's Comment on F08/0018: As the equivalents of these in F2003 were not constraints, I prefer to leave them as textual requirements. result of ballot on F08/0018: /interp agrees with Malcolm's comment => F08/0018 passes unchanged F08/0022 DO CONCURRENT and file i/o Bob Corbett's Comment for F08/0022: In addition to the banning the usage described in the interpretation, the proposed edit has the effect of banning nonadvancing I/O to a unit in different threads. Consider the program PROGRAM MAIN DO, CONCURRENT (INTEGER :: I = 1:3) WRITE (*, FMT='(A)', ADVANCE = 'NO') ' ONE' WRITE (*, FMT='(A)', ADVANCE = 'NO') ' TWO' END DO END Without the edit, the program conforms to the draft standard and the draft standard defines the output to be ONE TWO ONE TWO ONE TWO The edit makes the program nonconformant because the program writes to the same record in more than one iteration. I included this comment because I want to be sure this change to the standard is understood. I do not object to the change. I would have filed an interpretation request regarding the program shown above if the edit had not eliminated the problem illustrated by the program by eliminating the program from consideration. result of ballot on F08/0022: No change will be made as a result of this comment => F08/0022 passes unchanged F08/0031 PURE INTENT(OUT) finalization Van Snyder's Comment on F08/0031: An edit to 1.6.2 also appears to be necessary, since the answer affects programs that conform to F03. Malcolm Cohen's Comment on F08/0031: I think that no edit to 1.6.2 is necessary. F2003 was ambiguous as to whether this was permitted - see penultimate paragraph of interp question. result of ballot on F08/0031: /interp agrees with Malcolm's comment => F08/0031 passes unchanged F08/0032 PURE FUNCTION result finalization Van Snyder's Comment on F08/0032: An edit to 1.6.2 also appears to be necessary, since the answer affects programs that conform to F03. Malcolm Cohen's Comment on F08/0032: Additional edits seem to be required: [24:10] 1.6.2 last sentence, "Any"->"Except as identified in this subclause, any". Note this does something different from the edit in F08/0011; that one is about a program with a different interpretation, whereas this one is making a program non-conforming. Maybe they could be combined into some better weasel words (if not in an interp, in the next revision). [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be finalizable by an impure final subroutine. This is not permitted by this part of ISO/IEC 1539." Bill Long's Comment on F08/0032: In the example code, both of the contained procedures are named f. Suggested change (in case someone tries to compile this like I did): Make the name of the PURE Function g, and change "f%c = a" to "g%c = a". result of ballot on F03/0032: Both of Malcolm's edits and Bill's change are accepted => F08/0032 passes as amended F08/0033 PURE polymorphic finalization Van Snyder's Comment on F08/0033: An edit to 1.6.2 also appears to be necessary, since the answer affects programs that conform to F03. Or maybe not if the only mechanism by which the problem occurs is intrinsic assignment to a polymorphic allocatable variable. Malcolm Cohen's Comment on F08/0033: Additional edits seem to be required: [24:10] Same as in F08/0032 (done once, not twice). [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted an INTENT(OUT) argument of a pure subroutine to be polymorphic. This is not permitted by this part of ISO/IEC 1539.". result of ballot on F03/0033: Both of Malcolm's edits are accepted => F08/0033 passes as amended F08/0038 Are pointless restrictions on DIM arguments ntended? Jim Xia's Comment on F08/0038: This interp has the same problem as F08/0003. It misses the following intrinsics: COUNT, LBOUND, LCOBOUND, UBOUND, UCOBOUND in the "additional edits if if interp F08/0003 passes". result of ballot on F08/0038: See the comments for interp F08/0003 above. No change will be made as a result of this comment => F08/0003 passes unchanged F08/0039 Many-one vector subscript usage Van Snyder's Comment on F08/0039: Edit could be simplified to "is not definable and shall not become undefined." If the definition of "definable" were changed to "capable of definition and permitted to become defined or undefined" the edit could could be further simplified to "is not definable." result of ballot on F08/0039: No change will be made as a result of this comment => F08/0039 passes unchanged ---------------------------------------------------------------------- NUMBER: F08/0001 TITLE: Generic resolution with pointer dummy arguments KEYWORDS: Generic, Pointer, Allocatable DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTERFACE gen SUBROUTINE suba(a) REAL,ALLOCATABLE :: a(:) END SUBROUTINE SUBROUTINE subp(p) REAL,POINTER,INTENT(IN) :: p(:) END SUBROUTINE END INTERFACE REAL,ALLOCATABLE,TARGET :: x(:) ALLOCATE(x(100)) CALL gen(x) The call to gen(x) is compatible both with suba, since x is allocatable, and with subp, since x and p satisfy the requirements in 12.5.2.7 paragraph 2 (p is an INTENT(IN) pointer, x is an allowable target for p). Is this program fragment standard-conforming, and if so, which actual procedure is called? ANSWER: This program was not intended to be standard-conforming. An edit is supplied to add a sufficient requirement. EDITS to 10-007: [286:4] In 12.4.3.4.5p3, after "the other has the POINTER attribute", Insert "and not the INTENT(IN) attribute". SUBMITTED BY: Bill Long HISTORY: 10-145 m192 F08/001 submitted 10-145r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0002 TITLE: Are assumed- or deferred-shape objects allowed in namelist? KEYWORDS: assumed-shape, deferred-shape, namelist DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: At [10-007:111:19-23 5.6p5] it says A namelist group object shall either be accessed by use or host association or shall have its type, type parameters, and shape specified by previous specification statements or the procedure heading in the same scoping unit or by the implicit typing rules in effect for the scoping unit. Because "type parameters, and shape" appears, is the following conforming? real, allocatable :: A(:) real, pointer :: B(:) character(len=:), allocatable :: C namelist /N/ A, B, C DISCUSSION: The wording of 5.6p5 is a result of not completely finishing the replacement of the constraint at [97-007r2:66:1-4 5.4]: A shall not be an array dummy argument with nonconstant bound, a variable with nonconstant character length, an automatic object, a pointer, a variable of a type that has an ultimate component that is a pointer, or an allocatable array. by [04-007:95:10 5.4 C574] which became [09-007r3:111:10 5.6 C585]: C585 (R564) A shall not be an assumed-size array. ANSWER: It was intended that the above conform. Edits are supplied to clarify this. EDITS to 10-007: In the first sentence of [111:19 5.6p5], replace "type parameters, and shape" by "kind type parameters, and rank". SUBMITTED BY: Van Snyder on behalf of Tobias Burnus HISTORY: 10-146 m192 F08/0002 Submitted 10-146r1 m192 Proposed answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0003 TITLE: Is a disassociated pointer allowed as an actual DIM argument? KEYWORDS: DIM argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Several intrinsic functions, such as ANY, have a DIM argument, with the rank of the result depending upon whether it is present. There is a prohibition against the actual argument being an optional dummy argument, but not against it being a disassociated pointer or deallocated allocatable. Is the following program standard conforming, and if so what does it print? program DIM_Arg integer, pointer :: Dim => NULL() logical :: Mask(2,2) = & & reshape( (/ .true., .false, .false, .true. /), (/ 2, 2 /) ) print *, shape( any(mask,dim) ) end program DIM_Arg The description worked until we allowed a disassociated pointer or unallocated allocatable variable that is associated with a nonpointer nonallocatable optional argument to be interpreted not to be present. ANSWER: It was intended that this program not conform. It was an oversight that disassociated pointer and unallocated allocatable actual arguments were not prohibited to correspond to DIM dummy arguments for these intrinsic functions. Edits are provided to clarify this. These functions were intended to behave similarly to MAXLOC et al, where this issue does not arise. Edits are provided to change the descriptions accordingly. EDITS to 10-007: [13.2.4p1 316:24-25] Replace "an optional" by "a" and replace ", if present, specifies" by "can specify". [13.5 Table 13.1 319] Replace "ALL ( MASK [, DIM ])" by "ALL ( MASK ) or ALL ( MASK, DIM )". Replace "ANY ( MASK [, DIM ])" by "ANY ( MASK ) or ANY ( MASK, DIM )". [13.5 Table 13.1 322] Replace "NORM2 ( X [, DIM ])" by "NORM2 ( X ) or NORM2 ( X, DIM )". Replace "PARITY ( MASK [, DIM ])" by "PARITY ( MASK ) or PARITY ( MASK, DIM )". [13.5 Table 13.1 323] Replace "THIS_IMAGE (COARRAY[, DIM])" by "THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.10 328:2] Replace the subclause heading by "ALL ( MASK, DIM ) or ALL ( MASK )" [13.7.10p3 328:7] In the description of the DIM argument, delete "(optional)". [13.7.10p4 328:10] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.13 329:6] Replace the subclause heading by "ANY ( MASK, DIM ) or ANY ( MASK )" [13.7.13p3 329:11] In the description of the DIM argument, delete "(optional)". [13.7.13p4 329:14] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.41p3 338:31] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.90p3 360:4] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.91p3 360:25] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.123 374:24] Replace the subclause heading by "NORM2 ( X, DIM ) or NORM2 ( X )" [13.7.123p3 374:29] In the description of the DIM argument, delete "(optional)". [13.7.123p4 374:31] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.128 377:20] Replace the subclause heading by "PARITY ( MASK, DIM ) or PARITY ( MASK )" [13.7.128p3 377:25] In the description of the DIM argument, delete "(optional)". [13.7.128p4 377:28] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.165 392:6] Replace "or THIS_IMAGE (COARRAY[, DIM]) by ", THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.165p3 392:11] In the description of the DIM argument, delete "(optional)". [13.7.171p3 394:27] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.172p3 395:11] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". SUBMITTED BY: Van Snyder HISTORY: 10-148 m192 F08/0003 submitted 10-148r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0004 TITLE: Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following conforming, and if so what does it print? program TARGET_Arg integer, pointer :: Pointer integer, pointer :: Target => NULL() integer, target :: AnotherTarget pointer => anotherTarget print *, Associated(pointer,target) end program TARGET_Arg DISCUSSION: Subclause 13.7 stipulates that descriptions of arguments of intrinsic procedures apply to actual arguments. This leaves open the question whether the TARGET dummy argument of ASSOCIATED is a pointer or not. If not a pointer, being optional, it is considered by subclause 12.5.2.12 to be absent if the corresponding actual argument is disassociated. Thereby, the result value of ASSOCIATED (by Case(i) of the result value clause) is true. If the TARGET dummy argument is a pointer, the result value of ASSOCIATED (by Case (iv) of the result value clause) is false. ANSWER: It is intended that the program is conforming and prints F. Edits are provided to clarify this. NOTE: This subsumes interp F08/0005 (10-152). EDITS to 10-007: [330:8] Fix the description to read "Query pointer association status". Change the description of the interface to state explicitly that the TARGET dummy argument has the POINTER and INTENT(IN) attributes. A nonpointer actual argument is now permitted by 12.5.2.7p2 to correspond to an INTENT(IN) pointer dummy argument, whereupon the dummy argument becomes pointer associated with the actual argument. The result is that a disassociated TARGET actual argument cannot be considered to be absent. [13.7.16p3 330:14] Before "If TARGET" insert "The dummy argument TARGET has the POINTER and INTENT(IN) attributes." Replace "TARGET" by "the actual argument". [13.7.16p3 330:15+] Insert a note: "NOTE 13.8a This requires the actual argument for TARGET to have the POINTER or TARGET attribute. If the actual argument is not a pointer, the dummy argument TARGET is associated with the actual argument (12.5.2.7)." [13.7.16p5 Cases (iv) and (v) 330:23-29] Delete Cases (iv) and (v) because they will be subsumed be the revisions of cases (vi) and (vii). [13.7.16p5 Case (vi) 330:30] Replace "a scalar pointer" by "scalar". [13.7.16p5 Case (vii) 330:33] Delete "pointer". SUBMITTED BY: Van Snyder HISTORY: 10-149 m192 F08/0004 submitted 10-149r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0005 TITLE: optional arguments and ASSOCIATED KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Subsumed by F08/0004 QUESTION: If the actual argument associated with the dummy argument TARGET of the intrinsic function ASSOCIATED is a disassociated pointer, is the dummy argument TARGET to be treated as an optional argument that is not present or as an argument that is present? ANSWER: The dummy argument TARGET should be treated as an argument that is present. DISCUSSION: This problem was created by the Fortran 2008 extension that declares that a dummy argument is not present if it corresponds to an actual argument that is a disassociated pointer [12.5.2.12p1, 299:15-17]. Among the solutions that have been suggested are (1) removing the extension, (2) restricting the extension to apply only to user-defined functions, (3) adding an exception to the extension for the intrinsic function ASSOCIATED, (4) changing the specification of ASSOCIATED in [17.7.16, 330:7-42] to specify two signatures. As attractive as the first two solutions are, I initially favored solution (3) as it caused the least change to the language as defined in recent drafts. I proposed to add text to Section 12.5.2.12 specifying the exception. Over time, I changed my mind; I now favor solution (4). I initially favored solution (3) over solution (4) because solution (4) does not treat the dummy argument TARGET as not present when the corresponding actual argument is an optional argument that is not present. That functionality is in Fortran 2003, and I did not think it should be removed. The more I thought about the issue, the more I was convinced that that functionality is useless except for programs written for test suites. I am now convinced that removing that functionality improves the language by making it possible for a processor to treat use of that functionality as the error it almost certainly is. EDITS to 10-007: [13.7.16, 330:7] Replace "ASSOCIATED (POINTER [,TARGET])" with "ASSOCIATED (POINTER) or ASSOCIATED(POINTER, TARGET)". [13.7.16, 330:18] Replace "is absence" with "does not appear". [13.7.16, 330:19] Replace "is present" with "appears". [13.7.16, 330:23] Replace "is present" with "appears". [13.7.16, 330:26] Replace "is present" with "appears". [13.7.16, 330:30] Replace "is present" with "appears". [13.7.16, 330:33] Replace "is present" with "appears". SUBMITTED BY: Robert Corbett HISTORY: 10-152 m192 F08/0005 submitted - subsumed by F08/0004 10-202 m192 Confirmed as amended by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0006 TITLE: generic resolution with banned argument combinations KEYWORDS: intrinsic, generic DEFECT TYPE: interpretation STATUS: J3 consideration in progress 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. Suppose one of those intrinsic functions or subroutines is referenced with one of the banned combinations of arguments. Q1. If the process of generic resolution tries to resolve the reference against the intrinsic, does it resolve the function or subroutine to the intrinsic or should it continue trying to resolve the function or subroutine reference? Q2. For example, given the function reference CMPLX(Z, R) where Z is COMPLEX and R is REAL, should the processor resolve the generic reference to the intrinsic even if it could be resolved to a user-defined function with the same signature later in the process of resolving the reference? Q3. Similarly, given the subroutine call CALL RANDOM_SEED(GET=A, PUT=B) should the processor skip over the intrinsic subroutine to possibly resolve the generic reference against a user-defined subroutine with the same signature? ANSWER: The definition of the interface of an intrinsic consists of its entire description in the standard, not just the names and keywords in the section header of its definition. All of that information must be used to resolve a reference to an intrinsic. A1. Generic resolution does not resolve to an intrinsic with an illegal combination of arguments. Generic resolution would continue to search user-defined specifics of the generic if they exist. If no match was found, the reference is illegal. A2. No, the given reference cannot resolve to the intrinsic CMPLX. Generic resolution would continue searching for another match in the generic definition if there are any. If no match is found, the reference is illegal. A3. Yes. The processor cannot resolve the reference to the intrinsic RANDOM_SEED since the definition of the intrinsic RANDOM_SEED requires exactly one or no arguments. Generic resolution would continue searching for another match in the generic definition if there are any. If no match is found, the reference is illegal. 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 Malcom Cohen's Comment on F08/0006 in 10-202: I think the answer to F08/0006 is perhaps subtly wrong. The bit where it says "the entire definition" implies that CHAR('xxx') should not resolve to the intrinsic but to a host-accessible user function (the user function has to be accessible only by host association, otherwise it overrides the intrinsic anyway). Worse, with CHAR(var) when LEN(var)/=1 at runtime, it calls the user function, but with LEN(var)==1 at runtime, it calls the intrinsic. This is obviously unworkable! This affects many of the intrinsic functions, not just CHAR. So it looks like F08/0006 needs more work. Possibly instead of "the entire description", "any explicit requirements on the presence or absence of arguments" would be ok, but it's a bit late to just drop totally new wording into it. Actually, getting this right (whatever "right" means) probably requires an edit to the standard to say what exactly has to be "consistent" with the reference to the intrinsic. Rather than raise this issue at the WG5 level, maybe we should fail it now. ------------------------------------------------------------------------ NUMBER: F08/0007 TITLE: Can zero have more than one bit sequence representation? KEYWORDS: zero, bits DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Question (1): Some processors provide two internal representations for the integer value zero. The ones' complement representation of signed integers and the signed-magnitude representation of signed integers both provide two representations for zero. Must a processor for such a machine use a bit sequence consisting of all zero bits to represent zero, regardless of the internal representation of zero? Question (2): The Fortran 2008 standard [13.3.1, 317:9] states The interpretation of a negative integer as a sequence of bits is processor dependent. Could a standard-conforming processor interpret all negative integers as a sequence of all zero bits? ANSWERS: Answer to question (1): Yes. The standard does not allow for more than one bit representation of zero. Answer to question (2): No. The standard specifies that the integer value of a string of all zero bits is zero. The standard does not specify the integer values for bit strings when the leftmost bit is one. A processor could interpret all negative integers as a sequence of a one followed by all zero bits. It would not be a useful bit representation but it is not disallowed. EDITS to 10-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-154 m192 F08/0007 submitted 10-154r1 m192 Draft answer 10-154r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0008 TITLE: IEEE exceptions for intrinsic functions KEYWORDS: IEEE_INVALID, SQRT DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Section 13.7.1, page 325, lines 10-12 states If an infinite result is returned, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal; if a NaN result is returned, the flag IEEE_INVALID shall signal. Question (1): The Fortran 2008 standard does not require a standard-conforming processor to support IEEE_INVALID [14.3p8, 404:15]. If a processor does not support IEEE_INVALID, is it required to signal IEEE_INVALID when a NaN result is returned? Question (2): IEC 60559 requires the result of SQRT(+inf) to be +inf without overflow being signaled. IEC 60559 requires SQRT(qNaN), where qNaN is a quiet NaN, not to signal an invalid operand exception. Does Fortran 2008 require SQRT(QNaN) to signal IEEE_INVALID? ANSWERS: Question (1): No. If the processor does not support IEEE_INVALID, it cannot signal IEEE_INVALID. Question (2): No. The standard does not specify the behavior of SQRT on qNaN. EDITS to 10-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-155 m192 F08/0008 submitted 10-155r1 m192 Fix title 10-155r2 m192 Draft answer 10-155r3 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0009 TITLE: Is ABS ever required to be the optional IEC 60559 abs? KEYWORDS: ABS, IEEE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Are there any circumstances where the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in the optional portion of IEC 60559? DISCUSSION: Chapter 14 of F2008 does not define an IEEE_ABS intrinsic as a separate IEEE version of ABS and the example given in Section 14.11.3p7 [409:26] requires that ABS comply with the function abs specified in the optional portion of IEC 60559. We infer that the standard intended for the ABS intrinsic to be compliant with the IEC 60559 definition. ANSWER: Yes, the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in IEC 60559. An edit is provided to make that explicit. EDITS to 10-007: In 14.9p1 [406:15+] add a bullet after the second bullet of the list: "the IEEE function abs shall be provided by the intrinsic function ABS," SUBMITTED BY: Robert Corbett HISTORY: 10-156 m192 F08/0009 submitted 10-156r1 m192 Draft answer 10-156r2 m192 Revised answer 10-156r3 m192 Revised again - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0010 TITLE: deallocating objects that are associated with other objects KEYWORDS: DEALLOCATE associated DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1: Consider the program SUBROUTINE SUBR(A) REAL A(*) REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q DEALLOCATE (P) END PROGRAM MAIN REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q ALLOCATE(P(100)) P = 1.0 Q => P CALL SUBR(Q(1:100:11)) END The subroutine SUBR deallocates the object containing the subobject associated with the nonpointer argument A. Is it intended that a pointer may be deallocated while its target is associated with a nonpointer entity? Q2: Consider the code fragment ASSOCIATE (X=>A(3)) DEALLOCATE (A) X = 0.0 where A is an allocatable array that is allocated at the start of the code fragment. Is it intended that an allocatable variable may be deallocated while it is associated with an associate name? ANSWER: A1: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. A2: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. EDITS to 10-007: [6.7.3.2p1, 130:23] Add the following sentence to the end of the paragraph "An allocatable variable shall not be deallocated if it or any subobject of it is argument associated with a dummy argument or construct associated with an associate name." [6.7.3.3p1, 131:27] Add the following sentence to the end of the paragraph "A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name." SUBMITTED BY: Robert Corbett HISTORY: 10-157 m192 F08/0010 submitted 10-157r1 m192 Draft answer 10-157r2 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0011 TITLE: How many times are constructed values finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f10,f11 End Type Type,Extends(t1) :: t2 Real d Contains Final :: f20,f21 End Type Contains Subroutine f10(x) Type(t1),Intent(InOut) :: x Print *,'f10 called' End Subroutine Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine Subroutine f20(x) Type(t2),Intent(InOut) :: x Print *,'f20 called' End Subroutine Subroutine f21(x) Type(t2),Intent(InOut) :: x(:) Print *,'f21 called' End Subroutine End Module Program q Call sub(1.5,2.5) End Program Subroutine sub(x,y) Use m Type(t1),Parameter :: p1 = t1(2.5) Type(t2),Parameter :: p2 = t2(3.5,-3.5) Call s10(t1(x)) Call s11([p1]) ! (a) Call s11([t1(x)]) ! (b) Call s11([ [ [ p1,p1 ] ] ]) ! (c) Call s20(t2(x,y)) Call s21([p2]) ! (d) Call s21([t2(y,y)]) ! (e) Call s21([t2(t1=p1,y)]) ! (f) Call s21([t2(t1=t1(x),y)]) ! (g) Call s21([(p2,t2(x,y),i=1,10**7)]) ! (h) End Subroutine The topic is how many times each final procedure is called on return from each subroutine? For s10, clearly f10 is called once. For s11(a), clearly f11 is called once, and f10 is not called. For s11(b), the standard (4.5.6.3 para 5) seems to indicate that f10 is called. That would not make much sense - the value of the structure constructor is part of the value of the array constructor, so calling f10 would mean that that array element would be finalized twice (once by f11, once by f10, in no set order). For s11(c), the standard standard appears to say that f11 is called three times, once for each (nested) array constructor. Seeing as how nesting array constructors is a syntactic thing that makes zero difference to the value - the value of [[anything]] is identical in every respect to the value of [anything] - this does not seem to make sense. For s20, clearly f20 is called once, and f10 is called afterwards to finalize the parent component. For s21(d), clearly f21 is called once, followed by f11 to finalize the parent components. f20 and f10 are not called. For s21(e), f21 and f11 are called as in s21(d); the standard implies that f20 and then f10 are called, but that does not make sense, the same as case s11(b). For s21(f), the situation seems to be the same as s21(e); the wanted f21 and f11, and (unordered) the unwanted f20 and f10. For s21(g), f21 and f11 are called as in s21(d); the standard implies that f10 is called to finalize t1(3) and also that f20 and then f10 are called to finalize t2(t1=t1(3),4). This makes even less sense than before, since the t1 part of the array constructor element is going to be finalized 3 times just because of the syntax we used. For s21(h), f21 and f11 are called as in s21(d) to finalize the whole array constructor value; the standard also implies that f20 and then f10 are called on all of the 5000000 even-numbered elements. Requiring the processor to keep track of all those elements to be finalized on return from s21 seems rather severe. Furthermore, an object that has been finalized is not permitted to be referenced or defined. That makes the multiple finalization interpretation even more hard to understand. Philosophically, finalization should finalize objects exactly once. There seem to be three possibilities here. (1) The finalizers are called multiple times, but on the separate entities created by the constructors. For example s21(g), that is t1(3) is created as object X, when t2(...) is evaluated a new separate object Y is created and that value is copied into it, and when [...] is evaluated a third object Z is created with the value of Y copied into it; afterwards, we effectively have call f10(X); call f20(Y); call f21(Z); call f11(Z%t1) For s21(h) that burden is going to be extreme because the standard says these are "finalized after execution of the innermost executable construct containing the reference" (and it is possible to detect this in a conforming program); changing that to "finalized after the value has been used" would be better if slightly vague. (2) These entities are indeed finalized multiple times, just as the standard implies. (3) Constructors that are merely providing part of the value of a bigger constructor are not finalized. (4) Constructors should never be finalized in themselves, this was just a design error that inevitably leads to multiple or unwanted finalization. Which is the correct approach? ANSWER: Approach 4. Constructors don't do anything that needs finalization. Edits are provided to correct the mistake. NOTE: This answer subsumes interp F08/0012 (10-159r1). EDITS to 10-007: [24:9] Change the first word of 1.6.2 "This" -> "Except as identified in this subclause, this". [24:11+] Insert new paragraph. "Fortran 2003 specified that array constructors and structure constructors of finalizable type are finalized. This part of ISO/IEC 1539 specifies that these constructors are not finalized.". [76:24-25,28-29] Delete paragraphs 5 and 7 of 4.5.6.3 (When finalization occurs). SUBMITTED BY: Malcolm Cohen HISTORY: 10-158 m192 F08/0011 submitted 10-158r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0012 TITLE: Are constants finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Subsumed by F08/0011 QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f10,f11 End Type Type,Extends(t1) :: t2 Real d Contains Final :: f20,f21 End Type Contains Subroutine f10(x) Type(t1),Intent(InOut) :: x Print *,'f10 called' End Subroutine Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine Subroutine f20(x) Type(t2),Intent(InOut) :: x Print *,'f20 called' End Subroutine Subroutine f21(x) Type(t2),Intent(InOut) :: x(:) Print *,'f21 called' End Subroutine End Module Program q Use m Type(t1),Parameter :: p1 = t1(1.5) Type(t2),Parameter :: p2 = t2(2.5,-3.5) Type(t1),Parameter :: ap1 = [ p1 ] Type(t2),Parameter :: ap2 = [ p2 ] Call sub1(p1) Call sub1(t1(1.5)) ! (*) Call sub2(p2) Call sub2(t2(2.5,-3.5)) ! (*) Call sub1a(ap1) Call sub1a([p1]) ! (*) Call sub2a(ap2) Call sub2a([p2]) ! (*) End Program The topic is how many times each final procedure is called on return from each subroutine? Clearly, the final procedures are not called on return from the calls not marked with an asterisk. For the ones marked with an asterisk, the situation is less clear. The standard says that a structure constructor or array constructor is finalized "[if] an executable construct references [it]" (4.5.6.3p5). However, the term "reference" is not defined for these entities; the closest would seem to be "appearance of a data object designator in a context requiring its value at that point during execution" which would appear on the face of it to mean that these entities are finalized since the constructor appears in a context requiring its value. Possible interpretations might be (a) Yes, the entities are required to be finalized (so the relevant final procedure is executed). (b) The text in 4.5.6.3p5 was not intended to be applied to constants (the standard is defective). (c) The processor can optionally evaluate an alternative expression with the same value, viz an named constant, so it is processor dependent whether the finalizer is called. Option (a) seems inconsistent with named constants otherwise being equivalent to their constant expression. Option (c) argument could be equally applied to nonconstant constructors, so this would make all finalization of constructed values optional. That would seem inconsistent with the purpose of finalization. Which is the correct approach? ANSWER: Subsumed by F08/0011. EDITS: N/A. SUBMITTED BY: Malcolm Cohen HISTORY: 10-159 m192 F08/0012 submitted 10-159r1 m192 Revised - subsumed by F08/0011 10-202 m192 Confirmed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0013 TITLE: How does finalization interact with allocatable assignment? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine End Module Program q Use m Type(t1),Parameter :: ap1(1) = [ t1(1.5) ] Type(t1),Parameter :: ap2(3) = [ t1(2.5),t1(3.5),t1(4.5) ] Type(t1),Parameter :: ap3(3) = t1(0.5) Type(t1),Allocatable :: x(:) x = ap1 ! (*1) x = ap2 ! (*2) x = ap3 ! (*3) End Program The topic is how 4.5.6.3 paragraphs 1 and 9 interact. The relevant texts are, respectively: "When an allocatable entity is deallocated, it is finalized." "When an intrinsic assignment statement is executed, the variable is finalized after evaluation of and before the definition of the variable." In the assignment marked (*1), paragraph 9 says that the variable (X) is finalized, i.e. CALL F11(X) is executed. However, this would be invalid, because an unallocated allocatable would be associated with a nonallocatable nonoptional dummy argument. In the assignment marked (*2), paragraph 9 again says that the variable is finalized - after evaluation of but before the definition of the variable. However, because the shapes of the variable and the expression differ, definition of the variable involves deallocating the variable (and allocating it with the correct shape). Paragraph 1 says that deallocating the variable finalizes it, so that means that F11 should be called twice for the variable. This is problematic since a finalized entity is not permitted to be referenced or defined by a final subroutine. In the assignment marked (*3), the variable and expression have the same shape so the variable will not be deallocated, so according to paragraph 9 it should be finalized once. Q1. Are all the assignment statements standard-conforming? Q2. How many times is the variable finalized (i.e. how many times is the final subroutine called) in each standard-conforming case? ANSWER: A1. Yes, all the assignment statements are intended to be standard conforming. Edits are supplied to correct the problem in (*1). A2. The variable is finalized exactly once, except when it was unallocated (and then it is not finalized). Edits are supplied to correct the problem in (*2). EDITS to 10-007: [76:17] In 4.5.6.3 When finalization occurs, paragraph 1, After "it is finalized" Insert "unless it is the variable in an intrinsic assignment (7.2.1.3) or a component thereof". [76:32] In 4.5.6.3 When finalization occurs, paragraph 9, change "the variable" to "if the variable is not an unallocated allocatable variable, it", [76:33] append new sentence to paragraph: "If the variable is an allocated allocatable that would be deallocated by intrinsic assignment, the finalization occurs before the deallocation.". Then, move the revised [76:32-33] (4.5.6.3p9) to precede the existing paragraph 1, i.e. [76:17-]. SUBMITTED BY: Malcolm Cohen HISTORY: 10-160 m192 F08/0013 submitted 10-160r1 m192 Revised 10-160r2 m192 Revised edit - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0014 TITLE: Finalizing assignment to vector-subscripted object KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' x%c = 0 ! (*) End Subroutine End Module Program q Use m Type(t1) :: x(10) = t1(0) x( [1,4,9] ) = t1(1.5) Print *,x End Program According to 6.5.3.2.2 Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." Therefore the program above is not standard-conforming; however it seems that deleting the assignment statement marked (*) would make the program standard-conforming. This seems to make final subroutines not useful when vector subscripts are involved; either the finalization doesn't do anything to the object in which case the vector subscript is allowed, or it does do something (like deallocation) in which case the vector subscript is disallowed. Also, since passing vector-subscripted objects as actual arguments is almost certainly going to pass a copy (and what's more a copy that won't be copied back), this results in something other than the actual entity being finalized - and this is possibly visible if pointers and targets are involved. Finally, these apparent violations of the standard are probably not going to be detected on many processors, resulting in silent wrong answers. At least if vector subscripted sections being finalized were rejected at compile time the user would stand a chance of avoiding these problems. Q. Is this analysis correct, and is this situation deliberate? ANSWER: A. The analysis is correct. This should have been alleviated by allowing elemental procedures to modify vector-subscripted arguments. An edit is supplied. EDITS to 10-007: [124:7+] Insert new paragraph "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine." [295:8] In 12.5.2.4p18, After "If" insert "the procedure is nonelemental and". SUBMITTED BY: Malcolm Cohen HISTORY: 10-161 m192 F08/0014 Submitted 10-161r1 m192 Revised answers and edits. 10-161r2 m192 Selected alternative answer, revised edits - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0015 TITLE: IMPLICIT KEYWORDS: IMPLICIT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 5.5 IMPLICIT statement contains the permission-giving statement: "The mapping may be to a derived type that is inaccessible in the local scope if the derived type is accessible to the host scope." But what if the derived type is not accessible to the host scope? Consider the module: module m implicit type(t) (a-z) type t real x end type contains subroutine s(x) type t character(10) c end type call inner(x) contains subroutine inner(y) a = x b = y print *,a%x,b%x end subroutine end subroutine end module In inner, the mapping is not to a derived type that is accessible to the host scope. Is this module standard-conforming? ANSWER: Yes. The statement apparently giving permission is in error: no permission needs to be given here, it simply follows from the other scoping rules. An edit is provided to clarify the standard. EDITS to 10-007: [109:21-22] (5.5p4) Delete the confusing sentence "The mapping may ... scoping unit.". SUBMITTED BY: Malcolm Cohen HISTORY: 10-162 m192 F08/0015 submitted 10-162r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0016 TITLE: Can a vector-subscripted argument become undefined? KEYWORDS: Vector subscript, actual argument, undefined. DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: According to 6.5.3.3.2 [124] Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." How can we predict the future? And even if we could, it implies that it would be ok for the dummy array to be undefined (because it only forbids becoming defined). As it happens, 12.5.2.4p18 [295:8-9] already says it is not definable, so already covers being defined and redefined - and also becoming undefined, and also prevents not just INTENT(OUT) or INOUT but also ASYNCHRONOUS and VOLATILE. What is the point to this future-predicting confusing redundancy? ANSWER: This paragraph is completely redundant as well as incomplete. C724 [158:19-20] covers in a pointer assignment statement. 9.4p2 [203:6-7] copvers internal files. An edit is supplied to correct this situation. EDITS to 10-007: [124:4-7] Delete 6.5.3.3.2 paragraph 2. SUBMITTED BY: Malcolm Cohen HISTORY: 10-163 m192 F08/0016 submitted 10-163r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0017 TITLE: Elemental subroutine restrictions KEYWORDS: ELEMENTAL, SUBROUTINE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following elemental subroutine ELEMENTAL SUBROUTINE test_add(a,b) REAL,INTENT(IN) :: a,b REAL c c = a+b END SUBROUTINE and the following reference: REAL x(10),y LOGICAL toobig ... CALL IEEE_SET_FLAG(IEEE_OVERFLOW,.FALSE.) CALL test_add(x,y) CALL IEEE_GET_FLAG(IEEE_OVERFLOW,toobig) The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow. Is this program fragment standard-conforming? 12.8.3 says "In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments corresponding to INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them." Obviously, it is not the case that all actual arguments are scalar. However, there not being any actual arguments corresponding to INTENT(OUT) or INTENT(INOUT) dummy arguments, it is not possible for the remaining actual arguments (x and y) to be conformable with them. Is this an oversight? (If not, it seems a very clumsy way of requiring elemental subroutines to have an INTENT(OUT) or INTENT(INOUT) argument, and one that doesn't work if they are only referenced with scalar arguments.) ANSWER: Yes, the program fragment is intended to be standard-conforming. An edit is supplied to correct the oversight in the standard. EDITS to 10-007: [314:16-19] In 12.8.3, replace the second sentence "In ... them." by "In a reference to an elemental subroutine, if any argument is an array, all actual arguments that correspond to INTENT (OUT) or INTENT (INOUT) dummy arguments shall be arrays. All actual arguments shall be conformable." NOTE: This edit is potentially subsumed by the edit in the interp F08/0018 (10-168r1) "Impure elemental restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-167 m192 F08/0017 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0018 TITLE: Impure elemental restrictions KEYWORDS: IMPURE, ELEMENTAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: With the following two impure elemental procedures, which perform essentially the same calculations, IMPURE ELEMENTAL SUBROUTINE one(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x END SUBROUTINE IMPURE ELEMENTAL REAL FUNCTION two(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x two = y - z END FUNCTION consider these references: REAL a(10),b,c ... CALL one(b,a) ! (i) ok, equivalent to CALL one([(b,i=1,10)],a) CALL one(a,b) ! (ii) not ok, prohibited by 12.8.3p1, sentence 2. c = two(b,a) ! (iii) ok, like (i) d = two(a,b) ! (iv) NOT prohibited!?! Was allowing case (iv) an oversight? ANSWER: Yes, this was an oversight: after adding impure elementals, the elemental subroutine argument restrictions need to apply to elemental functions as well. EDITS to 10-007: [314:7+] Insert new paragraph as follows. "In a reference to an elemental procedure, if any argument is an array, all actual arguments that correspond to INTENT (OUT) or INTENT (INOUT) dummy arguments shall be arrays. All actual arguments shall be conformable." [314:11-12] In 12.8.2, delete the third sentence; that sentence reads "For those ... conformable.". {Redundant with new paragraph.} [314:16-19] In 12.8.3, delete the second sentence; that sentence reads "In a reference ... conformable with them.". {Redundant with new paragraph.} NOTE: These edits subsume the one in the interp F08/0017 (10-167r1) "Elemental subroutine restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-168 m192 F08/0018 submitted 10-168r1 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0019 TITLE: Transformational Bessel functions KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTEGER :: n1(10) = 1,n2(2,3,4,5) = 2 ... PRINT *,BESSEL_JN(n1,n2,[1.0,2.0]) The description of BESSEL_JN, transformational version, merely states that N1 and N2 "shall be of type integer and nonnegative", and for X merely states that it "shall be of type real". There is no requirement on rank or conformability. Is this conforming, and if so, what value(s) should it print? A similar question applies to BESSEL_YN. ANSWER: This was not intended to be conforming. The N1 and N2 arguments should have been required to be scalar, as should the X argument for the transformational version of the function. Edits are supplied to correct this oversight. A similar answer pertains to the similar question for BESSEL_YN, and similar edits are supplied. EDITS to 10-007: [333:12,13] In 13.7.24p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [333:14] In 13.7.24p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". [334:12,13] In 13.7.27p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [334:14] In 13.7.27p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". SUBMITTED BY: Malcolm Cohen HISTORY: 10-169 m192 F08/0019 submitted 10-169r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0020 TITLE: FINDLOC and logical arguments KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider REAL :: array(1000),value COMPLEX :: carray(1000),cvalue LOGICAL :: ilarray(1000),ilvalue ... PRINT *,FINDLOC(array,value) PRINT *,FINDLOC(carray,cvalue) PRINT *,FINDLOC(ilarray,ilvalue) Are any of the references to FINDLOC standard-conforming? 13.7.61 requires of the VALUE argument that it "shall be ... in type conformance with ARRAY, as specified in Table 7.2 for relational intrinsic operations 7.1.5.5.2).". Yes, there is an unpaired parenthesis. More to the point: (a) Table 7.2 is in 7.1.5.1 not in 7.1.5.5.2; (b) there is no table about type conformance in 7.1.5.5.2, (c) for type logical, the comparison is allegedly done by .EQV., but that is not a relational operator. It could be argued that the reference to 7.1.5.5.2 is just misleading, and reading the rest of the sentence we should indeed use Table 7.2, with the conformance as specified for the relational operators. That would make the first reference to FINDLOC conforming. The second reference to FINDLOC is more problematic, because some relational operators permit complex arguments (e.g. .EQ.) and some do not (.LE.). This makes it ambiguous as to whether or not it is conforming. The third reference to FINDLOC is the most problematic, because no relational operators permit logical arguments. Later on, FINDLOC says it uses .EQV. for logical comparison, but .EQV. is a logical operator not a relational operator, so in any case VALUE cannot satisfy the rules in Table 7.2. ANSWER: These were all intended to be standard-conforming. Edits are supplied to correct the requirement. EDITS to 10-007: [347:31-32] In 13.7.61p3, VALUE argument, replace "for ... )" by "for the operator == or the operator .EQV.". {NB: Use the same operators as specified in 13.7.61p6. Use disjunction to avoid misinterpreting it as requiring both at once.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-170 m192 F08/0020 submitted 10-170r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0021 TITLE: STORAGE_SIZE and unlimited polymorphic KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CLASS(*),POINTER :: p NULLIFY(p) PRINT *,STORAGE_SIZE(p) Note that p does not have any deferred type parameters, so is not prohibited from being a disassociated pointer in a reference to STORAGE_SIZE. Was this intended to be standard-conforming? If so, what value would be printed? Zero? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to insert the missing prohibition. EDITS to 10-007: [390:6] In 13.7.160p3, argument A, before "has any deferred" insert "is unlimited polymorphic or", and after "type parameters" insert ",". {Comma to make the sentence easier to read, not strictly necessary.} That makes the whole sentence read: "If it is unlimited polymorphic or has any deferred type parameters, it shall not be an unallocated allocatable variable or a disassociated or undefined pointer." SUBMITTED BY: Malcolm Cohen HISTORY: 10-171 m192 F08/0021 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0022 TITLE: DO CONCURRENT and file i/o KEYWORDS: DO CONCURRENT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The standard states [178:15-16] that "An input/output statement shall not write data to a file record or position in one iteration and read from the same record or position in a different iteration." In the loop DO CONCURRENT (i=1:2) IF (i==1) READ(17,REC=100) x ! (a) IF (i==2) WRITE(17,REC=100) y ! (b) END DO The input/output statement at (a) only reads data from the file, it does not write it, and thus does not fall foul of this restriction. Similar reasoning shows that the input/output statement at (b) also obeys this restriction. Is this fragment intended to be standard-conforming? ANSWER: No, the example is not intended to be standard-conforming. An edit is supplied to make the requirement less ambiguous. EDITS to 10-007: [178:15-16] In 8.1.6.7p1, penultimate bullet point, replace the whole sentence "An input/output ... iteration." with "If data are written to a file record or position in one iteration, that record or position in that file shall not be read from or written to in a different iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-172 m192 F08/0022 submitted 10-172r1 m192 Draft answer 10-172r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0023 TITLE: DO CONCURRENT and POINTER KEYWORDS: DO CONCURRENT, POINTER DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) THEN ALLOCATE(x(i)) x = 3 ! Note: defines x, does not reference x. ELSE y(i) = SUM(x) ! (*) Note: references x. DEALLOCATE(x) END IF END DO This is clearly not conforming, as it violates the requirement in [178:8-9 8.1.6.7p1 second bullet]: "A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration." However, consider example 2, identical except for replacing the (*) statement with: y(i) = SIZE(x) ! (*) Note: SIZE does not reference x. That statement does not reference x (see definition of reference at 1.3.120) and so does not violate the requirement. An even simpler example which does not violate the requirement but which appears problematic is POINTER p NULLIFY(p) DO CONCURRENT(i=1:2) IF (i==1) ALLOCATE(p) IF (i==2) PRINT *,ASSOCIATED(p) END DO A third example which does not violate the requirement but again appears to be problematic is PROCEDURE(),POINTER :: p,q EXTERNAL a,b p => a DO CONCURRENT(i=1:2) IF (i==1) p => b IF (i==2) q => p ! (*1) END DO CALL q ! (*2) Note that (*1) does not reference p, but (*2) does reference q. The pointer q is only set by one iteration, so no problem there. Were these examples intended to be standard-conforming? ANSWER: No, the examples were not intended to be standard-conforming. An edit is supplied to correct the requirement. Comment: We don't need to require "pointer associated" for "reference", that is always required for references. What we need to require is for the pointer association status to be established. EDITS to 10-007: [178:8-9] Replace the sentence "A pointer that is referenced ... any iteration." with the following sentence: "A pointer that is used in an iteration other than as the pointer in pointer assignment, allocation, or nullification, either shall be previously pointer-assigned, allocated, or nullified in that iteration or shall not have its pointer association changed during any iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-173 m192 F08/0023 submitted 10-173r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0024 TITLE: Dummy arguments of impure elemental procedures KEYWORDS: IMPURE, ELEMENTAL, INTENT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider IMPURE ELEMENTAL SUBROUTINE swap1(a,b) REAL,INTENT(INOUT) :: a,b c = a a = b b = c END SUBROUTINE IMPURE ELEMENTAL SUBROUTINE swap2(a,b) REAL :: a,b c = a a = b b = c END SUBROUTINE ... REAL x,y(10) ... CALL swap1(x,y) ! (a) CALL swap2(x,y) ! (b) The rules for arguments of elemental subroutines means that CALL (a) is not standard-conforming. However, since there are no rules requiring declaration of INTENT (that being for PURE only), CALL (b) is apparently standard-conforming. Was this intended to be standard-conforming, and what should the effect be? ANSWER: This was not intended to be standard-conforming. Omission of the requirement for INTENT specification was inadvertent. An edit is supplied to correct this oversight. EDITS to 10-007: [314:7] Insert new constraint at the end of 12.8.1 "C1290a The of an elemental subprogram shall specify the intents of all of its dummy arguments that do not have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 10-174 m192 F08/0024 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0025 TITLE: DO CONCURRENT and ALLOCATABLE KEYWORDS: DO CONCURRENT, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) ... DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) ALLOCATE(x(i),STAT=j) ... y(i) = SUM(x) IF (IAND(i,1)==1) DEALLOCATE(x,STAT=j) END DO This is clearly not conforming, as it violates the requirement in [178:5-6 8.1.6.7 p1 first bullet]: "A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration." However, consider example 2, identical except for replacing the first statement with: REAL,ALLOCATABLE :: x(:) This satisfies the first restriction for allocatables - if allocated by more than one iteration, it shall be subsequently deallocated by that iteration. The second restriction for allocatables - that it not be referenced by a different iteration - only applies to allocatables allocated/deallocated by a single iteration, not by multiple iterations. Together with use of STAT= and a previously allocated array, this allows cross-iteration dependencies. Q1. Was this intended to be standard-conforming? Consider example 3 REAL,ALLOCATABLE :: x(:) ALLOCATE(x(10)) DO CONCURRENT(i=1:2) IF (i==1) THEN DEALLOCATE(x) ELSE IF (ALLOCATED(x)) THEN PRINT *,'Iteration 2 happened first' ELSE PRINT *,'Iteration 1 happened first' END IF END DO This does not fall foul of the restrictions because using ALLOCATED does not "reference" x. Q2. Was this intended to be standard-conforming? Consider example 4 REAL,ALLOCATABLE :: x(:) ... ALLOCATE(x(999)) DO CONCURRENT (i=1:3) IF (i>1) ALLOCATE(x(i)) X = 3 DEALLOCATE(x) END DO Again, the reference and DEALLOCATE in an iteration that does not ALLOCATE it is permitted because it is ALLOCATEd in more than one iteration. This would not have been permitted if x had been a pointer. Q3. Was this intended to be standard-conforming? The second allocatable restriction says [178:13-14]: "An allocatable object that is ... deallocated in only one iteration shall not be deallocated ... in a different iteration." This does not achieve anything, since the "deallocated ... in a different iteration" means that it is deallocated in more than one iteration in the first place. Q4. What is the meaning of this restriction? ANSWER: No, the examples were not intended to be standard-conforming. The restriction is faulty; an edit is supplied to correct it. EDITS to 10-007: [178:13-14] In 8.1.6.7p1, ante-penultimate bullet point, Replace the sentence "An object ... iteration." With "An allocatable object that is referenced, defined, deallocated, or has its allocation status, dynamic type, or a deferred type parameter value inquired about, in any iteration, either shall be previously allocated in that iteration or shall not be allocated or deallocated in any other iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-175 m192 F08/0025 submitted 10-175r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0026 TITLE: DO CONCURRENT and output interleaving KEYWORDS: DO CONCURRENT, output DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the trivial example: DO CONCURRENT (i=1:1) PRINT *,'Line 1' PRINT *,'Line 2' END DO According to the ultimate bullet point of 8.1.6.7, the output records appear in an indeterminate order, therefore it appears that the processor is permitted to produce the output Line 2 Line 1 for that program fragment. Q1. Is this intentional? Also, this ordering statement appears as a bullet point belonging to "The following additional restrictions apply to execution of a DO CONCURRENT construct." but it is not a restriction, either on the user or on the processor (rather the opposite of a restriction on the processor). Q2. Should this not be a separate paragraph to avoid confusion? ANSWER: A1. No, this was not intentional. An edit is supplied to correct this. A2. Yes, this should not have been a bullet point as it does not belong in the list of restrictions. EDITS to 10-007: [178:17-18] Delete the last bullet point of 8.1.6.7. [178:18+] Insert new paragraph "If records are written to a sequential file by more than one iteration, the ordering between records written by different iterations is indeterminate." {This leaves the statement within the subclause entitled "Restrictions on ..." which is suboptimal but not an actual contradiction.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-176 m192 F08/0026 submitted 10-176r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0027 TITLE: ATOMIC_REF example KEYWORDS: intrinsic, atomic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the example for ATOMIC_REF correct? ANSWER: No. The arguments are in the wrong order. EDIT to 10-007: [332:25] In 13.7.21 ATOMIC_REF, paragraph 4, change "CALL ATOMIC_REF (I[3], VAL)" to "CALL ATOMIC_REF (VAL, I[3])". SUBMITTED BY: John Reid HISTORY: 10-177 m192 F08/0027 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0028 TITLE: Does a procedure reference cause loop termination? KEYWORDS: branch, transfer of control, loop termination, procedure reference DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following DO construct DO CALL SUB END DO According to subclause 8.1.6.6.4 [177:28-29], loop termination occurs when "Control is transferred from a statement within the range of a DO construct to a statement that is neither the nor within the range of the same DO construct." A subroutine reference is a transfer of control. The first executable statement of SUB is not within the range of the DO construct. Does the loop terminate when SUB is invoked? ANSWER: It is not intended that execution of a DO construct be terminated by a procedure reference. Edits are provided to correct this. EDITS to 10-007: Replace the fourth item in the bulleted list in subclause 8.1.6.6.4 Loop termination [177:28-29] with the following: "o A branch occurs within the range of a DO construct and the branch target statement is neither the nor within the range of the same DO construct." SUBMITTED BY: Van Snyder HISTORY: 10-178 m192 F08/0028 submitted 10-178r1 m192 Draft answer 10-178r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0029 TITLE: G0 edit descriptor and floating-point output KEYWORDS: G edit descriptor, 0 width DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: For data types other than floating-point, the effect of the G0 edit descriptor is precisely defined. For floating-point output, the effect is precisely defined only if the value is an IEEE NaN or Infinity, the result is otherwise left up to the processor to select "reasonable" values for w, e, and d (if d is unspecified). The standard states [258:7-9 10.7.5.2.2p2]: "the G0 and G0.d edit descriptors follow the rules for the Gw.dEe edit descriptor, except that any leading or trailing blanks are removed". One might deduce from the wording of this that there is no upper limit on the choice of w, since the production of additional leading (or trailing) blanks has no effect on the output. Q1. Is a value for w or e that results in the field being filled with asterisks reasonable? This is not, after all, an error condition. Q2. Is a value for d that results in significant loss of precision reasonable? E.g. d==1, or for a less extreme example, d==PRECISION(value)/2. Q3. Is a value for d that produces many more digits than the precision reasonable? E.g. d==1000000. Or, for a less extreme example, d==PRECISION(quad) with a single precision value. Q4. Is a value for e that produces many more digits in the exponent than the exponent range reasonable? E.g. e==1000000. Q5. If the standard cannot tell me what "reasonable" means, what purpose does it serve for it to say that it must be reasonable? I cannot see how to tell whether a processor conforms to the standard in this respect. DISCUSSION: The standard permits, but does not require, the "best" values of w, d or e to be chosen for each internal value. ANSWER: A1. No, that is not reasonable. An edit is supplied to clarify the meaning of "reasonable". A2. No, a value of d that results in a significant loss of precision is not reasonable. An edit is supplied to correct this. A3. No, it is not reasonable for d to be ridiculously large. An edit is supplied to clarify the intent. A4. No, e should not be bigger than that required to represent the largest finite machine-representable number. An edit is supplied to specify this. A5. Yes, the use of the word "reasonable" in this context is entirely meaningless. An edit is supplied to remove this misleading terminology. EDITS to 10-007: In 10.7.5.2.2, paragraph 2: [258:9] "Reasonable processor-dependent" -> "Processor-dependent". {A5.} [258:10] After "value" insert ", that do not result in the field being filled with asterisks". {A1.} [258:10] Append new sentences to paragraph: "The value of shall not result in the production of an output value that differs from the internal value by more than 100*SPACING(value), and shall not be more than two larger than the maximum number of digits that might be required to distinguish between two different machine numbers of the kind of the internal value. The value of shall not be so large that the exponent would have a leading zero both when the internal value is the largest finite machine number and when it is the smallest finite machine number of that kind." {The first sentence limits the choice of to lose no more than 2 digits of precision (A2) and to have no more than 2 spurious digits of precision (A3); for some floating-point formats, the upper bound is not strong, being d <= 2+MAX(PRECISION(value)+2,RANGE(value)*2). The second sentence would allow e==4 for a lop-sided exponent range, e.g. -1100 to +900, but would limit e to at most 3 if the exponent range is e.g. -308 to +308 (A4). Neither of these restrictions prevent a processor from producing fewer mantissa or exponent digits for particular values if that does not result in serious loss of accuracy.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-179 m192 F08/0029 submitted 10-179r1 m192 Draft answer with straw vote on alternative 10-179r2 m192 Revised draft - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0030 TITLE: Unlimited format repeat effects KEYWORDS: repeat count DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program Program example Integer :: x(3) = (/ 1,2,3 /) Print 1,x 1 Format(1x,999999999('a',I0,'b')) Print 2,x 2 Format(1x,*('a',I0,'b')) Print 3,x 3 Format(1x,999999999('a',:,',',I0,'b')) Print 4,x 4 Format(1x,*('a',:,',',I0,'b')) End Program According to the first statement of 10.4p8 [249:12-13], "If format control encounters the rightmost parenthesis of a complete format specification and another effective item is not specified, format control terminates." This means that the first two lines of output should be a1ba2ba3ba a1ba2ba3b and the second two lines of output should be a,1ba,2ba,3ba a,1ba,2ba,3b But according to Note 10.7, "The effect of an unlimited-format-item is as if its enclosed list were preceded by a very large repeat count." which it manifestly is not. Is the normative text correct or the note? ANSWER: The note is correct. In the example above the output of the first two lines should be the same and equal to the first of the two lines and the second two lines should be the same and equal to the first of those two lines. An edit is supplied to correct the normative text. To make the following example non-standard: print 20 20 format ( *('a') ) the reused portion of the unlimited format item must contain at least one data edit descriptor. A constraint is provided. EDITS to 10-007: [246:15] After C1002 in 10.3.1, add a new constraint: "C1002A (R1005) An shall contain at least one data edit descriptor." [249:11+] Insert after the seventh paragraph of 10.3.3 a new paragraph: "If format control encounters the rightmost parenthesis of an unlimited format item, format control reverts to the leftmost parenthesis of that unlimited format item. This reversion of format control has no effect on the changeable modes (9.5.2)." [249:19-20] Change "If format control reverts ... , the" to "The" SUBMITTED BY: Malcolm Cohen HISTORY: 10-180 m192 F08/0030 submitted 10-180r1 m192 Draft answer 10-180r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0031 TITLE: PURE INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t ... CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x ... fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE zap(x) ! (1) TYPE(t),INTENT(OUT) :: x END SUBROUTINE PURE SUBROUTINE bad(y) TYPE(t),INTENT(INOUT) :: y CALL zap(y) ! (2) END SUBROUTINE END MODULE Clearly, even though subroutine zap is pure, invoking it causes impure final subroutine f to be called and so therefore it cannot be invoked in any context that requires it to be pure. Thus the call marked (2) is invalid. The question is whether the subroutine definition itself (marked (1)) is standard-conforming. If finalization of INTENT(OUT) arguments is considered to be done by the called procedure, then the subroutine definition is not standard-conforming. If finalization of INTENT(OUT) arguments is done by the caller, the subroutine definition might be standard-conforming. It would certainly seem a bit strange to be able to define a PURE procedure that cannot be invoked anywhere purity is required. DISCUSSION: Although the phrase "When a procedure is invoked" sounds like finalization occurs in the caller of a procedure and not in the called procedure, being PURE or having a finalizable INTENT(OUT) dummy argument are not grounds for an explicit interface to be required. This would appear to require, as a matter of practicality, that the processor performs the finalization of the actual argument on entry to the called procedure. I.e., that the impure final subroutine will in actuality be called from the pure procedure. ANSWER: Allowing a PURE procedure to cause invocation of impure final procedures in this way was inadvertant. An edit is supplied to clarify that any INTENT(OUT) dummy arguments of a PURE procedure must not have a relevant impure FINAL procedure. NOTE TO J3: This interpretation request has an interaction with interp F08/0034 (10-184). Care should be taken to keep these consistent. (This note should be removed in due course.) EDITS to 10-007: [312:22+] In 12.7 after C1278, insert new constraint "C1278a An INTENT(OUT) argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure." {In some other constraints we use "procedure that is not pure", but "impure procedure" is a simpler way of saying the same thing.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-181 m192 F08/0031 submitted 10-181r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0032 TITLE: PURE FUNCTION result finalization KEYWORDS: PURE FUNCTION FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t REAL c CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x x%c = 0 fcount = fcount + 1 END SUBROUTINE PURE TYPE(t) FUNCTION g(a) REAL,INTENT(IN) :: a g%c = a END FUNCTION END MODULE Even though this function is PURE, invoking it will inevitably result in the execution of the impure FINAL subroutine f. Thus, it cannot be used within another PURE procedure or from within a DO CONCURRENT loop, though it can be used from within a FORALL (because the finalizations only get done on termination of the outermost FORALL). Some other cases of impure finalization are prohibited by C1284, but not this because it does not occur "in" the procedure. Should an impurely-finalizable function result be allowed for a pure function? ANSWER: No, this should not be allowed. An edit is supplied to correct this oversight in the requirements for pure procedures. EDITS to 10-007: [24:10] 1.6.2 last sentence, "Any"->"Except as identified in this subclause, any". {This edit is also present in interp F08/0033.} [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be finalizable by an impure final subroutine. This is not permitted by this part of ISO/IEC 1539." [312:20+] In 12.7 after C1276, insert new constraint "C1276a The result variable of a pure function shall not be such that finalization of a reference to the function would reference an impure procedure." SUBMITTED BY: Malcolm Cohen HISTORY: 10-182 m192 F08/0032 Submitted 10-182r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0033 TITLE: PURE polymorphic finalization KEYWORDS: PURE CLASS FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE root REAL c CONTAINS FINAL pf PROCEDURE asgn GENERIC :: ASSIGNMENT(=) => asgn END TYPE TYPE,EXTENDS(root) :: t CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS PURE SUBROUTINE pf(x) TYPE(root),INTENT(INOUT) :: x x%c = 0 END SUBROUTINE SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE asgn(a,b) CLASS(root),INTENT(OUT) :: a CLASS(root),INTENT(IN) :: b a%c = b%c END SUBROUTINE SUBROUTINE process(array,scalar) CLASS(root) array(:),scalar FORALL (i=1:SIZE(array)) array(i) = scalar END SUBROUTINE END MODULE TYPE(root) w,x(100) TYPE(t) y(100),z ... CALL process(x,w) ! (1) CALL process(y,z) ! (2) The procedure reference at (1) will execute process with the dynamic types of its dummy arguments being TYPE(root); the finalization of the array elements caused by the defined assignment in the FORALL statement will execute only the pure procedure pf, so all is well. However, the procedure reference at (2) will execute process with the dynamic types of its dummy arguments being TYPE(t); the finalization of the array elements in this case will additionally call the impure final procedure f, so all is not well. However, this cannot be detected at compilation time. But constraint C1284 requires diagnosis of this error. Surely some mistake? Either the constraint cannot be a constraint (which would be bad, since a design goal of pure procedures is that violation of purity can be detected at compile time), or polymorphic arguments to pure procedures need to be restricted in some way. Q1. Should polymorphic INTENT(OUT) arguments to pure procedures be allowed? Note that finalization can also occur via DEALLOCATE of an ALLOCATABLE or POINTER dummy argument that is not INTENT(IN). Q2. Should ALLOCATABLE and POINTER dummy arguments of pure procedures be allowed to be polymorphic and not INTENT(IN)? Or should deallocation of any polymorphic subobject of a dummy argument simply be disallowed? Note that problematic (as in undecidable at compile time) finalization can also occur via DEALLOCATE of a non-polymorphic component of a non-INTENT(IN) argument if it has a subobject that is an ALLOCATABLE polymorphic component. Furthermore, such deallocation can occur via intrinsic assignment. Q3. Should this be constrained in some way? ANSWER: A1. This interaction between polymorphism, finalization, and purity is inadvertent. An INTENT(OUT) argument of a pure procedure should not be allowed to be polymorphic; an edit is supplied to correct this mistake. A2. Yes, deallocation of any polymorphic entity should be forbidden in a pure procedure. An edit is supplied to correct this. A3. Any statement that might result in a deallocation that is forbidden should not be allowed in a pure procedure. An edit is supplied, with a note. EDITS to 10-007: [24:10] 1.6.2 last sentence, "Any"->"Except as identified in this subclause, any". {This edit is also present in interp F08/0032.} [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted an INTENT(OUT) argument of a pure subroutine to be polymorphic. This is not permitted by this part of ISO/IEC 1539.". [312:22+] Insert new constraint "C1278b An INTENT(OUT) dummy argument of a pure procedure shall not be polymorphic." [313:6+] Insert new constraint "C1284a A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure. Note 12.48x Apart from the DEALLOCATE statement, this includes intrinsic assignment if the variable has a polymorphic allocatable component at any level of component selection that does not involve a pointer component but which might involve one or more allocatable components." SUBMITTED BY: Malcolm Cohen HISTORY: 10-183 m192 F08/0033 Submitted 10-183r1 m192 Revised note in the edit - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0034 TITLE: ELEMENTAL INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider MODULE m TYPE t1 REAL,POINTER :: vec(:) CONTAINS FINAL f1 END TYPE TYPE t2 REAL,POINTER :: vec(:) CONTAINS FINAL f2 END TYPE CONTAINS PURE SUBROUTINE f1(x) TYPE(t1),INTENT(INOUT) :: x IF (ASSOCIATED(x%vec)) DEALLOCATE(x%vec) END SUBROUTINE PURE SUBROUTINE f2(y) TYPE(t2),INTENT(INOUT) :: y(:) INTEGER i DO i=1,SIZE(y) IF (ASSOCIATED(y(i)%vec)) DEALLOCATE(y(i)%vec) END DO END SUBROUTINE ELEMENTAL SUBROUTINE zap1(z1) TYPE(t1),INTENT(OUT) :: z1 END SUBROUTINE ELEMENTAL SUBROUTINE zap2(z2) TYPE(t2),INTENT(OUT) :: z2 END SUBROUTINE END MODULE ... TYPE(t1) a,aa(10) TYPE(t2) b,bb(10) ... CALL zap1(a) ! (1) CALL zap1(aa) ! (2) CALL zap2(b) ! (3) CALL zap2(bb) ! (4) The question is which CALL statements result in finalization and thus deallocation of the various vec components. If the finalization of an INTENT(OUT) argument is considered to happen "on invocation" in the caller, then presumably the CALL statements marked (1) and (4) will result in deallocation. On the other hand, if the finalization of an INTENT(OUT) argument is considered to be done in the called procedure, then arguably it is the CALL statements marked (1) and (2) instead that will result in deallocation. In either case some clarification would seem to be useful. Q. Which statements result in deallocation of the vec components? ANSWER: A. The finalization is considered to occur in the called procedure, so the statements marked (1) and (2) will result in deallocation of the vec components. Note that this is consistent with the answer to interp F08/0031 (10-181r1). EDITS to 10-007: [76:31] At the end of 4.5.6.3 paragraph 8, append new sentence "The finalization caused by INTENT(OUT) is considered to occur within the invoked procedure; so for elemental procedures, an INTENT(OUT) argument will be finalized only if a scalar or elemental final subroutine is available, regardless of the rank of the actual argument." SUBMITTED BY: Malcolm Cohen HISTORY: 10-184 m192 F08/0034 submitted 10-184r1 m192 Selected alternative answer, fixed example - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ---------------------------------------------------------------------- NUMBER: F08/0035 TITLE: Maximum value for SHIFT argument to SHIFTL and SHIFTR KEYWORDS: SHIFTL, SHIFTR, BIT_SIZE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: A significant part of the justification for the addition of the redundant SHIFTL and SHIFTR intrinsic functions was that in the case of a nonconstant SHIFT argument, the generated code needed to test the shift direction and that such tests were inefficient. However, it is not uncommon for the actual hardware shift instructions to only shift the argument modulo the bit size, for either 32-bit or 64-bit shifts, or both. Since SHIFT is allowed to be equal to the bit size, this means that tests still need to be done to check for this case. Since being able to generate the value zero by shifting an arbitrary nonzero argument completely, applying the feature justification leads one to surmise that perhaps SHIFT should have been limited to BIT_SIZE-1 instead of BIT_SIZE. Q. Should the maximum value of the SHIFT argument to the SHIFTL and SHIFTR intrinsics be BIT_SIZE or BIT_SIZE - 1? Note: A similar argument does not apply quite so straightforwardly to SHIFTA, since it provides new functionality. ANSWER: A. Although allowing SHIFTL and SHIFTR by BIT_SIZE provides little useful functionality, this is allowed for consistency with ISHFT. EDITS to 10-007: None. SUBMITTED BY: Malcolm Cohen HISTORY: 10-185 m192 F08/0035 submitted 10-185r1 m192 Draft answer with straw vote alternative == answer not alternative - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0036 TITLE: NORM2 example in Annex C KEYWORDS: intrinsic, norm2 DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the example for NORM2 in C.13.3.6 correct? ANSWER: No. "|X_i|" should be "|X_i|^2". EDIT: [527:18 p3] In C.13.3.6 Vector norms (13.7.2, 13.7.109, 13.7.123), paragraph 3, replace "|X_i|" by "|X_i|^2". SUBMITTED BY: John Reid HISTORY: 10-186 m192 F08/0036 submitted 10-186r1 m192 Draft answer 10-186r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0037 TITLE: PROCEDURE POINTER vs PROTECTED KEYWORDS: PROCEDURE, PROTECTED DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following module fragment correct syntax for an abstract interface i_f? procedure(i_f), pointer, protected :: p_f1 => null() F2008 10-007 [100:4] C549 says "An entity with the PROTECTED attribute shall be a procedure pointer or variable." But 12.4.3.6 [287:11+] does not list PROTECTED as an allowable attribute on the procedure declaration statement. ANSWER: The module fragment was intended to be standard-conforming. An edit is provided to correct this. EDITS to 10-007: [287:15+] in R1213 after "<> POINTER", insert a new line "<> PROTECTED" SUBMITTED BY: Stan Whitlock HISTORY: 10-188 m192 F08/0037 submitted 10-188r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ----------------------------------------------------------------------- NUMBER: F08/0038 TITLE: Are pointless restrictions on DIM arguments intended? KEYWORDS: DIM argument, optional, intrinsic reduction function DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot DISCUSSION: Some of the reduction functions have two forms, one with a DIM argument and one without; the DIM argument is not optional. IALL is an example. Other reduction functions have a DIM argument that is optional. COUNT is an example. The actual argument corresponding to the DIM actual argument is prohibited from being an optional dummy argument in both cases. The reason in the case of an optional DIM argument is so that the processor can determine the rank of the result. In the case of those with two forms, there is no problem for the processor to determine the rank, so the prohibition against the corresponding actual argument being an optional dummy argument is pointless. There is already a prohibition against it being an absent optional dummy argument in 12.5.2.12p3(4). Consider, for example subroutine S ( ARRAY, DIM ) integer, intent(in) :: ARRAY(:,:) integer, intent(in), optional :: DIM if ( present(dim) ) then print *, iall(array,dim) else print *, iall(array) end if end subroutine S This subroutine clearly does not conform, but a processor would have no difficulty determining the rank of the result of IALL(ARRAY,DIM). QUESTION: (1) Was the pointless restriction intentional, or was it an oversight that it did not get removed in the two-form case when MAXLOC etc. were added? (2) Is it necessary to continue the pointless restriction? ANSWER: (1) This was an oversight. (2) No. Edits are provided to remove it. EDITS to 10-007: [13.2.4p1 316:26] Insert "absent" before "optional". [13.7.61p3 347:34] Delete "The corresponding ... optional dummy argument." [13.7.71p3 352:27] Delete "The corresponding ... optional dummy argument." [13.7.73p3 353:22] Delete "The corresponding ... optional dummy argument." [13.7.83p3 357:30] Delete "The corresponding ... optional dummy argument." [13.7.108p3 366:29] Delete "The corresponding ... optional dummy argument." [13.7.109p3 367:35] Delete "The corresponding ... optional dummy argument." [13.7.114p3 369:36] Delete "The corresponding ... optional dummy argument." [13.7.115p3 371:2] Delete "The corresponding ... optional dummy argument." [13.7.133p3 379:7] Delete "The corresponding ... optional dummy argument." [13.7.161p3 390:22] Delete "The corresponding ... optional dummy argument." Additional edits if interp F08/0003 passes ------------------------------------------ [13.7.10p3 328:8] Delete "The corresponding ... optional dummy argument." [13.7.13p3 329:12] Delete "The corresponding ... optional dummy argument." [13.7.123p3 374:29-30] Delete "The corresponding ... optional dummy argument." [13.7.128p3 377:26] Delete "The corresponding ... optional dummy argument." [13.7.165p3 392:12-13] Delete "The corresponding ... optional dummy argument." SUBMITTED BY: Van Snyder HISTORY: 10-187r1 m192 F08/0038 submitted 10-187r2 m192 Revised edit - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------ NUMBER: F08/0039 TITLE: Many-one vector subscript usage KEYWORDS: Vector subscripts. DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider SUBROUTINE zap(z,i) REAL z(:) INTEGER i(:) IF (no_duplicates(i)) z(i) = 0 END SUBROUTINE ... REAL x(10) ... CALL zap(x,(/ 2,3,2 /)) (The user-defined function no_duplicates returns .TRUE. if and only if its argument has no duplicate values.) 6.5.3.3.2 "Vector subscript" paragraph 3 says: "If a vector subscript has two or more elements with the same value, an array section with that vector subscript shall not appear in a variable definition context (16.6.7)." In the execution of zap from the CALL statement, the array section z(i) has a vector subscript with two elements with the same value, and appears in a variable definition context, in violation of the stated requirement. Q. Is this program fragment standard-conforming? ANSWER: Yes, this program is standard-conforming. The quoted requirement is poorly worded; an edit is supplied to correct it. EDITS to 10-007: [124:9] Replace "shall ... (16.6.7)" with "is not definable and shall not be defined or become undefined". SUBMITTED BY: Malcolm Cohen HISTORY: 10-195 m192 F08/0039 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot 10-199 ------------------------------------------------------------------------