J3/15-187 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #33 Date: 2015 July 19 Here are the results of J3 letter ballot #33 on Fortran interpretations that officially closed 24-Apr-2015. The ballot is in J3 paper 15-159 for meeting #207. 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 / interp 126 127 128 129 130 131 132 133 134 135 136 137 result of LB #33 Y A N A A Y Y Y Y A A A Daniel Chen Y Y N Y Y Y Y Y Y Y Y Y Tom Clune Y C Y Y Y Y Y Y Y Y Y Y Malcolm Cohen Y Y C Y Y Y Y Y Y Y Y C Robert Corbett Y N Y Y Y Y Y Y Y C C N Mark Leair Y Y Y Y Y Y Y Y Y Y Y Y Bill Long Y Y N Y Y Y Y Y Y Y Y N Toon Moene Y Y N Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y N C C Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y 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 interps marked "Y" pass with no change. The interps marked "A" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006. /Stan ************************************************************************ F08/0126 Can cobounds be referenced in the same type declaration? Result for F08/0126: All Yes votes, no Comments, and no No votes. F08/0126 passed by J3 letter ballot. F08/0127 May an initial line begin with a semicolon? Tom Clune's yes vote comment on F08/0127: Seems to be a trivial/unnecessary restriction. But use case also seems to be equally trivial/unnecessary. Robert Corbett's no vote on F08/0127: The existing text and the proposed edit do not completely encompass the change made to the language. The restriction that was removed was A ``;'' shall not appear as the first nonblank character on a line. (Clause 3.3.1.3, paragraph 2 of the Fortran 2003 standard). The quoted sentence appears in the description of free source form. The existing text and the text after the applying the edit refer only to the line beginning with a semicolon, not a sequence of blanks followed by a semicolon. I would change my vote to yes if the proposed edit is replaced with [xvi] Replace "A line in the program is permitted to begin with a semicolon." with "A free form continuation line is permitted to begin with zero or more blanks followed by a semicolon." Result for F08/0127: Robert's suggestion is accepted. F08/0127 passed as amended by J3 letter ballot. F08/0128 Is recursive USE within a submodule permitted? Daniel Chen's no vote on F08/0128: The NO vote is to A2. If a module does not have any module procedure interface body, submodules extends such a module are useless. Allowing accessing private module variables from such a module forces the compiler to write the private module variables into the module symbol file or some sort. If all the module procedure interface bodies are defined in a submodule's ancestor module or ancestor submodules, the submodule is useless. Again, there is really no point of accessing a private variable in such a submodule. There are two possible fixes: 1. A submodule whose ancestor module doesn't have any module procedure interface body or all the module procedure interface bodies are defined in its ancestor module or ancestor submodules should not be allowed. Or 2. Accessing a private variable by host association in a submodule is permitted only if its ancestor module has at least one module procedure interface body. There could be other solutions. The goal is to avoid recording private variables if it is useless. Malcolm Cohen's response [#1] to Daniel Chen's no vote on F08/0128: >> The NO vote is to A2. >> If a module does not have any module procedure interface body, >> submodules extends such a module are useless. Although I agree that a submodule extending a module with no mpib, or a submodule that has no outstanding undefined mpibs, is not at all useful, it really does not have anything to do with the interp as such. Example m2 has "..." indicating that declarations in the module were omitted as being not germane to the question (of whether it has any mpib). We could add an explicit one to the module, but since it has nothing to do with the accessibility of variable A or the protection of variable B, it would seem to be completely irrelevant to the question being asked. Unless I am mistaken, the submodule TR definitely allowed uselessly extending a module or submodule. But I would have no particular problem with disallowing that in F2008, if everyone else agrees. It's pretty late in the day for doing that, but not so many people have implemented submodules yet... But it really is a separate issue, and should be answered via a separate interp. Malcom Cohen's further comments [#2] on Daniel Chen's no vote on ...: Daniel Chen wrote some text explaining why being able to uselessly extend a module was harmful. I [Malcolm] wrote: > Unless I am mistaken, the submodule TR definitely allowed > uselessly extending a module or submodule. But I would have no > particular problem with disallowing that in F2008, if everyone > else agrees. Van Snyder wrote: > I don't see any point in bothering with this. We allow an empty > main program. We allow an empty module. We allow modules with > no public entities. We allow an empty subprogram. We allow an > IF construct with no in it.... Right, but Daniel suggested that not only was this useless, but also harmful to some extent. Some might agree with that. I have no problem with disallowing this IN FORTRAN 2008 via the defect resolution (interpretation) process, if that is what the rest of the committee(s) agree. I am absolutely not suggesting we leave it permitted in F2008 but taking it out of F2015. That would be irrational and unacceptable. Bill Long's comment [#3] on Malcolm Cohen's comment [#2] on ...: As one of the vendors that started implementing submodules based on the TR and early F2008 drafts, we still disallow USE of the ancestor module in a submodule. If we reinstated that rule, these other issues would disappear. I see allowing use of the ancestor module as pointless and confusing, and a good candidate for "wart" status. Daniel Chen's comment on Bill Long's comment [#3] on ...: We implemented the submodule feature already and we support USE of the ancestor module in a descendant submodule. However, I have NO objection to disallow it as Bill suggested. That being said, if this approach is not feasible, I am strongly in favor of disallowing the 'useless' submodule as an interp of F2008 as Malcolm mentioned. Malcolm Cohen's yes vote comment on F08/0128: (1) I did not like adding this (USE of ancestor module) in the first place. But I am even less convinced that we should be redesigning it. (2) The edit instruction for [100:12] is incomplete: it should state to insert the text immediately after the word "descendants" (i.e. before the comma). Bill Long's no vote on F08/0128: The discussion in this interp illustrates why the argument in 09-141 was wrong. I think a better answer for this interp is that passing 09-141 was a mistake and it is being corrected by reinstating the prohibition on a submodule using its ancestor. An alternative, but equivalent answer, is that there is no rational reason to allow use of its ancestor module in a submodule, and the failure to prohibit this is an error in the standard. Reinhold Bader's comment [#1] on Bill Long's no vote on F08/0128: I agree that there is no need to allow use access to any entity from the ancestor module in a submodule. However, I consider the following not only reasonable, but also quite often necessary: module mod_a type :: a ... end type end module module mod_b use mod_a type :: b type(a) :: a end type end module submodule(mod_a) :: submod use mod_b, only : b end submodule This, I think, would also be prohibited if the old restriction is reinstated. The feature request that I handed in ended up as 08-154r1, but subsequently triggered an UTI, as far as I recall. Is there any way to retain the above example as conforming? Note that the ONLY clause implies that no entity from the ancestor module is accessed; any access to "a" inside the submodule would work via host association. Bill Long's comment [#2] on Reinhold Bader's comment [#1] on ...: A bit convoluted, but I can imagine someone wanting to do this. Two possible solutions: 1) Make the rule "An entity in a module shall not be accessible by use association in a submodule of that module.". This avoids the conflict of the entity appearing to be accessed by both use and host association. 2) There was a proposal for a PRIVATE attribute on a USE statement. In the example above, module mod_b use, private :: mod_a would prevent anything from module mod_a from being accessible by use association in a subsequent scope via a USE of mod_b. Basically shorthand for listing everything use accessible from module mod_a in a PRIVATE statement in module mod_b. One could argue that this is equivalent to avoiding a USE of mod_a in the submodule. Van Snyder's comment on Reinhold Bader's comment [#1] on ...: Another point to be made is that allowing access to the ancestor module by use association raises the questions about visibility posed by the interp. The outcome that use association trumps host association might be unexpected by students who haven't studied both rules, and their interactions, carefully. The interaction observed in the interpretation is new, because accessing an entity by use association, that is already accessed by host association, was impossible until 09-141. The first note on page 7 of N1602 makes it clear that usage envisioned during development of the TR was at least module Mod_A ... end module Mod_A submodule(mod_a) :: Submod_A use b... end submodule Submod_A module Mod_B ... end module Mod_B submodule(mod_b) :: Submod_B use a... end submodule Submod_B The usage that Reinhold envisions would be useful, and we ought not to prohibit it. I don't think this can be handled in the general case, especially if PRIVATE or PROTECTED entities are involved, by moving the cross-using exclusively into the submodules, or by using a third module. Van Snyder's comment on Bill Long's comment [#2] on ...: Alternatively [to 1)], "A submodule shall not access an entity of its ancestor module by use association." Another possibility [to 2)] is another attribute for a USE statement that says "I only want the stuff that's declared or defined in the specified module -- nothing it got by use association -- maybe something like submodule(mod_a) :: submod use, direct :: mod_a [, only: ....] This would put the onus on submod instead of mod_b. Would either of these proposals allow access to the type(a) component of type b in submod? Probably, because type a is accessible in submod by host association. Toon Moene's no vote on F08/0128: The discussion that ensued *after* this interp passed the committee indicates to me that we didn't think this through enough. Back to the drawing board, please. Van Snyder's no vote on F08/0128: Answers to and edits for Q1 and Q2 are not problematic. The answer to Q3, that an entity with the PROTECTED attribute that is accessed in a submodule by use association from its ancestor module is not definable introduces a contradiction in 5.3.15. C551 and C552 clearly state that an entity that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition or pointer association context. 5.3.15p2, however, makes an exception for descendants of the module in which the entity is given the PROTECTED attribute. The submodule TR did not envision that the ancestor module would be accessible by use association, and therefore no contradiction arose, at least not one related to submodules. Since this is an entirely new concept, not envisioned in the TR, the answer to Q3 could go either way. I prefer that the answer be that a protected entity is not protected in a submodule of the module where it is given the attribute, even if it is accessed therein by use association. To that end, constraints C551 and C552 should be revised to begin in the same way that 5.3.15p2 begins, viz. "Other than within the module in which an entity is given the PROTECTED attribute, or within any of its descendants...." If we truly desire that a protected entity accessed from the ancestor module by use association be protected, then 5.3.15p2 needs attention to remove the inconsistency between it and C551/C552, viz. "Where an entity is accessed by use association, if it has the PROTECTED attribute in the module from which it is accessed then". There is an additional problem here, that is properly the topic of a different interpretation because it is not related to submodules. Suppose a variable is declared in a module. Suppose it is accessed by use association in another module, and given the PROTECTED attribute there. 5.3.15p2 appears to make it undefinable in the module in which it is originally declared. This is absurd. Either 5.3.15p2 needs revision, or it should be prohibited to confer the PROTECTED attribute upon an entity that is accessed by use association. Result for F08/0128: Malcolm's fix for [100:12] is accepted. The submodule TR allowed uselessly extending a module or submodule. We could disallow that in F2008 but it really is a separate issue and should be answered via a separate interp. It is unacceptable to permit this in F2008 but remove it from F2015. This interp needs more work. F08/0128 failed J3 letter ballot. F08/0129 Is CLASS(type) required to refer to a prior type definition? Van Snyder's yes vote comment on F08/0129: The TITLE: line for F08/0129 in 15-159 (and eventually 006) needs to be filled. Result for F08/0129: Van's suggestion is accepted. F08/0129 passed as amended by J3 letter ballot. F08/0130 Does coarray allocation sync even with stopped images? Van Snyder's yes vote comment on F08/0130: Edit instructions for [131:17-18] are inconsistent with the exposition of the entire revised paragraph. In the revised paragraph, insert "apart from STAT_STOPPED_IMAGE" before "occurs" in the third line. Result for F08/0130: Van's suggestion is accepted, reworded as "other than STAT_STOPPED_IMAGE". F08/0130 passed as amended by J3 letter ballot. F08/0131 Are the changes to C_LOC in the 2010 revision intentional? Result for F08/0131: All Yes votes, no Comments, and no No votes. F08/0131 passed by J3 letter ballot. F08/0132 Can a procedure pointer be declared with an interface block? Result for F08/0132: All Yes votes, no Comments, and no No votes. F08/0132 passed by J3 letter ballot. F08/0133 Is unallocated actual associated with nonallocatable dummy OK? Result for F08/0133: All Yes votes, no Comments, and no No votes. F08/0133 passed by J3 letter ballot. F08/0134 in an image control statement Result for F08/0134: All Yes votes, no Comments, and no No votes. F08/0134 passed by J3 letter ballot. F08/0135 Vector subscripted actual makes VALUE dummy undefinable? Robert Corbett's yes vote comment on F08/0135: I would like a "SUBMITTED BY:" clause to be added to the interpretation. The paper containing the interpretation was submitted by Van. Result for F08/0135: Robert's suggestion is accepted. F08/0135 passed as amended by J3 letter ballot. F08/0136 Argument correspondence with VALUE and ASYNCHRONOUS Robert Corbett's yes vote comment on F08/0136: I would like a "SUBMITTED BY:" clause to be added to the interpretation. The paper containing the interpretation was submitted by Van. Result for F08/0136: Robert's suggestion is accepted. F08/0136 passed as amended by J3 letter ballot. F08/0137 Result of TRANSFER when MOLD is an array with element size zero Malcolm Cohen's yes vote comment on F08/0137: (1) The code for example 3 does not show any problem. I recommend changing REAL c to REAL c(0) (2) The description of the problem is a bit confusing as it only mentions the problem in example 1, then goes on to say "these examples". I recommend, after "the size of a zero-length character is zero", inserting "and the size of the above derived types may be zero", (3) Example 7 is not valid Fortran. I recommend the change suggested by Bill Long. (4) In the answer, it flatly states that examples 1-3 are not conforming, but although this is true for example 1, examples 2 and 3 are conforming on a processor that has a nonzero minimum size for a derived type. I recommend changing Examples 1-3 are not conforming to Example 1 is not conforming, and if the derived types have size zero in examples 2 and 3, those examples are also not conforming, Robert Corbett's no vote on F08/0137: I do not like the proposed interpretation. I would prefer the definition of TRANSFER to specify a result for all sets of arguments. Defining some combinations of arguments not to be conforming does not promote portability. I would prefer that when the argument MOLD is an array whose elements have storage size zero, the result be an array of rank one and size zero. Bill Long's no vote on F08/0137: The answer for Example 7 is nominally wrong since the example has a declaration of a dummy argument (source4) that includes initialization. That is sufficient to make the example non-conforming. The example code can be repaired by changing the declaration of source4 to something like this: CHARACTER(999) :: source4(10) = REPEAT('!',999) ! Ditto. which seems to preserve the intent of the question while avoiding the error. With this change, I'd change my vote to Yes. I'll leave it to /Interp to decide whether J3 needs to revote a corrected version of the interp (since others have already voted on the current wording), or just fix it and send it on to WG5. Result for F08/0137: Malcolm's changes, including Bill's change, are accepted. F08/0137 passed as amended by J3 letter ballot. ---------------------------------------------------------------------- NUMBER: F08/0126 TITLE: Can cobounds be referenced in the same type declaration? KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Do the following declarations conform to the Fortran 2008 standard? integer :: A[5,*] = ucobound(a,1) ) integer :: C[5,ucobound(c,1),*] integer :: B[5,*], C[ucobound(b,1),*], D(ucobound(c,1)) ANSWER: 7.1.11p8 says "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the ...." This does not establish an interpretation for any of the declarations. The intent of interpretation F95/000090 was that the third one be allowed, while the first and second be prohibited. Edits are provided to correct this oversight. EDITS: [10-007r1:151:7-8 7.1.11p8] Replace "or an array bound" with ", an array bound, or a coarray bound". Replace "or array bound" with ", array bound, or coarray bound". SUBMITTED BY: Van Snyder HISTORY: 15-102 m206 F08/0126 submitted 15-102r2 m206 Passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0127 TITLE: May an initial line begin with a semicolon? KEYWORDS: Semicolon DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The Introduction to ISO/IEC 1539-1:2010, page xvi, states "A line in the program is permitted to begin with a semicolon." Therefore, do the following 3 lines constitute a valid program. ;PROGRAM bad PRINT *,'No' END PROGRAM ANSWER: No, the example is not a valid program as it does not satisfy the syntax rules and constraints. As stated in 3.3.2.5 and 3.3.3.4, a semicolon may be used to terminate a statement. That is not the case in the example, since there is no statement before the semicolon. The semicolon does not appear anywhere else in the Fortran syntax and therefore the example does not conform. An edit is supplied to the Introduction to clarify the change in Fortran 2008. EDITS: [xvi] Replace "A line in the program is permitted to begin with a semicolon." with "A free form continuation line is permitted to begin with zero or more blanks followed by a semicolon." SUBMITTED BY: Malcolm Cohen HISTORY: 15-105 m206 F08/0127 submitted - passed by J3 meeting 15-xxx m207 Passed as amended by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0128 TITLE: Is recursive USE within a submodule permitted? KEYWORDS: SUBMODULE, USE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider Module m1 Real x End Module Submodule(m1) subm1 Use m1 End Submodule Q1. The module m1 is referenced from within one of its own submodules. Is this standard-conforming? Note that the "submodule TR", Technical Report 19767 contains, an edit with the normative requirement: "A submodule shall not reference its ancestor module by use association, either directly or indirectly." along with a note which says "It is possible for submodules with different ancestor modules to access each other's ancestor modules by use association." It also contains an edit to insert the direct reference prohibition as a constraint. However, none of this text appears in ISO/IEC 1539-1:2010. The Introduction simply comments that submodules are available, but not that they have been extended beyond the Technical Report that created them. Also, consider Module m2 Real, Private :: a Real, Protected :: b ... End Module Submodule(m2) subm2 Contains Subroutine s Use m2 Implicit None a = 3 b = 4 End Subroutine End Submodule In submodule SUBM2, procedure S references M2 by use association. Use association does not make "A" accessible. Q2. Is "A" still accessible by host association? Also, procedure S attempts to assign a value to B, which is accessed by use association, but has the PROTECTED attribute. Normally, this attribute prevents assignment to variables accessed by use association. Q3. Is the assignment to "B" standard-conforming? DISCUSSION: The requirement appears in the early drafts of Fortran 2008, up to 08-007r1, then it was modified by paper 08-154r1 creating a UTI (because the modification was broken), and finally the requirement was completely removed by paper 09-141. ANSWER: A1. Yes, the example is conforming. An edit is supplied to add this extension to the Introduction, and to add normative text to clause 11 to make this completely unambiguous. A2. Yes, A is still accessible by host association. Subclause 16.5.1.4 paragraph 2 states "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." This does not apply since A is not being accessed by use association (because it is PRIVATE), therefore A can still be accessed by host association. {J3 note: no edit necessary here.} A3. No, the assignment to B is not conforming as it violates constraint C551 which states "A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition context..." An edit is provided to add an explanation of this. EDITS: [xv] Introduction, p2, first bullet, After "Submodules provide ... for modules." Insert new sentence "A submodule can reference its ancestor module by use association." [100:12] 5.3.15 PROTECTED attribute, insert this text immediately after the word "descendants" (i.e. before the comma) "where it is accessed by host association". [272:23] 11.2.2 The USE statement and use association, p1, After "A module shall not reference itself, either directly or indirectly." Append to paragraph "A submodule is permitted to reference its ancestor module by use association. " [273:2+4] Same subclause, NOTE 11.7, append "If a submodule accesses a PROTECTED entity from its ancestor module by use association, use of that entity is constrained by the PROTECTED attribute, e.g. if it is not a pointer it cannot appear in a variable definition context.". SUBMITTED BY: Malcolm Cohen HISTORY: 15-134 m206 F08/0128 submitted 15-134r1 m206 Revised edits - passed by J3 meeting 15-xxx m207 Failed J3 letter ballot 15-159 ** Result for F08/0128 from 15-xxx: Malcolm's fix for [100:12] is accepted. The submodule TR allowed uselessly extending a module or submodule. We could disallow that in F2008 but it really is a separate issue and should be answered via a separate interp. It is unacceptable to permit this in F2008 but remove it from F2015. ---------------------------------------------------------------------- NUMBER: F08/0129 TITLE: Is CLASS(type) required to refer to a prior type definition? KEYWORDS: CLASS, type definition DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does the CLASS(T) declaration of X in the following conform? recursive subroutine S ( N, X ) integer :: N class(t), optional :: X type :: T integer :: Q end type T ... ANSWER: Although subclause 4.3.1.3 does not require the in a CLASS specifier to refer to a previously-defined type, it was intended that CLASS declarations with be parallel to TYPE declarations. In a TYPE declaration (4.3.1.2), the specified derived type is required to be previously defined, or accessed by use or host association. Therefore the example ought not to conform. Edits are provided to correct this oversight. EDITS: [12-007:6+ 4.3.1.3p1+] Insert a paragraph: "Where a data entity other than a component is declared explicitly using the CLASS specifier to be of derived type, the specified derived type shall have been defined previously. If the data entity is a function result, the derived type may be specified in the FUNCTION statement provided the derived type is defined within the body of the function or is accessible there by use or host association. If the derived type is specified in the FUNCTION statement and is defined within the body of the function, it is as if the function result variable were declared with that derived type immediately following the of the specified derived type." {This is essentially identical to 4.3.1.2p1, except for the replacement of "TYPE" with "CLASS" and the addition of "other than a component" (4.3.1.2p1 does not mention components, but it ought to because otherwise it would contradict C440), but that's a different question.} SUBMITTED BY: Van Snyder HISTORY: 15-127 m206 F08/0129 submitted 15-127r1 m206 Passed by J3 meeting 15-xxx m207 Passed as amended by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0130 TITLE: Does coarray allocation sync even with stopped images? KEYWORDS: ALLOCATE, DEALLOCATE, coarray, synchronization, stopped DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Example 1: Consider the trivial program Program m206c7e1 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Stop 'Image 1 is now stopping' End If Allocate(x(100)[*],Stat=stat) ! If (me==2) Print *,'Arrived' !***A ! If (stat==0) Error Stop 'INCONCEIVABLE' If (stat/=Stat_Stopped_Image) Error Stop 'Bad STAT' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***B End Do End Program Q1. On images other than image 1, does execution ever reach the statement with comment "!***A"? 6.7.1.2 Execution of an ALLOCATE statement, p4 says "When an ALLOCATE statement is executed for which an allocate-object is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the statement is delayed until all other images have executed the same statement the same number of times." The second sentence seems to say that execution on images>1 is delayed forever, since image 1 will never execute that ALLOCATE statement. Example 2: Consider the program Program m206c7e2 Use Iso_Fortran_Env Implicit None Real(real32), Allocatable :: x(:,:,:,:)[:],y(:,:,:,:) Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Allocate(y(1000,1000,1000,1000)) !***C End If Allocate(x(1000,1000,1000,1000)[*],Stat=stat) !***D ! If (me==1 .And. stat==0) Error Stop 'Inconceivable!' ! If (stat==0) Print *, 'ALLOCATE ok on image', me !***E ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***F End Do End Program For purposes of discussion, let us assume that each image has 6 Terabytes of memory available to it for dynamic allocation. The ALLOCATE statement commented "!***C" will allocate 4 terabytes of memory on image 1. Execution of the ALLOCATE statement commented "!***D" will attempt to allocate 4 terabytes on each image; this will fail on image 1 as there is insufficient memory available, but could succeed on other images. Q2. Is the success of an ALLOCATE statement the same on every image, or may it fail on some images and succeed on others? That is, might the statement commented "!***E" execute the PRINT on some images (but not all). Q2 continuation: If the answer is that the ALLOCATE must either succeed or fail on all images, can the STAT= value differ by image (for example, might a processor return a different STAT= code for "no memory on this image" and "no memory on some other image"). Example 3: Consider the program Program m206c7e3 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Call do_something_that_takes_a_very_long_time End If Allocate(x(100)[*],Stat=stat) !***G ! If (stat==0) Error Stop 'INCONCEIVABLE' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***H End Do End Program Let us imagine that the processor operates some form of "timeout" mechanism, for example, if an image fails to reach a synchronization point within an hour of the first image reaching that statement, an error is returned. (If the slow image subsequently reaches that statement, one might conjecture that it will also get an error, but probably STAT_YOU_ARE_TOO_SLOW rather than STAT_TIMEOUT). In the example above, let us assume that the ALLOCATE statement commented "!***G" fails, e.g. with a timeout error as we imagined above. Q3. After resolution of question 1, which images are synchronized after execution of an ALLOCATE statement that fails? That is, is execution of the statements commented "!***B" (in Q1), "!***F" (in Q2) and "!***H" (above) permitted, or are they impermissible references to variables in unordered segments? In the case of "!***B", one might conjecture that all the non-stopped images are synchronized. In the case of "!***F" the text of the standard appears to require that image 1 has to wait for all the other images, but it might equally be conjectured that that is a mistake and that since it knows straightaway that it cannot satisfy the memory allocation it should be allowed to return straightaway without synchronizing, i.e. the "!***F" is not allowed. In the case of "!***H", image 1 has still not even reached the ALLOCATE statement (after an hour of the others waiting), so it would seem that it is impossible for it to have synchronized as required by the standard, and therefore that (for i==1 at least) the execution of "!***H" is not allowed. Q4. When allocation of a coarray is involved, and an error occurs (e.g. as in the examples above, plus other cases), under what situations does the coarray in question become allocated? In particular, can a coarray be allocated on some images but not others? If the answer is that the coarray never becomes allocated, that means that in the case of a stopped image, the remaining images cannot allocate any coarray. Q5. Do the answers to Q1-Q4 also apply to DEALLOCATE statements? ANSWER: A1. In the case of stopped images, the requirement in 6.7.1.2 was only intended to apply to the non-stopped images. An edit is provided to correct this mistake. A2. Allocation of a coarray was intended only to succeed if it succeeds on all images. An edit is provided to add this missing requirement. (A2 continuation) There was not intended to be any requirement that a nonzero STAT= value be the same on each image. No edit is provided to add such a requirement. A3. After execution of an ALLOCATE statement that returns an error other than STAT_STOPPED_IMAGE, there was not intended to be any requirement for synchronization. An edit is provided to correct this mistake. A4. The coarray can become allocated on an image if and only if it can become allocated on all other images. An edit is provided to add this requirement. The consequence in the case of a stopped image is indeed that no image can subsequently change the allocation status of any coarray. A5. Yes, the answers also apply to DEALLOCATE statements. Corresponding edits are supplied. EDITS: [128:16-17] 6.7.1.2 Execution of an ALLOCATE statement, p4, Change "On each image" to "If no error condition apart from STAT_STOPPED_IMAGE occurs," Change "all other images" to "all non-stopped images", {A1,A3: Synchronization only applies to successful allocations and to allocations that fail only due to STAT_STOPPED_IMAGE.} Append a sentence requiring allocation success consistency for coarrays, making the whole paragraph read: "When an ALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition apart from STAT_STOPPED_IMAGE occurs, execution of the segment following the statement is delayed until all non-stopped images have executed the same statement the same number of times. The coarray shall not become allocated on an image unless it is successfully allocated on all images." {A2,A4: Last sentence is the consistency requirement.} [131:17-18] 6.7.3.2 Deallocation of allocatable variables, p11, Change "On each image" to "If no error condition other than STAT_STOPPED_IMAGE occurs," Change "all other images" to "all non-stopped images", Append a sentence requiring deallocation consistency, making the whole paragraph read: "When a DEALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition other than STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2) following the statement is delayed until all non-stopped images have executed the same statement the same number of times. If the coarray is a dummy argument, its ultimate argument (12.5.2.3) shall be the same coarray on every image. The coarray shall not become deallocated on an image unless it is successfully deallocated on all images." SUBMITTED BY: Malcolm Cohen HISTORY: 15-133 m206 F08/0130 submitted 15-133r1 m206 Passed by J3 meeting 15-xxx m207 Passed as amended by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0131 TITLE: Are the changes to C_LOC in the 2010 revision intentional? KEYWORDS: C_LOC, interoperability DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The description of C_LOC in the intrinsic module ISO_C_BINDING permits noninteroperable array arguments that are contiguous, provided the type and kind are interoperable. This was not permitted by the previous revision of ISO/IEC 1539-1, which required all type parameters to be interoperable (and only exempted allocatable arrays from the "interoperable variable" requirement); however this is not listed in the Introduction as a change. For example, each of the following is apparently permitted as arguments to C_LOC by the requirements in Fortran 2008 but not in Fortran 2003: CHARACTER(13,C_char),TARGET :: x(100) CHARACTER(14,C_char),TARGET :: y REAL(C_float),CONTIGUOUS :: dummy1(:) INTEGER(C_int),CONTIGUOUS,POINTER :: z(:) (the CONTIGUOUS attribute does not exist in Fortran 2003). and also REAL(C_float) :: dummy2(:) INTEGER(C_int),POINTER :: z2(:) when dummy1 is argument-associated with a contiguous array, and z2 is pointer-associated with a contiguous array. Was this change intended? ANSWER: Yes, this change was intentional. An edit is provided to add this to the Introduction. EDITS: [xvi] Introduction, "Intrinsic modules" bullet point, Before "The function C_SIZEOF" insert new sentence "A contiguous array that is not interoperable but which has interoperable kind and kind type parameter, and a scalar character variable with length>1 and kind C_CHAR, can be used as the argument of the function C_LOC in the intrinsic module ISO_C_BINDING, provided the variable has the POINTER or TARGET attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 15-132 m206 F08/0131 submitted 15-132r1 m206 Revised edits 15-132r2 m206 Revised question - passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0132 TITLE: Can a procedure pointer be declared with an interface block? KEYWORDS: procedure pointer, interface block DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program PROGRAM c11 INTERFACE REAL FUNCTION F() END FUNCTION END INTERFACE POINTER F EXTERNAL G F => G PRINT *,F() END PROGRAM REAL FUNCTION G() G = 206 END FUNCTION According to 12.4.3.2 paragraph 5, F is an external procedure (and seems to be missing). There is no mention of the possibility of a procedure pointer in the subclause on interface blocks. Is this intended to be standard-conforming? ANSWER: Yes, this is intended to be standard-conforming. An edit is supplied to correct the mistake in 12.4.3.2. EDITS: [281:26] In 12.4.3.2 Interface block, paragraph 5, After "specific interface for an external procedure" change "or a dummy procedure" to ", dummy procedure, or procedure pointer". {Add procedure pointer for the list of things this can declare.} [281:27-28] Same paragraph, After "interface body, the procedure is a dummy procedure" change "; otherwise" to ". If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure and is not a procedure pointer,". {Correct how we establish what it is.} This makes that whole paragraph read: An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an explicit specific interface for an external procedure, dummy procedure, or procedure pointer. If the name of the declared procedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a dummy procedure. If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure and is not a procedure pointer, it is an external procedure. {Note careful wording to avoid saying that a dummy procedure is not a procedure pointer, since a dummy procedure pointer is indeed both a dummy procedure and a procedure pointer.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-136 m206 F08/0132 submitted - passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0133 TITLE: Is unallocated actual associated with nonallocatable dummy OK? KEYWORDS: OPTIONAL, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the 2008 standard? program P integer, allocatable :: I(:) call s ( i ) contains subroutine S ( A ) integer, intent(in), optional :: A(:) if ( present(a) ) then print *, 'A = ', a else print *, 'A is not present' end if end subroutine S end program P Subclause 6.7.1.3 says, concerning an unallocated allocatable variable, "It shall not be supplied as an actual argument corresponding to a nonallocatable dummy argument, except to certain intrinsic inquiry functions." On the other hand, subclause 12.5.2.12 says a dummy argument "is not present if the dummy argument ... does not have the ALLOCATABLE ... attribute, and corresponds to an actual argument that ... has the ALLOCATABLE attribute and is not allocated...." ANSWER: The intent was that the program conforms, and prints "A is not present", as specified by subclause 12.5.2.12. Edits are provided to correct this mistake. EDITS: [10-007r1:129:8 6.7.1.3 p1, second item in bulleted list] Insert "nonoptional" before "nonallocatable". {Optional editorial fiddling:} [10-007r1:129:8 6.7.1.3 p1, second item in bulleted list] Delete "supplied as"; replace "corresponding" with "that corresponds". SUBMITTED BY: Van Snyder HISTORY: 15-141 m206 F08/0133 submitted - passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0134 TITLE: in an image control statement KEYWORDS: stat=, image control statement DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended to allow or in an image control statement to be coindexed? For example, was it intended that this statement SYNC IMAGES(1, stat = is[2]) be allowed? It seems undesirable to involve image 2 when synchronizing the executing image with image 1. ANSWER: No, it was not intended to allow the or in an image control statement to be coindexed. An edit is provided to correct this oversight. EDIT: [190:5+] Add constraint "C851a (R859) A or in a shall not be a coindexed object. SUBMITTED BY: John Reid HISTORY: 15-144 m206 F08/0134 submitted - passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0135 TITLE: Vector subscripted actual makes VALUE dummy undefinable? KEYWORDS: VALUE, definable, vector subscript DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 12.5.2.4p18 [295:3-4] says "If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes." This would seem to be a strange requirement when the dummy argument has the VALUE attribute (and so is not argument-associated with the actual argument anyway). Consider program P1 real :: X(3) call S1 ( X ( [ 1, 3, 2 ] ) ) contains subroutine S1 ( A ) real, value :: A(:) A = 3 print *, A end subroutine end program and PROGRAM p2 REAL :: x(3) = [ 10,20,30 ] OPEN(10,ASYNCHRONOUS='YES',FORM='UNFORMATTED') CALL s2( x( [ 1,2,2,1 ] ) ) CONTAINS SUBROUTINE s2(a2) REAL,VALUE,ASYNCHRONOUS :: a2(:) READ(10,ASYNCHRONOUS='YES') a2 PRINT *,'reading...' WAIT(10) PRINT *,a2 END SUBROUTINE END PROGRAM Are these two programs standard-conforming? In particular, is the assignment to A permitted in S1, and is the dummy argument a2 permitted to have the ASYNCHRONOUS attribute in s2. ANSWER: These two programs were intended to be standard-conforming. Subclause 12.5.2.3 states that a VALUE dummy argument is associated with a definable data object and not with the actual argument. An edit is supplied to correct this mistake. EDITS: [295:3] 12.5.2.4 Ordinary dummy variables, p18 After "vector subscript" insert "and the dummy argument does not have the VALUE attribute". SUBMITTED BY: Van Snyder HISTORY: 15-148 m206 F08/0135 submitted - passed by J3 meeting 15-xxx m207 Passed as amended by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0136 TITLE: Argument correspondence with VALUE and ASYNCHRONOUS KEYWORDS: VALUE, ASYNCHRONOUS, coindexed, contiguous DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following three programs and discussions: program P1 real, asynchronous :: X[*] call S1 ( X [ 1 ] ) contains subroutine S1 ( A ) real, value, asynchronous :: A a = 3 end subroutine S1 end program P1 Program P1 appears to violate C1238 which says "An actual argument that is a coindexed object with the ASYNCHRONOUS or VOLATILE attribute shall not correspond to a dummy argument that has either the ASYNCHRONOUS or VOLATILE attribute." but the dummy argument is not associated with the actual argument so it is unclear why that should be the case. program P2 real, asynchronous :: X(3) call S2A ( X ) contains subroutine S2A ( A ) real, asynchronous :: A(:) call S2B ( A(1:3) ) end subroutine S2A subroutine S2B ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S2B end program P2 This appears to violate C1239 which says "If an actual argument is a nonpointer array that has the ASYNCHRONOUS or VOLATILE attribute but is not simply contiguous (6.5.4), and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS attribute." but again, it is unclear why that should matter for a VALUE dummy argument. program P3 real, target :: X(3) real, pointer, asynchronous :: Y(:) y => x call S3 ( y ) contains subroutine S3 ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S3 end program P3 This program appears to violate C1240 which says "If an actual argument is an array pointer that has the ASYNCHRONOUS or VOLATILE attribute but does not have the CONTIGUOUS attribute, and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an array pointer or an assumed-shape array that does not have the CONTIGUOUS attribute." but it is unclear why this should matter for a VALUE dummy argument. Are those programs intended to be standard-conforming? ANSWER: Yes, all those programs were intended to be standard-conforming. There is no need for those constraints to apply to dummy arguments with the VALUE attribute, because a VALUE dummy argument is not associated with the actual argument but with an anonymous definable data object. Edits are supplied to correct the mistakes in the constraints. EDITS: [295:6] 12.5.2.4 Ordinary dummy arguments, C1238, Between "VOLATILE attribute" and "." insert ", unless the dummy argument has the VALUE attribute". [295:9] Same subclause, C1239, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute,". [295:13] Same subclause, C1240, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute,". SUBMITTED BY: Van Snyder HISTORY: 15-149 m206 F08/0136 submitted 15-149r4 m206 Fix answer and typos - passed by J3 meeting 15-xxx m207 Passed by J3 letter ballot 15-159 ---------------------------------------------------------------------- NUMBER: F08/0137 TITLE: Result of TRANSFER when MOLD is an array with element size zero KEYWORDS: TRANSFER, zero-sized scalar DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following examples: Example 1: CHARACTER(0),PARAMETER :: nothing1(100) = '' PRINT *,SIZE(TRANSFER(111014,nothing1)) Example 2: TYPE empty END TYPE ! When the physical representation of empty() has size zero; ! this is not required but does seem to be permitted. TYPE(empty),PARAMETER :: nothing2(1) = empty() PRINT *,SIZE(TRANSFER(111014,nothing2)) Example 3: TYPE nonempty REAL c(0) END TYPE TYPE(nonempty),PARAMETER :: nothing3(0) = nonempty(0.0) PRINT *,SIZE(TRANSFER(111014,nothing3)) According to Fortran 2008, 13.7.168, the result of TRANSFER in this case is an array of rank one whose "size is as small as possible such that its physical representation is not shorter than that of SOURCE". However, the size of a zero-length character is zero and the size of the above derived types may be zero, no matter how many array elements there are, so these examples do not seem to be well-defined. Also consider the following examples, with nothing1 defined as in example 1. Example 4: CHARACTER(0) :: source1 = '' PRINT *,SIZE(TRANSFER(source1,nothing1)) Example 5: CHARACTER(999) :: source2(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source2,nothing1)) In these cases the physical representation of an element of MOLD has size zero, but then so does the physical representation of the SOURCE argument. According to the quoted text, that would mean that TRANSFER should return a zero-sized array, i.e. the examples will print zero. Example 6: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source3(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source3,maybe_nothing)) Example 7: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source4(10) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source4,maybe_nothing)) In these examples, the physical representation of MOLD is not known at compile time, but depends on the length of the dummy argument. Using the analysis above, example 6 would seem to be conforming (and print zero), while example 7 would seem to be conforming if and only if the length of maybe_nothing is nonzero at execution time. Which of the examples are conforming? If any of examples 1-3 are conforming, what value is printed? ANSWER: Example 1 is not conforming, and if the derived types have size zero in examples 2 and 3, those examples are also not conforming, as no interpretation is established for them. An edit is provided to clarify that they are not valid. Examples 4-6 are conforming, and the value zero is printed. Example 7 is conforming if and only if the length of maybe_nothing is not zero. The same edit clarifies that the zero-length case is not valid. EDITS: [393:18] 13.7.168 TRANSFER, p3 Arguments, MOLD, append "If the storage size of SOURCE is greater than zero and MOLD is an array, a scalar with the type and type parameters of MOLD shall not have a storage size equal to zero.". {It is ok for MOLD itself to have storage size zero, in the case where MOLD is a zero-sized array but the storage size of a scalar with its type and type parameters would be greater than zero.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-152 m206 F08/0137 submitted - passed by J3 meeting 15-xxx m207 Passed as amended by J3 letter ballot 15-159 ----------------------------------------------------------------------