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