10-254 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #22 - due 19-Nov-2010 Date: 2010 October 14 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 22 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #193. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0030 IEEE divide by zero --- --- F03/0048 Control edit descriptors in UDDTIO --- --- F03/0085 Finalizing targets of pointer or allocatable actual arguments --- --- F03/0091 Array components cannot depend on length type parameters --- --- F03/0096 Can a read statement change the unit value? --- --- F03/0105 SIZE= specifier and UDDTIO --- --- F03/0110 Error in field width for special cases of signed INFINITY output --- --- F03/0121 Precise FP semantics of the REAL intrinsic --- --- F03/0123 Implicit typing in derived types --- --- F03/0124 definition is poorly defined --- --- F03/0128 Subobjects in namelist output --- --- F08/0006 generic resolution with banned argument combinations --- --- F08/0040 MOVE_ALLOC for coarrays --- --- F08/0041 Segment ordering rules --- --- F08/0042 SOURCE= questions --- --- F08/0043 Executing a type-bound procedure on a coindexed object --- --- F08/0044 Resolving the type of a coarray or coindexed object --- --- F08/0045 constraints on entities of type LOCK_TYPE --- --- F08/0046 VALUE attribute restrictions --- --- F08/0047 public generic with same name as private type --- --- F08/0048 Sequence association for coarrays --- --- F08-0049 ELEMENTAL functions with nonconstant type parameters The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Friday, 19-Nov-2010, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS: Page and line numbers refer to 10-007. [403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW), Replace with "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the result of the operation or conversion, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. It occurs in an intrinsic real exponentiation as determined by the processor. It occurs in a complex operation, or conversion by the intrinsic function CMPLX, if it is caused by the calculation of the real or imaginary part of the result." [403:10-11] Replace with "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the result of the division, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. It is processor-dependent whether it occurs in a real exponentiation with a negative exponent. It occurs in a complex division if it is caused by the calculation of the real or imaginary part of the result." [462:24+] Insert new bullet points "- the conditions under which IEEE_OVERFLOW is raised in a calculation involving non-IEC 60559:1989 floating-point data; - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are raised in a floating-point exponentiation operation; - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a calculation involving non-IEC 60559:1989 floating-point data;" SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 F03/0030 submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 10-nnn m193 Revised answer ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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 [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 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 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 and remove the phrases "record position" and "record positioning" from the standard. EDITS: In 10-007 [227:15] In section 9.6.4.8, 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, 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.2, first paragraph, delete "record positioning" SUBMITTED BY: Rob James HISTORY: 05-139 m171 F03/0048 submitted 05-139r1 m171 Passed by J3 meeting 05-167/170 m172 Failed J3 letter ballot #11 06-366r2 m178 Passed by J3 meeting 07-250r1/272 m181 Failed J3 letter ballot #13 10-241 m193 Draft answer for F2008 10-241r1 m193 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0085 TITLE: Finalizing targets of pointer or allocatable actual arguments KEYWORDS: Finalization, pointer actual argument, allocatable actual argument DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: In 10-007 Replace the eighth paragraph of 4.5.6.3 [76:30-31] 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 ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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: None SUBMITTED BY: Van Snyder HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen) 10-243 m193 Draft answer for F2008 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is it allowed to change the value of a variable which supplies the unit number to an read statement? 10-007 [243:3-5] says the value of any input/output specifier shall not depend on any input-item. UNIT= is a specifier in a READ statement. Note 9.40 on page 221 gives the example READ(N) N, X(N) and discusses how the changes to N work. ANSWER: Yes, the example was intended to be allowed as long as N is not an internal unit. Edits will limit the restriction to "output items" n the specifier list and the Format. EDITS: In 10-007 In 9.12, paragraph 5, [243:3-4] Delete "on any , , or", Making that sentence read: "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." [243:5] Append new sentence to paragraph "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier shall not depend on any or ." SUBMITTED BY: Dick Hendrickson HISTORY: 07-266 m181 F03/0096 submitted 07-266r1 m181 Draft answer - withdrawn, no reason, no vote 10-246 m193 Draft answer for F2008 10-246r1 m193 Revised edit ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Interpretation STATUS: J3 consideration in progress DISCUSSION: 9.5.1.14 [191:21-26] 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 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: 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 ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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 10: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: None SUBMITTED BY: Michael Ingrassia HISTORY: 07-341 m182 F03/0110 submitted 10-248 m193 Draft answer for F2008 ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: J3 consideration in progress QUESTION: Must the intrinsic function REAL with KIND parameter wp return a value that is a REAL (KIND=wp) floating point number? RATIONALE FOR THE QUESTION: Computer hardware may use a wider floating-point format for registers than for memory; e.g., 80 bits for registers and 64 bits for memory for the case of standard double precision floating point numbers. Some algorithms require a high level of control over floating point semantics. If the intrinsic function REAL with KIND parameter wp is guaranteed to return a REAL (KIND=wp) result then a programmer can use this to force intermediate results into main memory format, never mind that the optimizing compiler may have placed the intermediate in a register. I am interested in a J3 interpretation of this matter, especially a loud and clear affirmative interpretation, because it appears that some present Fortran compilers optimize away my explicit use of the REAL intrinsic. The context is code for compensated summation (Kahan summation). I appreciate that parentheses are inviolable courtesy of the Fortran standard, but in order to have code that cannot be broken by an optimizing compiler I seem to need also a language mechanism to force intermediate results into main memory format. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANSWER: Yes, the result of the intrinsic function REAL with KIND argument wp returns a value that is of type REAL(KIND=wp). However, the description of REAL says that in this case "the result is equal to a processor-dependent approximation to A". Furthermore, if it is used within an expression involving intrinsic operations, "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." and "mathematically equivalent expressions of numeric type may produce different computational results", which means that it is unlikely to serve your purpose. Intermediate results can be rounded to storage format by using assignment to a VOLATILE variable. EDIT: None. HISTORY: 08-208r1 m185 F03/0121 submitted 10-240 m193 Draft answer for F2008 - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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-007: [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 ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: definition is poorly defined KEYWORDS: definition DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the program: PROGRAM MAIN 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 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. ANSWER: 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". EDITS: [455:14+] In 16.6.6 item (1), insert new sub-list item "(c) When all components of a structure of a numeric sequence type or character sequence type become defined as a result of partially associated objects becoming defined, an associated variable of a different type does not 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 ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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. EDIT: 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 ---------------------------------------------------------------------- NUMBER: F08/0006 TITLE: Generic resolution, intrinsic procedures, and host association KEYWORDS: intrinsic, generic, host association DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: The specifications of some intrinsic functions and subroutines explicitly ban certain combinations of arguments, even though those combinations are included in the title and the argument portion of the specification of the function or subroutine. Examples include CMPLX and RANDOM_SEED. 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-007: None. SUBMITTED BY: Robert Corbett HISTORY: 10-153 m192 F08/0006 submitted 10-153r1 m192 Draft answer 10-153r2 m192 Revised answer - Passed by J3 meeting 10-202 m192 Amended by J3 letter ballot 10-199; failed J3 letter ballot 10-199 10-236 m193 Revised answer for F2008 10-236r1 m193 Revised example - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: No. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray; therefore MOVE_ALLOC would need to be an image control statement for consistency with the DEALLOCATE statement. An edit is supplied to clarify this. EDIT: In 10-007 In 13.7.118 MOVE_ALLOC (FROM, TO), paragraph 3: [372:18] After "It shall be allocatable." add "It shall not be a coarray." [372:19] After "It shall be allocatable." add "It shall not be a coarray." SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0041 TITLE: Segment ordering rules KEYWORDS: segment, allocation DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) Was it intended to allow the allocation of a variable that is not a subobject of a coarray to be unordered with respect to its definition by another image through a pointer component of a coarray? For example, PROGRAM example1 TYPE t1 REAL,ALLOCATABLE :: c(:) END TYPE TYPE t2 TYPE(t2),POINTER :: p END TYPE TYPE(t1),TARGET :: x TYPE(t2) :: y[*] y%p => x ! y[n]%p => x[n] for all n. SYNC ALL IF (THIS_IMAGE()==1) THEN ALLOCATE(x%c(1000)) ! Allocates x[1]%c. ELSE y[1]%p%c(THIS_IMAGE()) = 999 ! Defines some part of x[1]%c. END IF END PROGRAM (2) If a variable is already defined (initially or by some segment that precedes all other segments in this question), may one image reference it while another image causes it to become undefined in unordered segments? For example, is PROGRAM example2 REAL :: x(100)[*] x = 1 SYNC ALL IF (THIS_IMAGE()==1) THEN PRINT *,SUM(x) ELSE CALL destroy(x) END IF CONTAINS SUBROUTINE destroy(x) REAL,INTENT(OUT) :: x(:) END SUBROUTINE END PROGRAM standard-conforming? This does not appear to violate any of the segment ordering requirements in 8.5.2 because it is not defined in any unordered segment (so bullet 1 does not apply), there is no allocation or pointer association status (so bullet 2 does not apply), and there is no dummy argument being defined (so bullet 3 does not apply). ANSWER: (1) No, this example violates the requirement of the first bullet in paragraph 3 of 8.5.2, which says: "if a variable is defined on an image in a segment, it shall not be referenced, defined, or become undefined in a segment on another image unless the segments are ordered". x[1]%c is defined in segment 2 by images 2-N, but is made undefined on image 1 (allocation makes a variable undefined except when default initialization occurs). (2) No, this example was not intended to be standard-conforming. An edit is supplied to clarify the intent. EDITS to 10-007: [189:14] In 8.5.2 paragraph 3, first bullet point, After "if a variable is defined" Insert "or becomes undefined" (before "on an image in a segment"). {Forbid uncoordinated undefinings of variables.} SUBMITTED BY: John Reid HISTORY: 10-201 m193 F08/0041 submitted 10-201r1 m193 Revised - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0042 TITLE: SOURCE= questions KEYWORDS: ALLOCATE, SOURCE= DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the program PROGRAM example1 REAL,ALLOCATABLE :: x(:),y(:) ALLOCATE(x(10),y(10),SOURCE=3.14159265) PRINT *,x,y END This program does not conform to Fortran 2003 due to constraint C631 which stated "If SOURCE= appears, ... shall contain only one ...". The corresponding constraint in Fortran 2008, C638, is missing this requirement, so apparently the program is now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention this as a new feature. Furthermore, 6.7.1.1 paragraph 4 begins "If is a coarray, shall not have a dynamic type of ..." which implies that there is only one for a (at least when the is a coarray). Similarly, the wording of constraint C639 implies a one-to-one correspondence between and . Q1. Is the omission of the single allocation requirement of Fortran 2003 an oversight? (i.e. is example1 non-conforming?). Also, consider the program PROGRAM example2 REAL,ALLOCATABLE :: x[:] ALLOCATE(x) x = 3 END The ALLOCATE statement appears not to conform to Fortran 2008 because of 6.7.1.1 paragraph 4; since does not appear, it cannot satisfy any condition about its dynamic type. Q2. Is an ALLOCATE statement for a coarray required to have SOURCE=? (i.e. is example2 non-conforming?). Also, if multiple allocations with SOURCE= are permitted, consider the program PROGRAM example3 INTEGER,ALLOCATABLE :: x,y ALLOCATE(x,y,SOURCE=f()) PRINT *,x,y CONTAINS INTEGER FUNCTION f() INTEGER,SAVE :: n = 1 f = n n = n + 1 END FUNCTION END PROGRAM The execution semantics of SOURCE= in 6.7.1.2 paragraph 7 do not state whether the is evaluated once per statement or once per allocation. If the processor evaluates per statement execution, something like " 1 1" will be printed, but if it evaluates it per allocation, something like " 1 2" could be printed. Q3. How many times may be evaluated in an ALLOCATE statement with multiple allocations? Also, consider the program PROGRAM example4 REAL,ALLOCATABLE :: x(:) ALLOCATE(x,SOURCE=[0.5,1.5]) PRINT *,x END PROGRAM The Introduction implies that this program should be standard- conforming, but it violates constraint C633, which begins "(R631) If is an array either shall appear or shall appear ..." The requirements of C633 are not satisfied because R631 is and does not appear in R631. Q4. Is example4 intended to be standard-conforming? ANSWER: The answer to question 1 is No. This feature was deliberately added to the Fortran 2008 standard. Edits are supplied to correct its exposition. The answer to question 2 is No. An edit is supplied to correct paragraph 4 of 6.7.1.1. The answer to question 3 is once. An edit is supplied to clarify paragraph 7 of 6.7.1.2. The answer to question 4 is Yes. An edit is supplied to correct constraint C633. EDITS: {to 10-007} [xiii] Introduction, bullet "Data usage and computation", Before "MOLD=" Insert "Multiple allocations are permitted in a single ALLOCATE statement with SOURCE=." {(Q1) Add new feature to the feature list.} [126:31-33] Replace C633 entirely with the constraints "C633 (R626) If an is an array, either shall appear in its or shall appear in the ALLOCATE statement. C633a (R631) If is scalar, shall not appear." {(Q4) Fix broken constraint.} [127:5] Constraint C639, replace entirely with "C639 (R626) If appears, the kind type parameters of each shall have the same values as the corresponding type parameters of ." {(Q1) Fix singular implication. Avoid introducing any implication that each has the same set of kind type parameters or that any has the same set of kind type parameters as the - the relationship is a subset.} [127:18] 6.7.1.1 paragraph 4, replace entirely with "If has a dynamic type of C_PTR, C_FUNPTR, LOCK_TYPE, or has a subcomponent whose dynamic type is LOCK_TYPE, no in that statement is permitted to be a coarray." {(Q2) Fix implied requirement of SOURCE= appearance for coarrays.} [128:26] 6.7.1.2 paragraph 7, append new sentence "The is evaluated exactly once for each execution of an ALLOCATE statement." {(Q3) Clarify number of evaluations.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-211 m193 F08/0042 submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: module m type :: foo integer :: i = 0 contains procedure, pass :: op end type contains subroutine op(this, i) class(foo) :: this this%i = i end subroutine end module m program p use m class(foo), allocatable :: o_foo[:] integer :: me allocate(foo :: o_foo[*]) me = this_image() if (me == 1) then call o_foo[2]%op(1) ! Type-bound call. end if sync all if (me == 2) write(*,*) o_foo%i end program p This program is not standard-conforming, as it violates one of the requirements of 12.5.2.4p2, viz "If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic." However, if the type-bound call were replaced by SELECT TYPE(o_foo) TYPE IS (foo) CALL o_foo[2]%op(1) END SELECT appears to be standard-conforming. The example program appears to be harmless, so the requirement appears to be unnecessary. It is conjectured that the requirement is misworded and should instead be "If the actual argument is a polymorphic subobject of a coindexed object, the dummy argument shall not be polymorphic."? Q1. Is this requirement intentional? Furthermore, constraint C1229 says of a that is the object for a type-bound procedure reference, that it "shall not be a polymorphic subobject of a coindexed object"; however, C617 already prohibits any from being a polymorphic subobject of a coindexed object except as the subject of a type parameter inquiry or as the actual argument in an intrinsic inquiry function reference, so C1229 appears to be completely redundant. Q2. Is constraint C1229 redundant? ANSWER: A1. The requirement is intentional, and needed to avoid a potential type enquiry of an object on another image. Consider TYPE,EXTENDS(foo) :: badfoo CLASS(*),ALLOCATABLE :: badcomponent(:) END TYPE If the dynamic type of object "o_foo" were "badfoo", the call to the type-bound procedure cannot be resolved without enquiring the type of o_foo%badcomponent on image 2 (because it needs to know how much to copy, and how); this type is not necessarily the same type as that of o_foo%badcomponent on image 1. A2. Yes, constraint C1229 is redundant. An edit is supplied to remove this unnecessary redundancy. EDITS to 10-007: [290:1] Delete C1229. SUBMITTED BY: R. Bader HISTORY: 10-208 m193 F08/0043 submitted 10-208r1 m193 Revised - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0044 TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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: None SUBMITTED BY: R. Bader HISTORY: 10-209 m193 F08/0044 submitted 10-209r1 m193 Proposed answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0045 TITLE: constraints on entities of type LOCK_TYPE KEYWORDS: lock, polymorphism DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: Program example Use Iso_Fortran_Env, Only:lock_type type :: m class(*), allocatable :: lock end type type(m) :: om[*] allocate(lock_type :: om%lock) call inner(om) ! Problem call. Contains Subroutine inner(omm) Type(m),Intent(Out) :: omm Print *,Allocated(omm%lock) End Subroutine End Program Constraint C1304 attempts to prohibit a variable with a LOCK_TYPE subobject from appearing in a variable definition context, such as the call to inner, but the dynamic type of om%lock cannot be determined statically. Is this program standard-conforming? ANSWER: The example was not intended to be standard-conforming. An ALLOCATE statement with a should not have been permitted to add components of type LOCK_TYPE; an edit is supplied to correct this error. EDITS to 10-007: [127:7] In C641, After "C_PTR" replace "or" by ","; After "C_FUNPTR" insert ", LOCK_TYPE (13.8.2.16), or a type with a direct component of type LOCK_TYPE that is not a direct component of the declared type of any ,". {Fix condition to prohibit LOCK_TYPE and any type with a LOCK_TYPE direct component. Note that we only want to prohibit "new" lock_type components from appearing in the , we don't want to forbid ones that are already in the declared type.} [127:8] After "LOCK_TYPE" delete "(13.8.2.16)". {Reference now appears one line earlier, so is unnecessary.} SUBMITTED BY: R. Bader HISTORY: 10-210 m193 F08/0045 submitted 10-210r1 m193 Revised - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0046 TITLE: VALUE attribute restrictions KEYWORDS: VALUE DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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, 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-007} [xiii] Introduction, bullet "Data declaration", append "The VALUE attribute is permitted for an array, and for an object with a nonconstant length type parameter." SUBMITTED BY: Malcolm Cohen HISTORY: 10-212 m193 F08/0046 submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0047 TITLE: public generic with same name as private type KEYWORDS: generic, accessibility DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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. SUBMITTED BY: R. Bader HISTORY: 10-213 m193 F08/0047 submitted 10-213r1 m193 Proposed answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Was the text in 12.5.2.8: "If the dummy argument is an array coarray that has the CONTIGUOUS attribute or is not of assumed shape, the corresponding actual argument shall be simply contiguous." intended to disallow sequence association for coarrays, as illustrated by the example interface subroutine sub (x) real x(10)[*] end subroutine end interface ... real :: x(100)[*] ... call sub (x(10)) 12.5.2.4 paragraph 13 seems to imply that this ought to be valid. ANSWER: Yes, passing an array element to a dummy coarray was not intended to use sequence association. There is no contradiction with 12.5.2.4 paragraph 13 (which as is simply doesn't apply), but it is confusing so an edit is supplied to clarify it. EDIT: [294:33] Append new sentence to 12.5.2.4 paragraph 13, "If the dummy argument is a coarray that is an array, the actual argument shall be an array." SUBMITTED BY: John Reid HISTORY: 10-226 m193 F08/0048 submitted 10-226r1 m193 Revised answer 10-226r2 m193 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0049 TITLE: ELEMENTAL functions with nonconstant type parameters KEYWORDS: ELEMENTAL, type parameter DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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,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-007} [314:6-7] 12.8.1, C1290, delete ", and shall not ... expression". {Delete erroneous constraint.} [314:7+] Insert new constraint "C1290a 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 enquiry shall not depend on a property that is deferred." SUBMITTED BY: Malcolm Cohen HISTORY: 10-231 m193 F08/0049 submitted - Passed by J3 meeting ----------------------------------------------------------------------