ISO/IEC JTC1/SC22/WG5 N2062 Fortran Interpretations waiting for WG5 ballot, July 20, 2015 Stan Whitlock for /interp [keep this text document to 75 characters per line] ....................4 ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done {if S = C* | T*, then done is assumed} * == active Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot X Excluded for the reasons given C1 In F2008 Corrigendum 1 C2 In F2008 Corrigendum 2 C3 In F2008 Corrigendum 3 N S T number title - - - ------ ----- * B I F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? * B E F08/0110 Interdependence of specifier values in input/output statements * B E F08/0115 ASYNCHRONOUS and argument passing * B E F08/0116 Interoperable procedures * B E F08/0117 TARGET and coindexed arguments * B E F08/0118 Subobject of variable in variable definition context * B E F08/0119 Branching to END BLOCK and END CRITICAL * B E F08/0120 Is the name of a procedure pointer a local identifier? * B E F08/0121 Add to introduction defined operations in specification exprs * B E F08/0122 Types with coarray components * B E F08/0123 SPACING intrinsic * B E F08/0124 Coindexed object with polymorphic subcomponent * B E F08/0126 Can cobounds be referenced in the same type declaration? * B E F08/0127 May an initial line begin with a semicolon? * B E F08/0129 Is CLASS(type) required to refer to a prior type definition? * B E F08/0130 Does coarray allocation sync even with stopped images? * B E F08/0131 Are the changes to C_LOC in the 2010 revision intentional? * B E F08/0132 Can a procedure pointer be declared with an interface block? * B E F08/0133 Is unallocated actual associated with nonallocatable dummy OK? * B E F08/0134 in an image control statement * B E F08/0135 Vector subscripted actual makes VALUE dummy undefinable? * B E F08/0136 Argument correspondence with VALUE and ASYNCHRONOUS * B E F08/0137 Result of TRANSFER when MOLD is an array with element size zero ====================================================================== Part 1: Interpretation Processing Rules ====================================================================== 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. Interps so forwarded are marked "Corrigendum". 6. J3/interp creates a edit for the next Fortran Standard if one is needed for all interps marked "Corrigendum". ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute is not argument associated with the corresponding actual argument. Rather, it is associated with an anonymous data object whose value is copied from the actual argument before execution of the executable constructs of the subprogram commences, and before expressions in the specification part are evaluated. Therefore, it can successfully take part in asynchronous operations that both start and complete within that procedure call, independently of whether the corresponding actual argument has or has not the ASYNCHRONOUS attribute. There is no problem if a dummy argument has the VALUE attribute and the corresponding actual argument has the ASYNCHRONOUS attribute, independently of whether the dummy argument has the ASYNCHRONOUS attribute. Subclause 9.6.4.1, paragraph 6 [220:13-15], prohibits an actual argument that is part of a pending input/output storage sequence affector from being associated with a dummy argument that has the VALUE attribute. EDIT to 10-007r1: None. SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting 14-192 m204 Failed J3 letter ballot #30 14-146 14-269 m205 Revised answer - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: 1. Are the following INQUIRE statements permitted? LOGICAL :: Exist, Opened INQUIRE ( FILE='fred', EXIST=exist ) INQUIRE ( UNIT=42, OPENED=opened ) 2. Is the following INQUIRE statement permitted? INTEGER :: U INTERFACE FUNCTION P ( A ) INTEGER, INTENT(IN) :: A INTEGER, POINTER :: P END FUNCTION P END INTERFACE INQUIRE ( FILE='fred', NUMBER=u, POS=p(u) ) 3. Is the following READ statement permitted? INTEGER :: STATS(42) NAMELIST /IN/ V READ ( *, IN, IOSTAT=STATS(V) ) ANSWERS: 1. According to 9.12p5 [243:3-5] "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statements are prohibited because the values of the variables EXIST and OPEN depend upon the values of the FILE= and UNIT= specifiers, respectively. They were intended to be permitted. Edits are provided to correct this mistake. 2. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any ,

, or on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statement is not prohibited because U is not a subscript or substring bound. According to 7.1.4p2 [139:3-4] "The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." the INQUIRE statement is not prohibited because, although U is assigned a value, it is not evaluated. The INQUIRE statement was intended to be prohibited. Edits are provided to correct this mistake. 3. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any ,

, or on the definition or evaluation of any other specifier in the or in that statement." and 9.12p7 [243:9-11] "In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if any, shall not be associated with any entity in the ... ...." and 9.12p8 [243:12-14] "In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an array element reference, its subscript values shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the ." the READ statement is not prohibited because V does not "depend on any ,

