From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Feb 9 10:10:44 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id F0EA9356972; Thu, 9 Feb 2012 10:10:43 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id 1EE5D356922 for ; Thu, 9 Feb 2012 10:10:36 +0100 (CET) X-Trace: 727808857/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/2.97.127.131/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.97.127.131 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7 X-IP-BHB: Once X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="txt'?scan'208";a="727808857" Received: from host-2-97-127-131.as13285.net (HELO [127.0.0.1]) ([2.97.127.131]) by smtp.tiscali.co.uk with ESMTP; 09 Feb 2012 09:10:33 +0000 Message-ID: <4F338D8F.9070102@stfc.ac.uk> Date: Thu, 09 Feb 2012 09:10:39 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7 MIME-Version: 1.0 To: Marisa Peacock CC: WG5 Subject: Re: Corrigendum 1 for Fortran 2008 References: <7971ff$j29pi@smtprelay1.iso.ch> <4F29142C.60708@stfc.ac.uk> <11169BEA3B01DA4887C61AF9BDA44E030A5A1174@ny-exchange.ANSI.org> <4F2A568C.7060602@stfc.ac.uk> <11169BEA3B01DA4887C61AF9BDA44E030A68B115@ny-exchange.ANSI.org> <4F31773C.2050508@stfc.ac.uk> <11169BEA3B01DA4887C61AF9BDA44E030A68B19F@ny-exchange.ANSI.org> In-Reply-To: <11169BEA3B01DA4887C61AF9BDA44E030A68B19F@ny-exchange.ANSI.org> Content-Type: multipart/mixed; boundary="------------080103010407040609000604" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------080103010407040609000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Marisa, Here is the defect report to go with Corrigendum 1. Best wishes, John. --------------080103010407040609000604 Content-Type: text/plain; name="N1907.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1907.txt" ISO/IEC JTC1/SC22/WG5 N1907 Defect reports that led to Corrigendum 1 and responses to them John Reid Defect Type T: E Erratum I Interpretation X Excluded for the reasons given T number title - - - ------ ----- E F03/0048 Control edit descriptors in UDDTIO E F03/0085 Finalizing targets of pointer or allocatable I F03/0091 Array components cannot depend on length type parameters I F03/0105 SIZE= specifier and UDDTIO I F03/0110 Restoring dropped restriction on ENTRY E F03/0123 Implicit typing in derived types E F03/0124 definition is poorly defined I F03/0128 Subobjects in namelist output E F08/0001 Generic resolution with pointer dummy arguments E F08/0002 Are assumed- or deferred-shape objects allowed in namelist? E F08/0003 Is a disassociated pointer allowed as an actual DIM argument? X F08/0005 optional arguments and ASSOCIATED - subsumed by F08/0004 I F08/0006 generic resolution with banned argument combinations I F08/0007 Can zero have more than one bit sequence representation? I F08/0009 Is ABS ever required to be the optional IEC 60559 abs? E F08/0010 deallocating objects that are associated with other objects E F08/0011 How many times are constructed values finalized? X F08/0012 Are constants finalized? - subsumed by F08/0011 E F08/0013 How does finalization interact with allocatable assignment? E F08/0014 Finalizing assignment to vector-subscripted object E F08/0015 IMPLICIT E F08/0016 Can a vector-subscripted argument become undefined? E F08/0017 Elemental subroutine restrictions E F08/0018 Impure elemental restrictions E F08/0019 Transformational Bessel functions E F08/0020 FINDLOC and logical arguments E F08/0021 STORAGE_SIZE and unlimited polymorphic E F08/0022 DO CONCURRENT and file i/o E F08/0023 DO CONCURRENT and POINTER E F08/0024 Dummy arguments of impure elemental procedures E F08/0025 DO CONCURRENT and ALLOCATABLE E F08/0026 DO CONCURRENT and output interleaving E F08/0027 ATOMIC_REF example E F08/0028 Does a procedure reference cause loop termination? E F08/0030 Unlimited format repeat effects E F08/0033 PURE polymorphic finalization E F08/0034 ELEMENTAL INTENT(OUT) finalization I F08/0035 Maximum value for SHIFT argument to SHIFTL and SHIFTR E F08/0036 NORM2 example in Annex C E F08/0037 PROCEDURE POINTER vs PROTECTED E F08/0039 Many-one vector subscript usage I F08/0044 Resolving the type of a coarray or coindexed object E F08/0046 VALUE attribute restrictions I F08/0047 public generic with same name as private type E F08/0049 ELEMENTAL functions with nonconstant type parameters E F08/0050 Ordering requirements on definition of specification functions E F08/0051 Pure procedure arguments with VALUE E F08/0052 Private type-bound procedures E F08/0053 Restrictions on generic declarations, generic resolution ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i = 0 CONTAINS PROCEDURE, PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE CONTAINS RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, '(i1, /)') dtv%i WRITE(unit, '(t1, a2)') 'AB' END SUBROUTINE pwf END MODULE PROGRAM foo USE m IMPLICIT NONE TYPE(t) :: a a%i = 3 PRINT *, 'xyz', a end program 9.6.4.8.3 p26 [227:17] states A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. The term "record position" is used, but it doesn't appear to be defined anywhere. Depending on the interpretation, the above program might be standard-conforming, or it might not be. If "record position" is taken to mean "the position within the current record", regardless of which record is the current record, then the record position at the beginning of the UDDTIO procedure is before the fourth character of the record. The first child data transfer statement begins a new record, and the second child data transfer statement writes to the first character of the new record. This would be before the "record position" at the time the UDDTIO procedure was invoked, and the program would not be standard-conforming. If "record position" is taken to mean a combination of the record and the position within that record (essentially making it mean the same thing as "file position"), then the above program is standard- conforming, since the control edit descriptor doesn't cause the file to be positioned before the record position when the UDDTIO procedure was invoked. What is the meaning of "record position", and is the above program standard-conforming? ANSWER: The term "record position" is not well defined. The intent of 9.6.4.8.3 was to prohibit a child data transfer statement from possibility overwriting or re-reading any characters in the current record that an active parent I/O statement had previously written or read. 9.6.4.8.3 should have used the term "file position" instead of "record position". Therefore, the program is standard-conforming, and prints xyz.3 AB where the first record starts with a space and the "." represents a value separator. Edits are supplied to clarify the intent of 9.6.4.8.3 and remove the phrases "record position" and "record positioning" from the standard. EDITS to 10-007r1: [227:15] In section 9.6.4.8.3 p25, in the paragraph that begins with "Because a child data transfer statement does not position the file prior to data transfer," replace "effective item or record positioning edit descriptor" with "effective item or edit descriptor" [227:17] In section 9.6.4.8.3 p26, replace the phrase "A record positioning edit descriptor, such as TL and TR," with "The edit descriptors T and TL" [227:18] Change "record position" to "file position" twice. [487:28] In section C.6.2p1, in the third sentence, delete "record positioning" SUBMITTED BY: Rob James HISTORY: 05-139 m171 F03/0048 submitted 05-139r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-167 06-366r2 m178 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 10-241 m193 Draft answer for F2008 10-241r1 m193 Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed as amended by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0085 TITLE: Finalizing targets of pointer or allocatable actual arguments KEYWORDS: Finalization, pointer actual argument, allocatable actual argument DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program program Finalize type :: T ... contains final :: ... end type T type(t), pointer :: TV allocate ( TV ) call sub ( TV ) contains sub ( A ) type(t), intent(out) :: A end sub A end program Finalize The eighth paragraph of 10-007, section 4.5.6.3 [76:30-31], says "When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument corresponding to an INTENT(OUT) dummy argument is finalized.'' Q1. Is the target of TV finalized when SUB is invoked? Q2. If TV were allocatable instead of a pointer, would it be finalized? ANSWER: A1. Yes A2. Yes It was intended that an allocatable actual argument or the target of a pointer actual argument that is associated with an INTENT(OUT) dummy argument be finalized when the procedure is invoked. Edits are provided to correct the error. EDITS to 10-007r1: Replace the eighth paragraph of 4.5.6.3 [76:23-24] with: "When a procedure is invoked, an object that becomes argument associated with a nonpointer, nonallocatable INTENT(OUT) dummy argument of that procedure is finalized." SUBMITTED BY: Van Snyder HISTORY: 06-374 m178 F03/0085 submitted 10-242 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: Consider MODULE m TYPE t(n) INTEGER,LEN :: n REAL v(n) END TYPE END Is the example intended to be standard-conforming? ANSWER: Yes, the example is standard-conforming in F2008. C531 in section 5.3.8.2 [94:15-16] of 10-007 says: "C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, BLOCK construct, or interface body." EDITS to 10-007r1: None SUBMITTED BY: Van Snyder HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen) 10-243 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot DISCUSSION: 9.6.2.15p1 [216:32-36] says that when SIZE= specifier is used in a formatted input statement with explicit format specifications, the variable specified in the SIZE= specifier is determined by the data edit descriptors during the input statement. These rules, however, did not take into account the following situation where a parent READ statement with a DT edit descriptor invokes a user-defined DTIO formatted read subroutine that reads input data using a list-directed or namelist READ statement. Consider the following example: module example type A integer x(10) contains procedure :: readArray generic :: read(formatted) => readArray end type contains subroutine readArray (dtv, unit, iotype, v_list, iostat, iomsg) class(A), intent(inout) :: dtv integer, intent(in) :: unit character(*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(*), intent(inout) :: iomsg read (unit, fmt=*, iostat=iostat, iomsg=iomsg) dtv%x end subroutine end module program test use example type(A) :: v integer countChar open (1, file='example.input', form='formatted') read (1, fmt='(DT)', advance='no', size=countChar) v end program test Note that there is no data edit descriptor in the UDDTIO subroutine, readArray, to count the total number of characters transferred during the child read. QUESTION: Is this example intended to be standard conforming? ANSWER: Yes, the example is standard-conforming. The definition of SIZE= in [10-007 216:31] section 9.6.2.15 does not restrict SIZE= if a child I/O is present. The description of how SIZE= works in [219:25] section 9.6.4.1p22 item (9) clearly indicates that SIZE= should be set even if child I/O occurs (items (5) and (6)). EDITS to 10-007r1: None SUBMITTED BY: Jim Xia HISTORY: 07-302 m182 F03/0105 submitted 07-302r1 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 10-247 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: It appears that a hard restriction found in ANSI X3.9-1978 was dropped when we published Fortran 90. The restriction on page 15-13 of the FORTRAN 77 standard says >In a function subprogram, a variable name that is the same >as an entry name must not appear in any statement that >precedes the appearance of the entry name in an ENTRY >statement, except in a type-statement. so FUNCTION S() T = 13.0 ENTRY T() END is not standard-conforming. The restriction appears to be missing from Fortran 90, 95, 2003. Should it still be in force ? ANSWER: No, for whatever reason, the restriction was dropped a long time ago and is not in F2008. The above program does not violate the standard with the placement of the assignment to T. [10-007 310:5-8] Section 12.6.2.6 specifies that the results S and T in the above example share the same memory so S() returns 13.0. As is, the example is not standard-conforming since no return value is set for T(). EDITS to 10-007r1: None SUBMITTED BY: Michael Ingrassia HISTORY: 07-341 m182 F03/0110 submitted 10-248 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program PROGRAM MAIN TYPE T INTEGER :: I = BIT_SIZE(J) END TYPE ! J = 0 CALL SUBR1 CONTAINS SUBROUTINE SUBR1 J = 1 CALL SUBR2 PRINT *, J END SUBROUTINE SUBROUTINE SUBR2 J = 2 END SUBROUTINE END Q1. Is this program standard-conforming? (In particular, is it permitted to have the first, or only, appearance of a local variable name appear within a type definition. The definition of implicit typing says that J is explicitly declared within T.) Q2. (a) If not, is it standard-conforming if the comment "! J = 0" is turned into the assignment statement "J = 0"? (b) If it is standard-conforming, what does it print? (If J is a local variable of MAIN, it should print 2.) ANSWER: A1. Yes, the program is standard-conforming. The definition of implicit typing is erroneous - J is a local entity of MAIN. An edit is supplied to correct this error. A2. (a) Not applicable. (b) The program will print the value 2. EDITS to 10-007r1: [109:22-23] In 5.5p4, After "The data entity is treated as if it were declared in an explicit type declaration" replace "in" with "; if", then after "the outermost inclusive scope in which it appears" insert "is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". Note: This makes the whole sentence read "The data entity is treated as if it were declared in an explicit type declaration; if the outermost inclusive scope in which it appears is not a type definition, it is declared in that scope, otherwise it is declared in the host of that scope". SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-268 m185 F03/0123 submitted 10-244 m193 Revised answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: Definition is poorly defined KEYWORDS: definition DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program: PROGRAM example1 TYPE T1 SEQUENCE INTEGER I, J END TYPE TYPE T2 SEQUENCE INTEGER I, J END TYPE TYPE(T1) X TYPE(T2) Y EQUIVALENCE (X, Y) X%I = 1 X%J = 2 PRINT *, X, Y END Q1. Is this program standard-conforming, and if so, what does it print? According to items (1) and (12) of 16.6.5, the assignment to X%I causes both X%I and Y%I to become defined. Similarly, the assignment to X%J causes both X%J and Y%J to become defined. Then, according to item (15) of 16.6.5, both X and Y become defined. However, according to 4.5.2.4, X and Y are types with different names, and therefore are of different type, thus according to 16.6.6 item (1) when X becomes defined Y becomes undefined, and vice versa. This appears to be a contradiction. Furthermore, consider PROGRAM example2 TYPE t INTEGER a,b END TYPE TYPE(t),TARGET :: x INTEGER,POINTER :: p x = t(1,2) p => x%a p = 33 PRINT *,x END PROGRAM According to the quoted text, the assignment to P is defining a variable of type INTEGER, and one that is associated (partially, via pointer association) with a variable of type T. That would seem to make X undefined according to item (1) of 16.6.6. Q2. Is example2 intended to be standard-conforming? Finally, consider MODULE ugly1 TYPE t1 INTEGER a,b END TYPE INTEGER w,z TYPE(t1) x COMMON/c/w,x,z END MODULE MODULE ugly2 TYPE t2 INTEGER c,d END TYPE TYPE(t2) y1,y2 COMMON/c/y1,y2 END MODULE BLOCK DATA COMON/c/i(4) DATA i/1,2,3,4/ END BLOCK DATA PROGRAM example3 USE ugly1 USE ugly2 ! At this point c is 1,2,3,4. y1 = t2(66,-6) PRINT *,w ! Is this ok? w = 0 PRINT *,y1 ! And is this ok? END PROGRAM This is similar to example1, except that we are defining a whole variable of sequence type at once, not by partial definition. Q3. Is example3 standard-conforming? ANSWER: A1. The program was intended to be standard-conforming. An edit is supplied to remove the apparent contradiction. The program should print something like " 1 2 1 2". A2. Yes, example2 is intended to be standard-conforming. An edit is supplied to remove the problem. A3. Yes, example3 is intended to be standard-conforming. An edit is supplied to remove the problem. DISCUSSION: The only interesting case of variable definition causing an associated variable to become undefined is using the old FORTRAN 77 data types; all the other intrinsic types are not permitted to be associated with variables of different type. We only need to get the scalar intrinsic case right, as the array and derived type cases then follow automatically from the definitions in 16.6.1. EDITS to 10-007r1: [455:4-10] Replace 16.6.6 item (1) entirely: "(1) When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined. When a double precision scalar variable becomes defined, all partially associated scalar variables become undefined. When a scalar variable becomes defined, all partially associated double precision scalar variables become undefined." SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted 10-245 m193 Draft answer - Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 11-150 m194 Revised answer - Passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1878 Passed by WG5 letter ballot N1902 Edit amended during corrigendum construction ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: Was it intended to disallow vendors to provide namelist output that includes a subobject designator followed by a value? ANSWER: Yes. The processor is required to produce output in the form specified by 10.11.4.3 "Namelist output records". 10.11.4.3 paragraph 2 states "The name of each namelist group object list item is placed in the output record followed by an equals and a list of values of the namelist group object list item." This unambiguously states that each namelist group object list item (these are the ones listed in NAMELIST statements) have their names placed in the output record followed by an equals sign and the list of their values. Subobject designators do not appear in NAMELIST statements. EDITS to 10-007r1: None. SUBMITTED BY: John Reid HISTORY: 09-115 m187 F03/0128 submitted 09-115r1 m187 Passed by J3 meeting + F2008 fix {pulled} 09-187r2 m188 Failed J3 letter ballot #18 09-155: accept edit line number change, F2008 fix from m187 does not appear in 09-007r1; 10-239 m193 Revised answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0001 TITLE: Generic resolution with pointer dummy arguments KEYWORDS: Generic, Pointer, Allocatable DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider INTERFACE gen SUBROUTINE suba(a) REAL,ALLOCATABLE :: a(:) END SUBROUTINE SUBROUTINE subp(p) REAL,POINTER,INTENT(IN) :: p(:) END SUBROUTINE END INTERFACE REAL,ALLOCATABLE,TARGET :: x(:) ALLOCATE(x(100)) CALL gen(x) The call to gen(x) is compatible both with suba, since x is allocatable, and with subp, since x and p satisfy the requirements in 12.5.2.7 paragraph 2 (p is an INTENT(IN) pointer, x is an allowable target for p). Is this program fragment standard-conforming, and if so, which actual procedure is called? ANSWER: This program was not intended to be standard-conforming. An edit is supplied to add a sufficient requirement. EDITS to 10-007r1: [286:4] In 12.4.3.4.5p3, in the third bullet after "the other has the POINTER attribute", Insert "and not the INTENT(IN) attribute". SUBMITTED BY: Bill Long HISTORY: 10-145 m192 F08/0001 submitted 10-145r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- 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 WG5 letter ballot QUESTION: At [10-007r1: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-007r1: In the first sentence of [111:19-20 5.6p5], replace "type parameters, and shape" by "kind type parameters, and rank". SUBMITTED BY: Van Snyder on behalf of Tobias Burnus HISTORY: 10-146 m192 F08/0002 Submitted 10-146r1 m192 Proposed answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0003 TITLE: Is a disassociated pointer allowed as an actual DIM argument? KEYWORDS: DIM argument DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Several intrinsic functions, such as ANY, have a DIM argument, with the rank of the result depending upon whether it is present. There is a prohibition against the actual argument being an optional dummy argument, but not against it being a disassociated pointer or deallocated allocatable. Is the following program standard conforming, and if so what does it print? program DIM_Arg integer, pointer :: Dim => NULL() logical :: Mask(2,2) = & & reshape( (/ .true., .false, .false, .true. /), (/ 2, 2 /) ) print *, shape( any(mask,dim) ) end program DIM_Arg The description worked until we allowed a disassociated pointer or unallocated allocatable variable that is associated with a nonpointer nonallocatable optional argument to be interpreted not to be present. ANSWER: It was intended that this program not conform. It was an oversight that disassociated pointer and unallocated allocatable actual arguments were not prohibited to correspond to DIM dummy arguments for these intrinsic functions. Edits are provided to clarify this. These functions were intended to behave similarly to MAXLOC et al, where this issue does not arise. Edits are provided to change the descriptions accordingly. EDITS to 10-007r1: [13.2.4p1 316:24-25] Replace "an optional" by "a" and replace ", if present, specifies" by "can specify". [13.5 Table 13.1 319] Replace "ALL (MASK [, DIM])" by "ALL (MASK) or ALL (MASK, DIM)". Replace "ANY (MASK [, DIM])" by "ANY (MASK) or ANY (MASK, DIM)". [13.5 Table 13.1 322] Replace "NORM2 (X [, DIM])" by "NORM2 (X) or NORM2 (X, DIM)". Replace "PARITY (MASK [, DIM])" by "PARITY (MASK) or PARITY (MASK, DIM)". [13.5 Table 13.1 323] Replace "THIS_IMAGE (COARRAY[, DIM])" by "THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.10 328:2] Replace the subclause heading by "ALL (MASK, DIM) or ALL (MASK)" [13.7.10p3 328:7] In the description of the DIM argument, delete "(optional)". [13.7.10p4 328:10] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.13 329:6] Replace the subclause heading by "ANY (MASK, DIM) or ANY (MASK)" [13.7.13p3 329:11] In the description of the DIM argument, delete "(optional)". [13.7.13p4 329:14] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.41p3 338:31] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.90p3 360:4] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.91p3 360:25] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.123 374:24] Replace the subclause heading by "NORM2 (X, DIM) or NORM2 (X)" [13.7.123p3 374:29] In the description of the DIM argument, delete "(optional)". [13.7.123p4 374:31] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.128 377:20] Replace the subclause heading by "PARITY (MASK, DIM) or PARITY (MASK)" [13.7.128p3 377:25] In the description of the DIM argument, delete "(optional)". [13.7.128p4 377:28] In the description of Result Characteristics, replace "is absent" by "does not appear". [13.7.165 392:6] Replace "or THIS_IMAGE (COARRAY[, DIM]) by ", THIS_IMAGE (COARRAY) or THIS_IMAGE (COARRAY, DIM)". [13.7.165p3 392:11] In the description of the DIM argument, delete "(optional)". [13.7.171p3 394:27] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". [13.7.172p3 395:11] In the description of the DIM argument, after "dummy argument" insert ", a disassociated pointer, or an unallocated allocatable". SUBMITTED BY: Van Snyder HISTORY: 10-148 m192 F08/0003 submitted 10-148r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot N1902 Edits amended during corrigendum construction ---------------------------------------------------------------------- NUMBER: F08/0005 TITLE: optional arguments and ASSOCIATED KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Subsumed by F08/0004 QUESTION: If the actual argument associated with the dummy argument TARGET of the intrinsic function ASSOCIATED is a disassociated pointer, is the dummy argument TARGET to be treated as an optional argument that is not present or as an argument that is present? ANSWER: The dummy argument TARGET should be treated as an argument that is present. DISCUSSION: This problem was created by the Fortran 2008 extension that declares that a dummy argument is not present if it corresponds to an actual argument that is a disassociated pointer [12.5.2.12p1, 299:15-17]. Among the solutions that have been suggested are (1) removing the extension, (2) restricting the extension to apply only to user-defined functions, (3) adding an exception to the extension for the intrinsic function ASSOCIATED, (4) changing the specification of ASSOCIATED in [17.7.16, 330:7-42] to specify two signatures. As attractive as the first two solutions are, I initially favored solution (3) as it caused the least change to the language as defined in recent drafts. I proposed to add text to Section 12.5.2.12 specifying the exception. Over time, I changed my mind; I now favor solution (4). I initially favored solution (3) over solution (4) because solution (4) does not treat the dummy argument TARGET as not present when the corresponding actual argument is an optional argument that is not present. That functionality is in Fortran 2003, and I did not think it should be removed. The more I thought about the issue, the more I was convinced that that functionality is useless except for programs written for test suites. I am now convinced that removing that functionality improves the language by making it possible for a processor to treat use of that functionality as the error it almost certainly is. EDITS to 10-007r1: [13.7.16, 330:7] Replace "ASSOCIATED (POINTER [,TARGET])" with "ASSOCIATED (POINTER) or ASSOCIATED(POINTER, TARGET)". [13.7.16p5 case (i) , 330:18] Replace "is absence" with "does not appear". [13.7.16p5 case (ii), 330:19] Replace "is present" with "appears". [13.7.16p5 case (iv), 330:23] Replace "is present" with "appears". [13.7.16p5 case (v), 330:26] Replace "is present" with "appears". [13.7.16p5 case (vi), 330:30] Replace "is present" with "appears". [13.7.16p5 case (vii), 330:33] Replace "is present" with "appears". SUBMITTED BY: Robert Corbett HISTORY: 10-152 m192 F08/0005 submitted - subsumed by F08/0004 10-202 m192 Confirmed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 ------------------------------------------------------------------------ NUMBER: F08/0006 TITLE: Generic resolution, intrinsic procedures, and host association KEYWORDS: intrinsic, generic, host association DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: The specifications of some intrinsic functions and subroutines explicitly ban certain combinations of arguments, even though those combinations are included in the title and the argument portion of the specification of the function or subroutine. Examples include CMPLX and RANDOM_SEED. Other requirements include being a valid KIND type parameter value (e.g. INT) or having having character length 1 (e.g. ICHAR). Consider the program fragment PROGRAM p INTERFACE cmplx LOGICAL FUNCTION mycmplx(a,b) COMPLEX a REAL b END END INTERFACE INTERFACE random_seed SUBROUTINE my_random_seed(get,put,size) INTEGER,OPTIONAL :: get(:),put(:),size END SUBROUTINE END INTERFACE INTERFACE int INTEGER FUNCTION myint(i,j) END END INTERFACE COMPLEX :: z = (1,2) REAL :: r = 3 CALL check CONTAINS SUBROUTINE check INTRINSIC int,cmplx,random_seed PRINT *,cmplx(z,r) ! Reference (1). CALL random_seed(GET=a,PUT=b) ! Reference (2). PRINT *,int(3,17) ! Reference (3). END SUBROUTINE END PROGRAM Are the procedure references (1), (2), and (3) invalid references to the intrinsic procedures CMPLX, RANDOM_SEED, and INT, or are they valid references to the user procedures mycmplx, my_random_seed, and myint respectively? ANSWER: Reference (1) is a valid reference to the user procedure. Both references (2) and (3) are invalid references to the intrinsic procedures; however, no constraints are violated so a standard- conforming processor may do anything, including treating them as references to the user procedures. DISCUSSION: 12.5.5.2 paragraph 4 explains that the reference is to the intrinsic procedure if it is "consistent with the interface of that intrinsic procedure". The interface to an intrinsic procedure consists of its name, characteristics, and dummy argument names. The characteristics of a procedure as defined by 12.4.1 do not include arbitrary restrictions such as those for RANDOM_SEED which are on argument presence (an execution time concept). Nor are requirements such as an actual argument being required to be a constant expression part of an interface. In the case of CMPLX however, there is no specific version whose interface has an X argument of type COMPLEX and any Y argument. 13.7.36 describes this by "If X is of type complex, no actual argument shall correspond to Y". Therefore the reference to CMPLX with such arguments is not consistent with the intrinsic. EDITS to 10-007r1: None. SUBMITTED BY: Robert Corbett HISTORY: 10-153 m192 F08/0006 submitted 10-153r1 m192 Draft answer 10-153r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Amended by J3 letter ballot 10-199; failed J3 letter ballot 10-199 10-236 m193 Revised answer for F2008 10-236r1 m193 Revised example - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0007 TITLE: Can zero have more than one bit sequence representation? KEYWORDS: zero, bits DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTIONS: Question (1): Some processors provide two internal representations for the integer value zero. The ones' complement representation of signed integers and the signed-magnitude representation of signed integers both provide two representations for zero. Must a processor for such a machine use a bit sequence consisting of all zero bits to represent zero, regardless of the internal representation of zero? Question (2): The Fortran 2008 standard [13.3.1, 317:9] states The interpretation of a negative integer as a sequence of bits is processor dependent. Could a standard-conforming processor interpret all negative integers as a sequence of all zero bits? ANSWERS: Answer to question (1): Yes. The standard does not allow for more than one bit representation of zero. Answer to question (2): No. The standard specifies that the integer value of a string of all zero bits is zero. The standard does not specify the integer values for bit strings when the leftmost bit is one. A processor could interpret all negative integers as a sequence of a one followed by all zero bits. It would not be a useful bit representation but it is not disallowed. EDITS to 10-007r1: None. SUBMITTED BY: Robert Corbett HISTORY: 10-154 m192 F08/0007 submitted 10-154r1 m192 Draft answer 10-154r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0009 TITLE: Is ABS ever required to be the optional IEC 60559 abs? KEYWORDS: ABS, IEEE DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: Are there any circumstances where the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in the optional portion of IEC 60559? DISCUSSION: Chapter 14 of F2008 does not define an IEEE_ABS intrinsic as a separate IEEE version of ABS and the example given in Section 14.11.3p7 [409:26] requires that ABS comply with the function abs specified in the optional portion of IEC 60559. We infer that the standard intended for the ABS intrinsic to be compliant with the IEC 60559 definition. ANSWER: Yes, the Fortran standard requires the intrinsic function ABS to be compliant with the function abs described in IEC 60559. An edit is provided to make that explicit. EDITS to 10-007r1: In 14.9p1 [406:15+] add a bullet after the second bullet of the list: "the IEEE function abs shall be provided by the intrinsic function ABS," SUBMITTED BY: Robert Corbett HISTORY: 10-156 m192 F08/0009 submitted 10-156r1 m192 Draft answer 10-156r2 m192 Revised answer 10-156r3 m192 Revised again - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0010 TITLE: deallocating objects that are associated with other objects KEYWORDS: DEALLOCATE associated DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Q1: Consider the program SUBROUTINE SUBR(A) REAL A(*) REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q DEALLOCATE (P) END PROGRAM MAIN REAL, POINTER, DIMENSION(:) :: P, Q COMMON P, Q ALLOCATE(P(100)) P = 1.0 Q => P CALL SUBR(Q(1:100:11)) END The subroutine SUBR deallocates the object containing the subobject associated with the nonpointer argument A. Is it intended that a pointer may be deallocated while its target is associated with a nonpointer entity? Q2: Consider the code fragment ASSOCIATE (X=>A(3)) DEALLOCATE (A) X = 0.0 where A is an allocatable array that is allocated at the start of the code fragment. Is it intended that an allocatable variable may be deallocated while it is associated with an associate name? ANSWER: A1: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. A2: No, the deallocation is not intended to be permitted. An edit is supplied to correct this oversight. EDITS to 10-007r1: [6.7.3.2p1, 130:23] Add the following sentence to the end of the paragraph "An allocatable variable shall not be deallocated if it or any subobject of it is argument associated with a dummy argument or construct associated with an associate name." [6.7.3.3p1, 131:27] Add the following sentence to the end of the paragraph "A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name." SUBMITTED BY: Robert Corbett HISTORY: 10-157 m192 F08/0010 submitted 10-157r1 m192 Draft answer 10-157r2 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0011 TITLE: How many times are constructed values finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f10,f11 End Type Type,Extends(t1) :: t2 Real d Contains Final :: f20,f21 End Type Contains Subroutine f10(x) Type(t1),Intent(InOut) :: x Print *,'f10 called' End Subroutine Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine Subroutine f20(x) Type(t2),Intent(InOut) :: x Print *,'f20 called' End Subroutine Subroutine f21(x) Type(t2),Intent(InOut) :: x(:) Print *,'f21 called' End Subroutine End Module Program q Call sub(1.5,2.5) End Program Subroutine sub(x,y) Use m Type(t1),Parameter :: p1 = t1(2.5) Type(t2),Parameter :: p2 = t2(3.5,-3.5) Call s10(t1(x)) Call s11([p1]) ! (a) Call s11([t1(x)]) ! (b) Call s11([ [ [ p1,p1 ] ] ]) ! (c) Call s20(t2(x,y)) Call s21([p2]) ! (d) Call s21([t2(y,y)]) ! (e) Call s21([t2(t1=p1,y)]) ! (f) Call s21([t2(t1=t1(x),y)]) ! (g) Call s21([(p2,t2(x,y),i=1,10**7)]) ! (h) End Subroutine The topic is how many times each final procedure is called on return from each subroutine? For s10, clearly f10 is called once. For s11(a), clearly f11 is called once, and f10 is not called. For s11(b), the standard (4.5.6.3 para 5) seems to indicate that f10 is called. That would not make much sense - the value of the structure constructor is part of the value of the array constructor, so calling f10 would mean that that array element would be finalized twice (once by f11, once by f10, in no set order). For s11(c), the standard standard appears to say that f11 is called three times, once for each (nested) array constructor. Seeing as how nesting array constructors is a syntactic thing that makes zero difference to the value - the value of [[anything]] is identical in every respect to the value of [anything] - this does not seem to make sense. For s20, clearly f20 is called once, and f10 is called afterwards to finalize the parent component. For s21(d), clearly f21 is called once, followed by f11 to finalize the parent components. f20 and f10 are not called. For s21(e), f21 and f11 are called as in s21(d); the standard implies that f20 and then f10 are called, but that does not make sense, the same as case s11(b). For s21(f), the situation seems to be the same as s21(e); the wanted f21 and f11, and (unordered) the unwanted f20 and f10. For s21(g), f21 and f11 are called as in s21(d); the standard implies that f10 is called to finalize t1(3) and also that f20 and then f10 are called to finalize t2(t1=t1(3),4). This makes even less sense than before, since the t1 part of the array constructor element is going to be finalized 3 times just because of the syntax we used. For s21(h), f21 and f11 are called as in s21(d) to finalize the whole array constructor value; the standard also implies that f20 and then f10 are called on all of the 5000000 even-numbered elements. Requiring the processor to keep track of all those elements to be finalized on return from s21 seems rather severe. Furthermore, an object that has been finalized is not permitted to be referenced or defined. That makes the multiple finalization interpretation even more hard to understand. Philosophically, finalization should finalize objects exactly once. There seem to be three possibilities here. (1) The finalizers are called multiple times, but on the separate entities created by the constructors. For example s21(g), that is t1(3) is created as object X, when t2(...) is evaluated a new separate object Y is created and that value is copied into it, and when [...] is evaluated a third object Z is created with the value of Y copied into it; afterwards, we effectively have call f10(X); call f20(Y); call f21(Z); call f11(Z%t1) For s21(h) that burden is going to be extreme because the standard says these are "finalized after execution of the innermost executable construct containing the reference" (and it is possible to detect this in a conforming program); changing that to "finalized after the value has been used" would be better if slightly vague. (2) These entities are indeed finalized multiple times, just as the standard implies. (3) Constructors that are merely providing part of the value of a bigger constructor are not finalized. (4) Constructors should never be finalized in themselves, this was just a design error that inevitably leads to multiple or unwanted finalization. Which is the correct approach? ANSWER: Approach 4. Constructors don't do anything that needs finalization. Edits are provided to correct the mistake. NOTE: This answer subsumes interp F08/0012 (10-159r1). EDITS to 10-007r1: [24:9] Change the first word of 1.6.2p1 "This" -> "Except as identified in this subclause, this". [24:11+] Insert new paragraph after 1.6.2p1: "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:17-18,21-22] Delete paragraphs 5 and 7 of 4.5.6.3 (When finalization occurs). SUBMITTED BY: Malcolm Cohen HISTORY: 10-158 m192 F08/0011 submitted 10-158r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- 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 to 10-007r1: N/A. SUBMITTED BY: Malcolm Cohen HISTORY: 10-159 m192 F08/0012 submitted 10-159r1 m192 Revised - subsumed by F08/0011 10-202 m192 Confirmed by J3 letter ballot #21 10-199 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0013 TITLE: How does finalization interact with allocatable assignment? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' End Subroutine End Module Program q Use m Type(t1),Parameter :: ap1(1) = [ t1(1.5) ] Type(t1),Parameter :: ap2(3) = [ t1(2.5),t1(3.5),t1(4.5) ] Type(t1),Parameter :: ap3(3) = t1(0.5) Type(t1),Allocatable :: x(:) x = ap1 ! (*1) x = ap2 ! (*2) x = ap3 ! (*3) End Program The topic is how 4.5.6.3 paragraphs 1 and 9 interact. The relevant texts are, respectively: "When an allocatable entity is deallocated, it is finalized." "When an intrinsic assignment statement is executed, the variable is finalized after evaluation of and before the definition of the variable." In the assignment marked (*1), paragraph 9 says that the variable (X) is finalized, i.e. CALL F11(X) is executed. However, this would be invalid, because an unallocated allocatable would be associated with a nonallocatable nonoptional dummy argument. In the assignment marked (*2), paragraph 9 again says that the variable is finalized - after evaluation of but before the definition of the variable. However, because the shapes of the variable and the expression differ, definition of the variable involves deallocating the variable (and allocating it with the correct shape). Paragraph 1 says that deallocating the variable finalizes it, so that means that F11 should be called twice for the variable. This is problematic since a finalized entity is not permitted to be referenced or defined by a final subroutine. In the assignment marked (*3), the variable and expression have the same shape so the variable will not be deallocated, so according to paragraph 9 it should be finalized once. Q1. Are all the assignment statements standard-conforming? Q2. How many times is the variable finalized (i.e. how many times is the final subroutine called) in each standard-conforming case? ANSWER: A1. Yes, all the assignment statements are intended to be standard conforming. Edits are supplied to correct the problem in (*1). A2. The variable is finalized exactly once, except when it was unallocated (and then it is not finalized). Edits are supplied to correct the problem in (*2). EDITS to 10-007r1: [76:10] 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:25] In 4.5.6.3 When finalization occurs, move paragraph 9 of the subclause and Note 4.49 to precede paragraph 1. In addition, edit the paragraph by changing "the variable is" to "if the variable is not an unallocated allocatable variable, it is" and by appending a new sentence at the end of the paragraph: "If the variable is an allocated allocatable that would be deallocated by intrinsic assignment, the finalization occurs before the deallocation.". SUBMITTED BY: Malcolm Cohen HISTORY: 10-160 m192 F08/0013 submitted 10-160r1 m192 Revised 10-160r2 m192 Revised edit - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot N1902 Edits amended during corrigendum construction ------------------------------------------------------------------------ NUMBER: F08/0014 TITLE: Finalizing assignment to vector-subscripted object KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program: Module m Type t1 Real c Contains Final :: f11 End Type Contains Subroutine f11(x) Type(t1),Intent(InOut) :: x(:) Print *,'f11 called' x%c = 0 ! (*) End Subroutine End Module Program q Use m Type(t1) :: x(10) = t1(0) x( [1,4,9] ) = t1(1.5) Print *,x End Program According to 6.5.3.2.2 Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." Therefore the program above is not standard-conforming; however it seems that deleting the assignment statement marked (*) would make the program standard-conforming. This seems to make final subroutines not useful when vector subscripts are involved; either the finalization doesn't do anything to the object in which case the vector subscript is allowed, or it does do something (like deallocation) in which case the vector subscript is disallowed. Also, since passing vector-subscripted objects as actual arguments is almost certainly going to pass a copy (and what's more a copy that won't be copied back), this results in something other than the actual entity being finalized - and this is possibly visible if pointers and targets are involved. Finally, these apparent violations of the standard are probably not going to be detected on many processors, resulting in silent wrong answers. At least if vector subscripted sections being finalized were rejected at compile time the user would stand a chance of avoiding these problems. Q. Is this analysis correct, and is this situation deliberate? ANSWER: A. The analysis is correct. This should have been alleviated by allowing elemental procedures to modify vector-subscripted arguments. An edit is supplied. EDITS to 10-007r1: [124:7+] After 6.5.3.3.2p2, insert new paragraph: "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine." [295:3] In 12.5.2.4p18, After "If" insert "the procedure is nonelemental and". SUBMITTED BY: Malcolm Cohen HISTORY: 10-161 m192 F08/0014 Submitted 10-161r1 m192 Revised answers and edits. 10-161r2 m192 Selected alternative answer, revised edits - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0015 TITLE: IMPLICIT KEYWORDS: IMPLICIT DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: 5.5 IMPLICIT statement contains the permission-giving statement: "The mapping may be to a derived type that is inaccessible in the local scope if the derived type is accessible to the host scope." But what if the derived type is not accessible to the host scope? Consider the module: module m implicit type(t) (a-z) type t real x end type contains subroutine s(x) type t character(10) c end type call inner(x) contains subroutine inner(y) a = x b = y print *,a%x,b%x end subroutine end subroutine end module In inner, the mapping is not to a derived type that is accessible to the host scope. Is this module standard-conforming? ANSWER: Yes. The statement apparently giving permission is in error: no permission needs to be given here, it simply follows from the other scoping rules. An edit is provided to clarify the standard. EDITS to 10-007r1: [109:21-22] (5.5p4) Delete the confusing sentence "The mapping may ... scoping unit.". SUBMITTED BY: Malcolm Cohen HISTORY: 10-162 m192 F08/0015 submitted 10-162r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0016 TITLE: Can a vector-subscripted argument become undefined? KEYWORDS: Vector subscript, actual argument, undefined. DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: According to 6.5.3.3.2 [124] Vector subscript, "An array section with a vector subscript shall not be ... argument associated with a dummy array that is defined or redefined ..." How can we predict the future? And even if we could, it implies that it would be ok for the dummy array to be undefined (because it only forbids becoming defined). As it happens, 12.5.2.4p18 [295:3-4] already says it is not definable, so already covers being defined and redefined - and also becoming undefined, and also prevents not just INTENT(OUT) or INOUT but also ASYNCHRONOUS and VOLATILE. What is the point to this future-predicting confusing redundancy? ANSWER: This paragraph is completely redundant as well as incomplete. C724 [158:19-20] covers in a pointer assignment statement. 9.4p2 first bullet[203:6-7] copvers internal files. An edit is supplied to correct this situation. EDITS to 10-007r1: [124:4-7] Delete 6.5.3.3.2 paragraph 2. SUBMITTED BY: Malcolm Cohen HISTORY: 10-163 m192 F08/0016 submitted 10-163r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0017 TITLE: Elemental subroutine restrictions KEYWORDS: ELEMENTAL, SUBROUTINE DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the following elemental subroutine ELEMENTAL SUBROUTINE test_add(a,b) REAL,INTENT(IN) :: a,b REAL c c = a+b END SUBROUTINE and the following reference: REAL x(10),y LOGICAL toobig ... CALL IEEE_SET_FLAG(IEEE_OVERFLOW,.FALSE.) CALL test_add(x,y) CALL IEEE_GET_FLAG(IEEE_OVERFLOW,toobig) The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow. Is this program fragment standard-conforming? 12.8.3 says "In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments corresponding to INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them." Obviously, it is not the case that all actual arguments are scalar. However, there not being any actual arguments corresponding to INTENT(OUT) or INTENT(INOUT) dummy arguments, it is not possible for the remaining actual arguments (x and y) to be conformable with them. Is this an oversight? (If not, it seems a very clumsy way of requiring elemental subroutines to have an INTENT(OUT) or INTENT(INOUT) argument, and one that doesn't work if they are only referenced with scalar arguments.) ANSWER: Yes, the program fragment is intended to be standard-conforming. An edit is supplied to correct the oversight in the standard. EDITS to 10-007: [314:16-19] In 12.8.3, replace the second sentence "In a reference ... them." by "In a reference to an elemental subroutine, if any argument is an array, all actual arguments that correspond to INTENT (OUT) or INTENT (INOUT) dummy arguments shall be arrays. All actual arguments shall be conformable." NOTE: This edit is potentially subsumed by the edit in the interp F08/0018 (10-168r1) "Impure elemental restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-167 m192 F08/0017 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0018 TITLE: Impure elemental restrictions KEYWORDS: IMPURE, ELEMENTAL DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: With the following two impure elemental procedures, which perform essentially the same calculations, IMPURE ELEMENTAL SUBROUTINE one(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x END SUBROUTINE IMPURE ELEMENTAL REAL FUNCTION two(x,y) INTENT(IN) x INTENT(OUT) y REAL :: z = 0 y = x + z z = x two = y - z END FUNCTION consider these references: REAL a(10),b,c ... CALL one(b,a) ! (i) ok, equivalent to CALL one([(b,i=1,10)],a) CALL one(a,b) ! (ii) not ok, prohibited by 12.8.3p1, sentence 2. c = two(b,a) ! (iii) ok, like (i) d = two(a,b) ! (iv) NOT prohibited!?! Was allowing case (iv) an oversight? ANSWER: Yes, this was an oversight: after adding impure elementals, the elemental subroutine argument restrictions need to apply to elemental functions as well. EDITS to 10-007r1: [314:5+] at the end of 12.8.1, 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:9-10] In 12.8.2p1, delete the third sentence; that sentence reads "For those ... conformable.". {Redundant with new paragraph.} [314:14-17] In 12.8.3p1, delete the second sentence; that sentence reads "In a reference ... conformable with them.". {Redundant with new paragraph.} NOTE: These edits subsume the one in the interp F08/0017 (10-167r1) "Elemental subroutine restrictions". SUBMITTED BY: Malcolm Cohen HISTORY: 10-168 m192 F08/0018 submitted 10-168r1 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0019 TITLE: Transformational Bessel functions KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider INTEGER :: n1(10) = 1,n2(2,3,4,5) = 2 ... PRINT *,BESSEL_JN(n1,n2,[1.0,2.0]) The description of BESSEL_JN, transformational version, merely states that N1 and N2 "shall be of type integer and nonnegative", and for X merely states that it "shall be of type real". There is no requirement on rank or conformability. Is this conforming, and if so, what value(s) should it print? A similar question applies to BESSEL_YN. ANSWER: This was not intended to be conforming. The N1 and N2 arguments should have been required to be scalar, as should the X argument for the transformational version of the function. Edits are supplied to correct this oversight. A similar answer pertains to the similar question for BESSEL_YN, and similar edits are supplied. EDITS to 10-007r1: [333:12,13] In 13.7.24p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [333:14] In 13.7.24p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". [334:12,13] In 13.7.27p3, lines beginning N1 and N2, replace "of type integer and nonnegative" by "an integer scalar with a nonnegative value". [334:14] In 13.7.27p3, line beginning X, after "real" insert "; if the function is transformational, X shall be scalar". SUBMITTED BY: Malcolm Cohen HISTORY: 10-169 m192 F08/0019 submitted 10-169r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0020 TITLE: FINDLOC and logical arguments KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider REAL :: array(1000),value COMPLEX :: carray(1000),cvalue LOGICAL :: ilarray(1000),ilvalue ... PRINT *,FINDLOC(array,value) PRINT *,FINDLOC(carray,cvalue) PRINT *,FINDLOC(ilarray,ilvalue) Are any of the references to FINDLOC standard-conforming? 13.7.61 requires of the VALUE argument that it "shall be ... in type conformance with ARRAY, as specified in Table 7.2 for relational intrinsic operations 7.1.5.5.2).". Yes, there is an unpaired parenthesis. More to the point: (a) Table 7.2 is in 7.1.5.1 not in 7.1.5.5.2; (b) there is no table about type conformance in 7.1.5.5.2, (c) for type logical, the comparison is allegedly done by .EQV., but that is not a relational operator. It could be argued that the reference to 7.1.5.5.2 is just misleading, and reading the rest of the sentence we should indeed use Table 7.2, with the conformance as specified for the relational operators. That would make the first reference to FINDLOC conforming. The second reference to FINDLOC is more problematic, because some relational operators permit complex arguments (e.g. .EQ.) and some do not (.LE.). This makes it ambiguous as to whether or not it is conforming. The third reference to FINDLOC is the most problematic, because no relational operators permit logical arguments. Later on, FINDLOC says it uses .EQV. for logical comparison, but .EQV. is a logical operator not a relational operator, so in any case VALUE cannot satisfy the rules in Table 7.2. ANSWER: These were all intended to be standard-conforming. Edits are supplied to correct the requirement. EDITS to 10-007r1: [347:31-32] In 13.7.61p3, VALUE argument, replace "for ... )" by "for the operator == or the operator .EQV.". {NB: Use the same operators as specified in 13.7.61p6. Use disjunction to avoid misinterpreting it as requiring both at once.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-170 m192 F08/0020 submitted 10-170r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0021 TITLE: STORAGE_SIZE and unlimited polymorphic KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider CLASS(*),POINTER :: p NULLIFY(p) PRINT *,STORAGE_SIZE(p) Note that p does not have any deferred type parameters, so is not prohibited from being a disassociated pointer in a reference to STORAGE_SIZE. Was this intended to be standard-conforming? If so, what value would be printed? Zero? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to insert the missing prohibition. EDITS to 10-007r1: [390:6] In 13.7.160p3, argument A, before "has any deferred" insert "is unlimited polymorphic or", and after "type parameters" insert ",". {Comma to make the sentence easier to read, not strictly necessary.} That makes the whole sentence read: "If it is unlimited polymorphic or has any deferred type parameters, it shall not be an unallocated allocatable variable or a disassociated or undefined pointer." SUBMITTED BY: Malcolm Cohen HISTORY: 10-171 m192 F08/0021 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0022 TITLE: DO CONCURRENT and file i/o KEYWORDS: DO CONCURRENT DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: The standard states [178:15-16] that "An input/output statement shall not write data to a file record or position in one iteration and read from the same record or position in a different iteration." In the loop DO CONCURRENT (i=1:2) IF (i==1) READ(17,REC=100) x ! (a) IF (i==2) WRITE(17,REC=100) y ! (b) END DO The input/output statement at (a) only reads data from the file, it does not write it, and thus does not fall foul of this restriction. Similar reasoning shows that the input/output statement at (b) also obeys this restriction. Is this fragment intended to be standard-conforming? ANSWER: No, the example is not intended to be standard-conforming. An edit is supplied to make the requirement less ambiguous. EDITS to 10-007r1: [178:15-16] In 8.1.6.7p1, penultimate bullet point, replace the whole sentence "An input/output ... iteration." with "If data are written to a file record or position in one iteration, that record or position in that file shall not be read from or written to in a different iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-172 m192 F08/0022 submitted 10-172r1 m192 Draft answer 10-172r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0023 TITLE: DO CONCURRENT and POINTER KEYWORDS: DO CONCURRENT, POINTER DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) THEN ALLOCATE(x(i)) x = 3 ! Note: defines x, does not reference x. ELSE y(i) = SUM(x) ! (*) Note: references x. DEALLOCATE(x) END IF END DO This is clearly not conforming, as it violates the requirement in [178:8-9 8.1.6.7p1 second bullet]: "A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration." However, consider example 2, identical except for replacing the (*) statement with: y(i) = SIZE(x) ! (*) Note: SIZE does not reference x. That statement does not reference x (see definition of reference at 1.3.120) and so does not violate the requirement. An even simpler example which does not violate the requirement but which appears problematic is POINTER p NULLIFY(p) DO CONCURRENT(i=1:2) IF (i==1) ALLOCATE(p) IF (i==2) PRINT *,ASSOCIATED(p) END DO A third example which does not violate the requirement but again appears to be problematic is PROCEDURE(),POINTER :: p,q EXTERNAL a,b p => a DO CONCURRENT(i=1:2) IF (i==1) p => b IF (i==2) q => p ! (*1) END DO CALL q ! (*2) Note that (*1) does not reference p, but (*2) does reference q. The pointer q is only set by one iteration, so no problem there. Were these examples intended to be standard-conforming? ANSWER: No, the examples were not intended to be standard-conforming. An edit is supplied to correct the requirement. Comment: We don't need to require "pointer associated" for "reference", that is always required for references. What we need to require is for the pointer association status to be established. EDITS to 10-007r1: [178:8-9] In 8.1.6.7p1, second bullet, replace the first sentence "A pointer that is referenced ... any iteration." with the following sentence: "A pointer that is used in an iteration other than as the pointer in pointer assignment, allocation, or nullification, either shall be previously pointer-assigned, allocated, or nullified in that iteration or shall not have its pointer association changed during any iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-173 m192 F08/0023 submitted 10-173r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0024 TITLE: Dummy arguments of impure elemental procedures KEYWORDS: IMPURE, ELEMENTAL, INTENT DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider IMPURE ELEMENTAL SUBROUTINE swap1(a,b) REAL,INTENT(INOUT) :: a,b c = a a = b b = c END SUBROUTINE IMPURE ELEMENTAL SUBROUTINE swap2(a,b) REAL :: a,b c = a a = b b = c END SUBROUTINE ... REAL x,y(10) ... CALL swap1(x,y) ! (a) CALL swap2(x,y) ! (b) The rules for arguments of elemental subroutines means that CALL (a) is not standard-conforming. However, since there are no rules requiring declaration of INTENT (that being for PURE only), CALL (b) is apparently standard-conforming. Was this intended to be standard-conforming, and what should the effect be? ANSWER: This was not intended to be standard-conforming. Omission of the requirement for INTENT specification was inadvertent. An edit is supplied to correct this oversight. EDITS to 10-007r1: [314:5] Insert new constraint at the end of 12.8.1 "C1290a The of an elemental subprogram shall specify the intents of all of its dummy arguments that do not have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 10-174 m192 F08/0024 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0025 TITLE: DO CONCURRENT and ALLOCATABLE KEYWORDS: DO CONCURRENT, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the following example: REAL,POINTER :: x(:) REAL y(4) ... DO CONCURRENT (i=1:4) IF (IAND(i,1)==1) ALLOCATE(x(i),STAT=j) ... y(i) = SUM(x) IF (IAND(i,1)==1) DEALLOCATE(x,STAT=j) END DO This is clearly not conforming, as it violates the requirement in [178:5-6 8.1.6.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 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-007r1: [178:13-14] In 8.1.6.7p1, ante-penultimate bullet point, Replace the sentence "An object ... iteration." With "An allocatable object that is referenced, defined, deallocated, or has its allocation status, dynamic type, or a deferred type parameter value inquired about, in any iteration, either shall be previously allocated in that iteration or shall not be allocated or deallocated in any other iteration." SUBMITTED BY: Malcolm Cohen HISTORY: 10-175 m192 F08/0025 submitted 10-175r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0026 TITLE: DO CONCURRENT and output interleaving KEYWORDS: DO CONCURRENT, output DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the trivial example: DO CONCURRENT (i=1:1) PRINT *,'Line 1' PRINT *,'Line 2' END DO According to the ultimate bullet point of 8.1.6.7, the output records appear in an indeterminate order, therefore it appears that the processor is permitted to produce the output Line 2 Line 1 for that program fragment. Q1. Is this intentional? Also, this ordering statement appears as a bullet point belonging to "The following additional restrictions apply to execution of a DO CONCURRENT construct." but it is not a restriction, either on the user or on the processor (rather the opposite of a restriction on the processor). Q2. Should this not be a separate paragraph to avoid confusion? ANSWER: A1. No, this was not intentional. An edit is supplied to correct this. A2. Yes, this should not have been a bullet point as it does not belong in the list of restrictions. EDITS to 10-007r1: [178:17-18] Delete the last bullet point of 8.1.6.7p1. [178:18+] Insert new paragraph at the end of 8.1.6.7p1: "If records are written to a file connected for sequential access by more than one iteration, the ordering between records written by different iterations is indeterminate." {This leaves the statement within the subclause entitled "Restrictions on ..." which is suboptimal but not an actual contradiction.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-176 m192 F08/0026 submitted 10-176r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot N1902 Edit amended during corrigendum construction ------------------------------------------------------------------------ NUMBER: F08/0027 TITLE: ATOMIC_REF example KEYWORDS: intrinsic, atomic DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Is the example for ATOMIC_REF correct? ANSWER: No. The arguments are in the wrong order. EDIT to 10-007r1: [332:25] In 13.7.21 ATOMIC_REF, paragraph 4, change "CALL ATOMIC_REF (I [3], VAL)" to "CALL ATOMIC_REF (VAL, I [3])". SUBMITTED BY: John Reid HISTORY: 10-177 m192 F08/0027 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ 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 WG5 letter ballot QUESTION: Consider the following DO construct DO CALL SUB END DO According to subclause 8.1.6.6.4p1 penultimate bullet [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-007r1: Replace the fourth item in the bulleted list in subclause 8.1.6.6.4 Loop termination [177:28-29] with the following: "o A branch occurs within the range of a DO construct and the branch target statement is neither the nor within the range of the same DO construct." SUBMITTED BY: Van Snyder HISTORY: 10-178 m192 F08/0028 submitted 10-178r1 m192 Draft answer 10-178r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0030 TITLE: Unlimited format repeat effects KEYWORDS: repeat count DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program Program example Integer :: x(3) = (/ 1,2,3 /) Print 1,x 1 Format(1x,999999999('a',I0,'b')) Print 2,x 2 Format(1x,*('a',I0,'b')) Print 3,x 3 Format(1x,999999999('a',:,',',I0,'b')) Print 4,x 4 Format(1x,*('a',:,',',I0,'b')) End Program According to the first statement of 10.4p8 [249:12-13], "If format control encounters the rightmost parenthesis of a complete format specification and another effective item is not specified, format control terminates." This means that the first two lines of output should be a1ba2ba3ba a1ba2ba3b and the second two lines of output should be a,1ba,2ba,3ba a,1ba,2ba,3b But according to Note 10.7 [249:21+], "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-007r1: [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.4 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] In 10.4p7 last sentence, change "If format control reverts ... , the" to "The" SUBMITTED BY: Malcolm Cohen HISTORY: 10-180 m192 F08/0030 submitted 10-180r1 m192 Draft answer 10-180r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0033 TITLE: PURE polymorphic finalization KEYWORDS: PURE CLASS FINAL DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider MODULE m TYPE root REAL c CONTAINS FINAL pf PROCEDURE asgn GENERIC :: ASSIGNMENT(=) => asgn END TYPE TYPE,EXTENDS(root) :: t CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS PURE SUBROUTINE pf(x) TYPE(root),INTENT(INOUT) :: x x%c = 0 END SUBROUTINE SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE asgn(a,b) CLASS(root),INTENT(OUT) :: a CLASS(root),INTENT(IN) :: b a%c = b%c END SUBROUTINE SUBROUTINE process(array,scalar) CLASS(root) array(:),scalar FORALL (i=1:SIZE(array)) array(i) = scalar END SUBROUTINE END MODULE TYPE(root) w,x(100) TYPE(t) y(100),z ... CALL process(x,w) ! (1) CALL process(y,z) ! (2) The procedure reference at (1) will execute process with the dynamic types of its dummy arguments being TYPE(root); the finalization of the array elements caused by the defined assignment in the FORALL statement will execute only the pure procedure pf, so all is well. However, the procedure reference at (2) will execute process with the dynamic types of its dummy arguments being TYPE(t); the finalization of the array elements in this case will additionally call the impure final procedure f, so all is not well. However, this cannot be detected at compilation time. But constraint C1284 [313] 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-007r1: [24:10] 1.6.2p1 last sentence, "Any"->"Except as identified in this subclause, any". {This edit is also present in interp F08/0032.} [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted an INTENT(OUT) argument of a pure subroutine to be polymorphic; that is not permitted by this part of ISO/IEC 1539.". [312:23+] After C1278 and Note 12.47, insert new constraint: "C1278b An INTENT(OUT) dummy argument of a pure procedure shall not be polymorphic." [313:4+] After C1284, insert new constraint and note: "C1284a A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure. Note 12.48x Apart from the DEALLOCATE statement, this includes intrinsic assignment if the variable has a polymorphic allocatable component at any level of component selection that does not involve a pointer component but which might involve one or more allocatable components." SUBMITTED BY: Malcolm Cohen HISTORY: 10-183 m192 F08/0033 Submitted 10-183r1 m192 Revised note in the edit - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot N1902 Edit amended during corrigendum construction ------------------------------------------------------------------------ NUMBER: F08/0034 TITLE: ELEMENTAL INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider MODULE m TYPE t1 REAL,POINTER :: vec(:) CONTAINS FINAL f1 END TYPE TYPE t2 REAL,POINTER :: vec(:) CONTAINS FINAL f2 END TYPE CONTAINS PURE SUBROUTINE f1(x) TYPE(t1),INTENT(INOUT) :: x IF (ASSOCIATED(x%vec)) DEALLOCATE(x%vec) END SUBROUTINE PURE SUBROUTINE f2(y) TYPE(t2),INTENT(INOUT) :: y(:) INTEGER i DO i=1,SIZE(y) IF (ASSOCIATED(y(i)%vec)) DEALLOCATE(y(i)%vec) END DO END SUBROUTINE ELEMENTAL SUBROUTINE zap1(z1) TYPE(t1),INTENT(OUT) :: z1 END SUBROUTINE ELEMENTAL SUBROUTINE zap2(z2) TYPE(t2),INTENT(OUT) :: z2 END SUBROUTINE END MODULE ... TYPE(t1) a,aa(10) TYPE(t2) b,bb(10) ... CALL zap1(a) ! (1) CALL zap1(aa) ! (2) CALL zap2(b) ! (3) CALL zap2(bb) ! (4) The question is which CALL statements result in finalization and thus deallocation of the various vec components. If the finalization of an INTENT(OUT) argument is considered to happen "on invocation" in the caller, then presumably the CALL statements marked (1) and (4) will result in deallocation. On the other hand, if the finalization of an INTENT(OUT) argument is considered to be done in the called procedure, then arguably it is the CALL statements marked (1) and (2) instead that will result in deallocation. In either case some clarification would seem to be useful. Q. Which statements result in deallocation of the vec components? ANSWER: A. The finalization is considered to occur in the called procedure, so the statements marked (1) and (2) will result in deallocation of the vec components. Note that this is consistent with the answer to interp F08/0031 (10-181r1). EDITS to 10-007r1: [76:24] At the end of 4.5.6.3 paragraph 8, append new sentence "The finalization caused by INTENT(OUT) is considered to occur within the invoked procedure; so for elemental procedures, an INTENT(OUT) argument will be finalized only if a scalar or elemental final subroutine is available, regardless of the rank of the actual argument." SUBMITTED BY: Malcolm Cohen HISTORY: 10-184 m192 F08/0034 submitted 10-184r1 m192 Selected alternative answer, fixed example - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0035 TITLE: Maximum value for SHIFT argument to SHIFTL and SHIFTR KEYWORDS: SHIFTL, SHIFTR, BIT_SIZE DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTION: A significant part of the justification for the addition of the redundant SHIFTL and SHIFTR intrinsic functions was that in the case of a nonconstant SHIFT argument, the generated code needed to test the shift direction and that such tests were inefficient. However, it is not uncommon for the actual hardware shift instructions to only shift the argument modulo the bit size, for either 32-bit or 64-bit shifts, or both. Since SHIFT is allowed to be equal to the bit size, this means that tests still need to be done to check for this case. Since being able to generate the value zero by shifting an arbitrary nonzero argument completely, applying the feature justification leads one to surmise that perhaps SHIFT should have been limited to BIT_SIZE-1 instead of BIT_SIZE. Q. Should the maximum value of the SHIFT argument to the SHIFTL and SHIFTR intrinsics be BIT_SIZE or BIT_SIZE - 1? Note: A similar argument does not apply quite so straightforwardly to SHIFTA, since it provides new functionality. ANSWER: A. Although allowing SHIFTL and SHIFTR by BIT_SIZE provides little useful functionality, this is allowed for consistency with ISHFT. EDITS to 10-007r1: None. SUBMITTED BY: Malcolm Cohen HISTORY: 10-185 m192 F08/0035 submitted 10-185r1 m192 Draft answer with straw vote alternative == answer not alternative - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0036 TITLE: NORM2 example in Annex C KEYWORDS: intrinsic, norm2 DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Is the example for NORM2 in C.13.3.6 [527] correct? ANSWER: No. "|X_i|" should be "|X_i|^2". EDITS to 10-007r1: [527:18 p3] In C.13.3.6 Vector norms (13.7.2, 13.7.109, 13.7.123), paragraph 3, replace "|X_i|" by "|X_i|^2". SUBMITTED BY: John Reid HISTORY: 10-186 m192 F08/0036 submitted 10-186r1 m192 Draft answer 10-186r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0037 TITLE: PROCEDURE POINTER vs PROTECTED KEYWORDS: PROCEDURE, PROTECTED DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Is the following module fragment correct syntax for an abstract interface i_f? procedure(i_f), pointer, protected :: p_f1 => null() F2008 10-007r1 [100:4] C549 says "An entity with the PROTECTED attribute shall be a procedure pointer or variable." But in 12.4.3.6 [287:11+] R1213 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-007r1: [xvi] In the last item in the main bulleted list (Programs and procedures), before "The FUNCTION and SUBROUTINE" insert the new sentence: "The PROTECTED attribute can be specified by the procedure declaration statement." [287:15+] in R1213 after "<> POINTER", insert a new line "<> PROTECTED" SUBMITTED BY: Stan Whitlock HISTORY: 10-188 m192 F08/0037 submitted 10-188r1 m192 Draft answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot N1902 Edit added during corrigendum construction ----------------------------------------------------------------------- NUMBER: F08/0039 TITLE: Many-one vector subscript usage KEYWORDS: Vector subscripts. DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider SUBROUTINE zap(z,i) REAL z(:) INTEGER i(:) IF (no_duplicates(i)) z(i) = 0 END SUBROUTINE ... REAL x(10) ... CALL zap(x,(/ 2,3,2 /)) (The user-defined function no_duplicates returns .TRUE. if and only if its argument has no duplicate values.) 6.5.3.3.2 "Vector subscript" paragraph 3 [124] 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-007r1: [124:9] In 6.5.3.3.2p3 replace "shall ... (16.6.7)" with "is not definable and shall not be defined or become undefined". SUBMITTED BY: Malcolm Cohen HISTORY: 10-195 m192 F08/0039 submitted - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed by WG5 letter ballot ------------------------------------------------------------------------ NUMBER: F08/0044 TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot QUESTIONS: Consider the following code: module m type :: foo integer :: i = 0 end type end module m program p use m class(foo), allocatable :: o_foo[:] integer :: j allocate(foo :: o_foo[*]) if (this_image() == 1) then select type(a => o_foo[2]) ! 1 type is(foo) j = a%i end select select type(a => o_foo) ! 2 type is(foo) j = a[2]%i end select select type(o_foo) ! 3 type is(foo) j = o_foo[2]%i end select end if end program p (1) Is the first SELECT TYPE block standard-conforming? (2) Is the second SELECT TYPE block standard-conforming? (3) Is the third SELECT TYPE block standard-conforming? ANSWERS: References are to 10-007 (1) No. is in the definition of in R847 [184:10]. is defined in R805 [170:17]. C803 [170:22] disallows a coindexed object if is a . C803 constrains in both and . (2) Yes. This is implied by 8.1.3.3 para 1 [171:2]. (3) Yes. EDITS to 10-007r1: None SUBMITTED BY: R. Bader HISTORY: 10-209 m193 F08/0044 submitted 10-209r1 m193 Proposed answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1889 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0046 TITLE: VALUE attribute restrictions KEYWORDS: VALUE DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program unit SUBROUTINE s(x,y,n) REAL,VALUE :: x(:) CHARACTER(n),VALUE :: y DO i=2,SIZE(x) x(i) = x(i) + x(i-1) END DO PRINT *,y,x END SUBROUTINE This is not valid in Fortran 2003 as it violates constraint C527 "If the VALUE attribute is specified, the ... DIMENSION ... attribute shall not be specified." and also violates constraint C528 "If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions." The corresponding constraint to F2003/C527 for Fortran 2008, C558 [101], does not prohibit the DIMENSION attribute. There does not appear to be any constraint in F2008 corresponding to F2003/C528. Therefore this program unit is apparently now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention these as new features. Is the omission of these requirements an oversight? ANSWER: No, these are deliberate additions to the language. An edit is supplied to clarify the Introduction. EDITS to 10-007r1: [xv] Introduction, bullet "Data declaration", append "An array or an object with a nonconstant length type parameter can have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 10-212 m193 F08/0046 submitted - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0047 TITLE: public generic with same name as private type KEYWORDS: generic, accessibility DEFECT TYPE: Interpretation STATUS: Passed by WG5 letter ballot Consider the following code: module m implicit none private public :: foo ! A type, private :: foo ! B integer :: i = 0 end type type(foo), public :: o_foo interface foo module procedure foo_proc end interface contains function foo_proc(i) result(this) integer, intent(in) :: i type(foo) :: this this%i = i write(*, *) 'Hello' end function end module m program p use m implicit none o_foo = foo(2) end program QUESTION: Is this program standard conforming? ANSWER: No. DISCUSSION: The PUBLIC statement at A contradicts the PRIVATE attribute at B which violates the standard. EDITS to 10-007r1: None. SUBMITTED BY: R. Bader HISTORY: 10-213 m193 F08/0047 submitted 10-213r1 m193 Proposed answer - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1889 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0049 TITLE: ELEMENTAL functions with nonconstant type parameters KEYWORDS: ELEMENTAL, type parameter DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Interpretation F03/0119, which became part of the Fortran 2008 standard, added as constraint the requirement of an elemental function that its result variable "shall not have a type parameter that is defined by an expression that is not a constant expression". This makes a number of valid Fortran 95 programs invalid, for no apparent technical reason. Moreover, no text was added to clause 1 to indicate this incompatibility with Fortran 95. Here are several examples of non-problematic Fortran 95 elemental procedures that are apparently not valid Fortran 2008. MODULE ex1 INTEGER :: mylen CONTAINS ELEMENTAL CHARACTER(mylen) FUNCTION f(a) INTEGER,INTENT(IN) :: a f = REPEAT(CHAR(a),mylen) END FUNCTION END MODULE ELEMENTAL FUNCTION ex2(a,b) CHARACTER(*),INTENT(IN) :: a,b CHARACTER(LEN(a)+LEN(b)) :: ex2 ex2 = a//b END FUNCTION MODULE ex3 INTEGER,ALLOCATABLE :: x(:) CONTAINS PURE FUNCTION gcd(a) INTEGER :: gcd INTEGER,INTENT(IN) :: a(:) gcd = ... code to calculate this omitted ... END FUNCTION ELEMENTAL FUNCTION f(y,z) CHARACTER(*),INTENT(IN) :: y,z CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f f = ... END FUNCTION END MODULE Was this incompatibility with Fortran 95 an oversight? ANSWER: Yes, this was an oversight; requiring the type parameter values to be constant is unnecessarily onerous. An edit is supplied to correct this defect in the standard. EDITS to 10-007r1: [314:4-5] In 12.8.1, C1290, delete ", and shall not ... expression". {Delete erroneous constraint.} [314:5+] In 12.8.1, after C1290, insert new constraint: "C1290b In the that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry, and that specification inquiry shall not depend on a property that is deferred." SUBMITTED BY: Malcolm Cohen HISTORY: 10-231 m193 F08/0049 submitted - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 Passed as amended by WG5 letter ballot N1902 Edit amended during corrigendum construction ---------------------------------------------------------------------- NUMBER: F08/0050 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot REFERENCE: F95/0030 BACKGROUND (can be skipped without significant loss): F95/0030 asked to consider the following program unit. MODULE MOD INTERFACE INT MODULE PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END MODULE MOD In processing the references to "INT(1_4)" and "INT(1_2)" in F1, the processor needs to determine whether the references are to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to have determined the kind type parameter of the dummy argument J, of F2. In turn, that requires the processor to determine whether the reference to "INT(2_4)" is a reference to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to determine the kind type parameter of the dummy argument I, which requires it to determine that "INT(1_4)" in F1 was a reference to the intrinsic function INT. After all this is determined, the processor can determine that the reference to "INT(1_2)" in the declaration of B in F1 is a reference to the specification function F2. According to F95/7.1.6.1 [97-007r2:94:38-41], "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement." or F03/7.1.7 [04-007:30-33] "If an initialization 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 . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." or F08/7.1.12p2 [10-007r1:152:22-25] "If a constant 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 . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." According to F95/7.1.6.2 [97-007r2:96:27-37], "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a reference to an inquiry function for 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 . The prior specification may be to the left of the inquiry function reference in the same statement. If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F03/7.1.6 [126:9-14] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "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 . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F08/7.1.11p8+9 [10-007r1:151:3-12] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "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 . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." The rules regarding references to variables in specification expressions and initialization expressions require a strict left-to-right, top-to-bottom ordering between specification and inquiry. Specification functions appear to be unrestricted in this respect. Interp F95/0030 added the following new paragraph immediately before F03/Note 7.11 [04-007:127:33+] If an initialization expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the initialization expression. And the following new paragraph immediately before F03/Note 7.10 [04-007:126:19+]: If a specification expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the specification expression. QUESTION: The new paragraphs introduced into F03 by F95/0030, at [04-007:127:33+] and [04-007:126:19+], were changed in F08. The additional caveat "or submodule" was harmlessly introduced in four places by TR 19767. Paper 07-190r3 introduced "the of" in F08/7.1.12p3 [10-007r1:152:26-28] If a constant expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the constant expression. and F08/7.1.11p9 [10-007r1:151:13-15] If a specification expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the specification expression. Because of the changes introduced in F08 by 07-190r3, the paragraphs no longer address the question of interpretation request F95/0030, resulting in the example in the F95/0030 being standard conforming, contrary to the ANSWER to F95/0030. In light of F08 allowing generic interfaces to have specific procedures that are internal procedures, the following example illustrates a deeper problem than was illustrated in F95/0030: SUBROUTINE SUB INTERFACE INT PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END SUBROUTINE SUB Assuming that the processor supports integers with kind type parameters of 1, 2 and 4, was it the intent of the committee that this program unit example should be standard-conforming? ANSWER: No, it is clear from the answer to interpretation request F95/0030 that it is not the intent that the above program unit be standard conforming. The required complexity of implementation is not justified. The standard (as amended by corrigenda) briefly had prohibitions against it, but they were inadvertently removed during development of Fortran 2008. The edits below correct this. EDITS to 10-007r1: Replace F08/7.1.11p9 [10-007r1:151:13-15] by "A generic entity referenced in a specification expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the specification expression." Replace F08/7.1.12p3 [10-007r1:152:26-28] by "A generic entity referenced in a constant expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the constant expression." SUBMITTED BY: Van Snyder HISTORY: 11-101 m194 F08/0050 submitted - revision of F95/0030 11-101r1 m194 Passed by J3 meeting 11-207r1 m195 Passed by J3 letter ballot #23 11-156 N1889 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0051 TITLE: Pure procedure arguments with VALUE KEYWORDS: INTENT, PURE, VALUE DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider PURE FUNCTION F(X) REAL,VALUE :: X F = X**2 END FUNCTION This subprogram does not conform to the Fortran 2003 standard, but appears to conform to the Fortran 2008 standard, as constraints C1276 and C1277 (in Fortran 2008) have been modified to remove the previous requirement for an INTENT specification in the case of arguments that have the VALUE attribute. However, this is not mentioned as a change in the Introduction. Was this change inadvertent? ANSWER: No, this change was deliberate. An edit is provided to clarify. EDITS tp 10-007r1: [xvi] Introduction, paragraph 2, last bullet point: Before "An impure" Insert the new sentence "An argument to a pure procedure can have default INTENT if it has the VALUE attribute.". SUBMITTED BY: Malcolm Cohen HISTORY: 11-139 m194 F08/0051 submitted - passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 Passed by WG5 letter ballot N1902 Edit amended during corrigendum construction ---------------------------------------------------------------------- NUMBER: F08/0052 TITLE: Private type-bound procedures KEYWORDS: Type extension, type-bound procedures, accessibility DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot QUESTION: Consider the program MODULE example1_m1 TYPE t1 CONTAINS PROCEDURE,PRIVATE,NOPASS :: p ! (1). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE SUBROUTINE do_p(x) CLASS(t1) x CALL x%p END SUBROUTINE END MODULE MODULE example1_m2 USE example1_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: p => p2 ! (2). END TYPE CONTAINS SUBROUTINE p2(n) PRINT *,'p2',n END SUBROUTINE END MODULE PROGRAM example1 USE example1_m2 TYPE(t2),TARGET :: x CLASS(t1),POINTER :: y y => x CALL do_p(x) ! (3): I expect this to print 'p'. CALL do_p(y) ! (4): I expect this to print 'p'. CALL x%p(13) ! (5): I expect this to print 'p2 13'. END PROGRAM Question 1: does type-bound procedure overriding take account of accessibility; that is, is the type-bound procedure statement at (2) (a) a valid new type-bound procedure definition, or (b) an invalid overriding of the definition at (1)? Question 2: If the answer to question 1 was "yes" (a), and the example is standard-conforming, are the expectations at (3), (4), and (5) correct? For the next question, consider the following program fragment: MODULE example2_m1 TYPE,ABSTRACT :: t1 CONTAINS PROCEDURE(p),PRIVATE,DEFERRED,NOPASS :: hidden ! (6). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE END MODULE MODULE example2_m2 USE example2_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: hidden => exposed ! (7). END TYPE CONTAINS SUBROUTINE exposed PRINT *,'exposed' END SUBROUTINE END MODULE Question 3: If the answer to question 1 was "yes" (a), then the definition of type t2 would seem to be defective in that (7) must be defining a new type-bound procedure, and not overriding the type-bound procedure defined at (6), and that therefore t2 still has a deferred type-bound procedure. That would mean that an abstract type with a private deferred type-bound procedure could not be extended outside of the module in which it is defined: is that correct? ANSWER: Q1. Yes, type-bound procedure overriding does take account of accessibility. This means that the type-bound procedure statement at (2) is (a) a valid new type-bound procedure definition. Subclause 4.5.7.3p1 says [78:4-6] "If a specific type-bound procedure specified in a type definition has the same binding name as a type-bound procedure from the parent type then [it] overrides the [inherited one]." If the inherited type-bound procedure is private, and the extending type definition is not in the same module, then the inherited type-bound procedure is not accessible by that name, so the condition "has the same binding name" cannot be satisfied. This wording is very confusing, so an edit is supplied to clarify the intent. Q2. Yes, the comments at (3), (4), and (5) are accurate. Q3. Yes, an abstract type with a private deferred type-bound procedure cannot be extended outside the defining module, because it is otherwise impossible to override the private type-bound procedure. EDITS to 10-007r1: [78:4] In 4.5.7.3p1, change "as a type-bound" to "as an accessible type-bound". SUBMITTED BY: Malcolm Cohen HISTORY: 11-141 m194 F08/0052 submitted - passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 Passed by WG5 letter ballot ---------------------------------------------------------------------- NUMBER: F08/0053 TITLE: Restrictions on generic declarations, generic resolution KEYWORDS: generic declarations, generic resolution DEFECT TYPE: Erratum STATUS: Passed by WG5 letter ballot BACKGROUND: There is a specification in 12.4.3.4 [283] of the properties that cause two dummy arguments to be distinguishable. C1214 [286] specifies that two procedures within the scope of a shall be distinguishable. There is no specification of the properties that cause two procedures to be distinguishable. 12.4.3.4.5p5 [286:38] specifies that a "generic invocation applies to...." QUESTIONS: (1) Shouldn't the requirement in C1214 be that the \cf{dtv} arguments are distinguishable? (2) Shouldn't 12.4.3.4.5p5 specify that a "generic nvocation is consistent with...?" ANSWERS: (1) Yes. (2) Yes. Edits are provided to clarify these two issues. EDITS to 10-007r1: [286:12-13 C1214] Replace "two ... identifier" by "if two procedures have the same generic identifier, their \cf{dtv} arguments (9.6.4.8.3)". [286:38 12.4.3.4.5p5] Replace "applies to" by "is consistent with". SUBMITTED BY: Van Snyder HISTORY: 11-136r2 m194 Submitted F08/0053 in section 2 11-136r1 m194 Passed section 1 - Editorial edits 11-136r3 m194 Section 2 passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 Passed as amended by WG5 letter ballot ---------------------------------------------------------------------- --------------080103010407040609000604--