, or on the definition or evaluation of any other specifier in the or in that statement." Although V is input from namelist, it is not "the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier." The READ statement was intended to be prohibited. Edits are provided to correct this mistake. EDITS to 10-007r1: [243:3-5 9.12p5] Within the second sentence, provided by Corrigendum 2, replace "values of any or" with "value of any". Append ", or be affected by data transfer caused by that statement". That sentence becomes "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT=, or SIZE= specifier shall not depend on the value of any

in the same statement, or be affected by data transfer caused by that statement." {Using "data transfer" instead of "" covers the namelist case.} [243:6-7 9.12p6] Replace "value of any subscript or substring bound" with "denotation". Replace "depend ... " with "be affected by the data transfer, the processing". The paragraph becomes "The denotation of a variable that appears in a specifier in an input/output statement shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the or in that statement." After the paragraph, insert a note: NOTE 9.nn The semantics of how a variable is denoted is its "denotation"; this includes such things as component and array element selection. Anything that affects this process is prohibited in this context; that includes the values of any subscripts used, and if the variable is specified by a pointer function reference, anything that affects the evaluation of that function. {Using "data transfer" instead of "" covers the namelist case.} [243:9 9.12p7] "Insert "ID=," before "IOSTAT". {Not mentioned in a question, but was a problem.} [243:12-14 9.12p8] Repairing the paragraph would make it equivalent (if not identical) to 9.12p6, as revised above. Therefore, delete the paragraph. SUBMITTED BY: Van Snyder HISTORY: 14-193 m204 F08/0110 submitted 14-193r1 m204 Revised 14-272r1 m205 Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0115 TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider PROGRAM Main INTEGER, ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') CALL async_read(array) CALL fred(array(::2)) ! Problematic? WAIT (11) PRINT *, array CONTAINS SUBROUTINE async_read(array) INTEGER, ASYNCHRONOUS, INTENT(INOUT) :: array(:) READ (11, *, ASYNCHRONOUS='yes') array END SUBROUTINE END PROGRAM SUBROUTINE Fred (arg) ! In general, an external procedure INTEGER :: arg(*) ! Otherwise unused CONTINUE ! In general, something that takes more time END SUBROUTINE Is the call to "Fred" standard-conforming? It is not excluded by 5.3.4p2, because 'array' is merely associated with 'arg' in subroutine Fred, and not used in any executable statement or specification expression there. However, if copy-in/out is used for argument passing and the actual i/o transfer occurs in between the copy-in and copy-out, the wrong answers will be given. ANSWER: This program was not intended to be conforming. An edit is provided to correct this oversight. EDITS: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or". SUBMITTED BY: Nick Maclaren HISTORY: 14-218 m205 F08/0115 submitted 14-218r1 m205 Revised 14-218r2 m205 Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: In all cases, Alf is a Fortran procedure like this: SUBROUTINE Alf (Arg) BIND(C,NAME='Alf') INTERFACE SUBROUTINE Arg () BIND(C) END SUBROUTINE Arg END INTERFACE CALL Arg END SUBROUTINE Alf Q1. Consider extern void Bert (void) { ; } int main (void) { Alf(Bert); } 15.5.1p2 requires a procedure defined by means other than Fortran to have the same binding label as the interface. Function Bert() has a binding label of 'Bert', but 15.5.2p2 states that the dummy argument Arg has no binding label, therefore 15.5.1p2 is not satisfied. Was this intended to be conforming? Q2. Consider static void Fred (void) { ; } int main (void) { Alf(Fred); } 15.5.1p2 requires a procedure defined by means other than Fortran to have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999. Function Fred() has no such name, as its definition has internal linkage. However, linkage in C affects only the visibility of the external name, and has no application to either types or values, whether in the form of function parameters or other pointers. Was this intended to be conforming? Q3. Consider extern inline void arg (void) { ; } int main (void) { Alf(Joe); } C99 6.7.4 describes the inline specifier. This does not prevent it from having external linkage, but "An inline definition does not provide an external definition for the function" i.e. despite having external linkage, there might be no external definition that could be invoked from Fortran. Was it not an oversight not to exclude inline in 15.5.1? ANSWERS: A1. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A2. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A3. A C function with no external definition is not "defined by means other than Fortran" so much as "not defined". This was not intended to be conforming. An edit is provided to clarify this situation. EDITS: [436:15] 15.5.1 Definition and reference of interoperable procedures, p1, Append sentence "A C function that has an inline definition and no external definition is not considered to be defined in this sense.". In 15.5.1p2, apply these edits [436:16] After "means other than Fortran," delete "it shall", [436:17] Before "be describable" insert "it shall", after "the interface," insert "and", [436:18-19] Before "have a name" insert "if it is accessed using its binding label, it shall" and begin a bullet sub-list, and make the "have the same" bullet the second sublist item. This makes that whole paragraph read "If the procedure is defined by means other than Fortran, -- it shall be describable by a C prototype that is interoperable with the interface, and -- if it is accessed using its binding label, it shall - have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999, and - have the same binding label as the interface." {Note this wording uses "accessed" rather than "invoked" since it can be the argument of C_FUNPTR or the target in a procedure pointer assignment.} SUBMITTED BY: Nick Maclaren HISTORY: 14-221 m205 F08/0116 submitted 14-221r1 m205 Revised 14-221r2 m205 Further Revised - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following program conforming and required to print 10, 10, 10 and 123, 123, 123? PROGRAM Main INTEGER, TARGET :: coarray(3)[*] coarray = 10*THIS_IMAGE() SYNC ALL IF (THIS_IMAGE() == 1) THEN SYNC ALL coarray = 123 SYNC ALL ELSE IF (THIS_IMAGE() == 2) THEN CALL Fred(coarray(:)[1]) ELSE SYNC ALL SYNC ALL END IF CONTAINS SUBROUTINE Fred (arg) INTEGER, TARGET :: arg(:) PRINT *, arg SYNC ALL SYNC ALL PRINT *, arg END SUBROUTINE Fred END PROGRAM Main DISCUSSION: This program is modifying an actual argument while it is associated with a dummy argument. That is normally prohibited by the anti-aliasing rules in 12.5.2.13, but these do not operate in the TARGET dummy argument case. However, coindexed actual arguments are accessing remote memory, so in general will be passed by copy-in/out; in this case permitting aliasing is not reasonable. ANSWER: The program is not intended to be conforming. Edits are provided to correct this oversight. EDITS: [300] 12.5.2.13p1(3)(b) append to the end of the paragraph "or a coindexed object". [300] 12.5.2.13p1(4)(b) append to the end of the paragraph "or a coindexed object". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-223 F08/0117 submitted m205 14-223r1 Revised example and discussion - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does this program conform to the Fortran 2008 standard? type :: T integer :: C end type T type(t), parameter :: V = T(41) associate ( W => V ) 1 w%c = 42 end associate end DISCUSSION: Because the selector is not permitted to appear in a variable definition context, the associate-name is not permitted to appear in a variable definition context. However, that does not affect subobjects of the associate-name. ANSWER: The associate-name is not permitted to appear in a variable definition context because no interpretation is established; however, it should be explicitly stated that this is not permitted. An edit is provided to clarify this. EDITS: [170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801, Between "" and "shall not appear" insert "or any subobject of ". [171:12] 8.1.3.3 Attributes of associate names, p2, Between "the associate name" and "shall not appear" insert "or any subobject of the associate name". [184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836, Between "" and "shall not" insert "of any subobject of ". SUBMITTED BY: Van Snyder HISTORY: 14-240r1 m205 F08/0118 submitted 14-240r2 m205 Revised question and answer - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Do the GO TO statements in the following conform to the Fortran 2008 standard? go to 1 block 1 end block go to 2 critical 2 end critical ANSWER: Branching to an END BLOCK or END CRITICAL statement from outside the construct was intended to be prohibited. Edits are provided to correct this omission. EDITS: [172:13+] 8.1.4 BLOCK construct, after p3 (before NOTE 8.5), Insert new paragraph "It is permissible to branch to an only from within its BLOCK construct.". [173:21+] 8.1.5 CRITICAL construct, after p3 (before NOTE 8.6), Insert new paragraph "It is permissible to branch to an only from within its CRITICAL construct.". FUTURE REVISION: A future revision could make all of these constraints, and combine them into a single requirement as follows. [170:36 8.1.3.2p3] Delete the paragraph. [175:35-36 8.1.6.4p1] Delete "It is permitted ... DO construct." [175:40 8.1.6.4p2] Delete "Transfer of control ... ." [180:25 8.1.7.2p2] Delete "It is permissible ... IF construct." [182:26 8.1.8.2p3] Delete the paragraph. [185:26 8.1.9.2p9] Delete the paragraph. [187:7+ 8.2.1p1+] Insert constraint: "C847a If a branch target statement is an , , , , , , or , the branching statement that references the label of that branch target statement shall be within the construct completed by that branch target statement." SUBMITTED BY: Van Snyder HISTORY: 14-242 m205 F08/0119 submitted 14-242r1 m205 Revised question and answer 14-242r2 m205 Fixed typo in example - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the name of a procedure pointer a local identifier? The list of classes of local identifiers given in paragraph 1 of subclause 16.3.1 of J3/10-007r1 (page 440) does not include procedure pointers. ANSWER: Yes, if a procedure pointer is named, the name of the procedure pointer is a local identifier. An edit is provided to amend the oversight. EDITS: [440:4, 16.3.1p1] Replace "named constants, named" with "named constants, named procedure pointers, named". SUBMITTED BY: Robert Corbett HISTORY: 14-256 m205 F08/0120 submitted - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Fortran 2003 7.1.6 (Specification expressions), says on 141:12: A restricted expression is an expression in which each operation is intrinsic Fortran 2008 7.1.11 says on 150:8: A restricted expression is an expression in which each operation is intrinsic or defined by a specification function This new feature is not called out in the Introduction but should be. ANSWER: This was an oversight. An edit to correct the problem is supplied. EDIT to 10-007r1: Introduction, page xv. Add to the "Data declaration" list in paragraph 2: "A can be used in a specification expression." SUBMITTED BY: Steve Lionel HISTORY: 14-259 m205 F08/0121 submitted 14-259r1 m205 In edit, replace "defined operator" with "" - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: Q1. Consider Module m Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] Contains Subroutine dubious Volatile x Volatile xco ... End Subroutine End Module Program bad Use m Volatile x Volatile xco ... End Program 5.3.19 C560 says "The VOLATILE attribute shall not be specified for a coarray that is accessed by use (11.2.2) or host (16.5.1.4) association." That means that the two "VOLATILE XCO" statements are not conforming. However, the "VOLATILE X" statements have essentially the same effect, but are unaffected by the constraint, which seems inconsistent. Was this constraint also intended to apply to objects with coarray components? Q2. Consider Program blockvolatile Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] ... Block Volatile x Volatile xco End Block 5.3.19 C561 says "Within a BLOCK construct (8.1.4), the VOLATILE attribute shall not be specified for a coarray that is not a construct entity (16.4) of that construct." That means that VOLATILE XCO is not standard-conforming. However, the constraint apparently does not apply to X, so VOLATILE X is standard- conforming, even though it has essentially the same effect as the forbidden case. Was this constraint intended also to apply to objects with coarray components? Q3. 5.3.19p1 says "A noncoarray object that has the VOLATILE attribute may be associated with an object that does not have the VOLATILE attribute..."; does this apply to objects with a coarray component? Q4. 12.4.2.2p1 says "A procedure other than a statement function shall have an explicit interface if it is referenced and ... (2) the procedure has a dummy argument that ... (c) is a coarray, ...." Is this intended also to apply to objects with coarray components? Q5. Consider: Program volatility Type t Real,Allocatable :: co[:] End Type Type(t) :: x Type(t),Volatile :: y ... Call s1(x) Call s2(x) ! Dummy is volatile, X is not. Call s1(y) ! Y is volatile, dummy is not. Call s2(y) Contains Subroutine s1(a) Type(t) :: a ... End Subroutine Subroutine s2(b) Type(t),Volatile :: b ... End Subroutine End Program 12.5.2.8p1 says "If the dummy argument is a coarray, the corresponding actual argument shall be a coarray and shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." That means that if the program were passing the component CO directly (and the TYPE(T) declarations in S1 and S2 were changed to REAL), the second and third calls would not be conforming because of the VOLATILE mismatch. It seems inconsistent that there is no requirement for VOLATILE to match when there are coarray components, since it has the same effect that X%CO is VOLATILE in S2 but not in the caller, and Y%CO is VOLATILE in the caller but not in S1. Was this requirement also intended to apply to objects with coarray components? Q6. 12.8.1 C1289 says "All dummy arguments of an elemental procedure shall be scalar noncoarray dummy data objects and shall not have the POINTER or ALLOCATABLE attribute." Is this intended also to apply to objects with coarray components? ANSWER: A1. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A2. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A3. No, this does not apply to objects with coarray components, as there is no way of giving the noncoarray parts of the object the VOLATILE attribute without giving the coarray part the VOLATILE attribute, which is forbidden. That the quoted text gives permission for a noncoarray to have the VOLATILE attribute does not override any other requirements in the standard. A4. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. A5. Yes, this requirement was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A6. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. EDITS: [102:9] 5.3.19 VOLATILE attribute, C560, Between "for a coarray" and "that is accessed by use or" insert ",or a variable with a coarray ultimate component,". {A1.} [102:11] 5.3.19 VOLATILE attribute, C561, Between "for a coarray" and "that is not a construct entity" insert ",or a variable with a coarray ultimate component,". {A2.} [295:4+] 12.5.2.4 Ordinary dummy variables, p18+, "If the dummy argument has a coarray ultimate component, the corresponding actual argument shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." {A5.} SUBMITTED BY: Nick Maclaren HISTORY: 14-228 m205 F08/0122 submitted 14-228r1 m205 Revised questions with answers - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program Program test_spacing Real :: x, y, tiny_spacing, z x = Tiny(x) y = Nearest(x,1.0) tiny_spacing = y - x If (tiny_spacing>0) Then ! Probably IEEE arithmetic with subnormals: ! the spacing y - x is representable. Else ! Probably no subnormals, so y - z is not representable. tiny_spacing = Tiny(x) End If z = Spacing(x) If (z/=tiny_spacing) Then Print *,'FAIL' Else Print *,'ok' End If End Program Furthermore let us assume that the processor supports IEEE arithmetic with subnormals, and that default REAL is IEEE single precision. According to Fortran 95, the result for SPACING is: "If X is not zero, the result has the value b**(e-p), where b, e, and p are as defined in 13.7.1 for the model representation of X, provided this result is within range." therefore the program is expected to print the value "ok". However, according to Fortran 2008, the result for SPACING is: "If X does not have the value zero ..., the result has the value b**max(e-p,emin-1), where ..." Unsurprisingly, e-p is not equal to max(e-p,emin-1) for smallish numbers, and therefore the program would be expected to print the value "FAIL". However, there is no such incompatibility with Fortran 90/95 listed in clause 1, therefore the standard contradicts itself. (The value specified in Fortran 2008 also contradicts the Description of the function which says "Spacing of model numbers (13.4)", since it does not even attempt to return that value.) Is the new specification a deliberate incompatibility or a mistake? DISCUSSION: The description of SPACING was changed in Fortran 2003 by paper 01-361r2 "Comments on Section 13", which contains no justification for this technical change and indeed does not even mention it is a technical change - there is just the bare edit (buried in a huge list of bare edits) with no indication as to why. This would seem to indicate that the technical change is an inadvertent error (presumably the paper simply forgot about subnormal numbers and assumed the new formula gave the same result as the old one). ANSWER: The new wording of SPACING inadvertently changed the return values when IEEE subnormal values were available. An edit is provided to correct this mistake. EDITS to 10-007r1: [389:4-5] 13.7.157 SPACING (X), p5 Result Value, Change "max(e-p,emin-1)" to "e-p", After "that of X" insert ", provided this result is representable; otherwise the result is the same as that of TINY (X).", Change "; if there are two such values" to "If there are two extended model values equally near to X,". This makes the whole paragraph read: If X does not have the value zero and is not an IEEE infinity or NaN, the result has the value b**(e-p), where b, e, and p are as defined in 13.4 for the value nearest to X in the model for real values whose kind type parameter is that of X, provided this result is representable; otherwise the result is the same as that of TINY (X). If there are two extended model values equally near to X, the value of greater absolute value is taken. If X has the value zero, the result is the same as that of TINY (X). If X is an IEEE infinity, the result is an IEEE NaN. If X is an IEEE NaN, the result is that NaN." where "b**(e-p)" represents the typesetting of $b^{e-p}$. SUBMITTED BY: Malcolm Cohen HISTORY: 14-263 m205 F08/0123 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following type definitions and object declarations: Type t1 Class(*),Allocatable :: bad End Type Type t2 Type(t1),Allocatable :: oops End Type Type(t1) x[*] Type(t2) y[*] Do the following subroutine calls conform to the Fortran 2008 standard? Call s1(x[2]) Call s2(y[2]) DISCUSSION: If Y[2]%OOPS and Y[2]%OOPS%BAD are both allocated they are subobjects, but only OOPS is a subcomponent of Y[2]. Since OOPS is not polymorphic and BAD is not a subcomponent, this clearly does not violate C617. That seems inconsistent since in both cases a copy of the coindexed variable would necessarily copy the polymorphic BAD component. ANSWER: The intent of C617 was to prevent copying a polymorphic subobject of a coindexed object. Since a subobject is not always a subcomponent, an edit is provided to correct the mistake of using the term "subcomponent" in C617. EDITS: [6:7+] After 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component" {We need a new term to describe this properly.} [119:13 C617] Replace "subcomponent" with "potential subobject component". SUBMITTED BY: Van Snyder HISTORY: 14-262 m205 F08/0124 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- 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-187 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-187 m207 Passed as amended by J3 letter ballot 15-159 ---------------------------------------------------------------------- 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-187 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-187 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-187 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-187 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-187 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-187 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-187 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-187 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-187 m207 Passed as amended by J3 letter ballot 15-159 ----------------------------------------------------------------------