ISO/IEC JTC1/SC22/WG5 N2121 Interpretations for Fortran 2008 Corrigenda 1, 2, 3, and 4 Stan Whitlock December 2016 This document contains the final form of the defect reports that led to Fortran 2008 Corrigenda 1, 2, 3, and 4 and responses to them. ------------------------------------------------------------------------ Corrigendum C: 1 J3/021 = N1907 == F08 Corrigendum 1 interps 2 J3/024 = N1959 == F08 Corrigendum 2 interps 3 J3/026 = N2004 == F08 Corrigendum 3 interps 1-3 J3/020 = N2006 == F08 Corrigenda 1, 2, and 3 interps 4 J3/none = N2098 == F08 Corrigendum 4 interps Defect Type T: E Erratum I Interpretation C T number title - - ------ ----- 2 I F03/0017 Dummy procedure pointers and PRESENT 2 C F03/0018 Multiple identical specific procedures in type-bound generic interfaces 2 E F03/0019 Multiple identical specific procedures in generic interface blocks 2 E F03/0021 What kind of token is a stop code? 3 E F03/0030 IEEE divide by zero 4 I F03/0042 IEEE funny values and Standard real generic intrinsic procedures 2 C F03/0046 Unlimited polymorphic pointers in common blocks 3 I F03/0047 Polymorphic arguments to intrinsic procedures 1 E F03/0048 Control edit descriptors in UDDTIO 3 E F03/0053 The BIND attribute for C_PTR and C_FUNPTR 3 E F03/0064 Recursive declaration of procedure interfaces 2 I F03/0065 Relational equivalence 1 E F03/0085 Finalizing targets of pointer or allocatable 1 I F03/0091 Array components cannot depend on length type parameters 2 E F03/0096 Can a read statement change the unit value? 3 E F03/0100 Error in field width for special cases of signed INFINITY output 2 E F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type 1 I F03/0105 SIZE= specifier and UDDTIO 1 I F03/0110 Restoring dropped restriction on ENTRY 2 I F03/0116 indistinguishable specifics for a generic interface with use association 2 E F03/0118 Are lower bounds of assumed-shape arrays assumed? 2 E F03/0120 When are parameterized sequence types the same type? 1 E F03/0123 Implicit typing in derived types 1 E F03/0124 definition is poorly defined 1 I F03/0128 Subobjects in namelist output 3 E F03/0139 Functions returning procedure pointers -------- 1 E F08/0001 Generic resolution with pointer dummy arguments 1 E F08/0002 Are assumed- or deferred-shape objects allowed in namelist? 1 E F08/0003 Is a disassociated pointer allowed as an actual DIM argument? 2 E F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? 1 E F08/0005 optional arguments and ASSOCIATED - subsumed by F08/0004 1 I F08/0006 generic resolution with banned argument combinations 1 I F08/0007 Can zero have more than one bit sequence representation? 2 I F08/0008 IEEE exceptions for intrinsic functions 1 I F08/0009 Is ABS ever required to be the optional IEC 60559 abs? 1 E F08/0010 deallocating objects that are associated with other objects 1 E F08/0011 How many times are constructed values finalized? 1 E F08/0012 Are constants finalized? - subsumed by F08/0011 1 E F08/0013 How does finalization interact with allocatable assignment? 1 E F08/0014 Finalizing assignment to vector-subscripted object 1 E F08/0015 IMPLICIT 1 E F08/0016 Can a vector-subscripted argument become undefined? 1 E F08/0017 Elemental subroutine restrictions 1 E F08/0018 Impure elemental restrictions 1 E F08/0019 Transformational Bessel functions 1 E F08/0020 FINDLOC and logical arguments 1 E F08/0021 STORAGE_SIZE and unlimited polymorphic 1 E F08/0022 DO CONCURRENT and file i/o 1 E F08/0023 DO CONCURRENT and POINTER 1 E F08/0024 Dummy arguments of impure elemental procedures 1 E F08/0025 DO CONCURRENT and ALLOCATABLE 1 E F08/0026 DO CONCURRENT and output interleaving 1 E F08/0027 ATOMIC_REF example 1 E F08/0028 Does a procedure reference cause loop termination? 1 E F08/0030 Unlimited format repeat effects 2 E F08/0031 PURE INTENT(OUT) finalization 2 E F08/0032 PURE FUNCTION result finalization 1 E F08/0033 PURE polymorphic finalization 1 E F08/0034 ELEMENTAL INTENT(OUT) finalization 1 I F08/0035 Maximum value for SHIFT argument to SHIFTL and SHIFTR 1 E F08/0036 NORM2 example in Annex C 1 E F08/0037 PROCEDURE POINTER vs PROTECTED 2 C F08/0038 Are pointless restrictions on DIM arguments intended? 1 E F08/0039 Many-one vector subscript usage 2 E F08/0040 MOVE_ALLOC for coarrays 2 E F08/0042 SOURCE= questions 2 E F08/0043 Executing a type-bound procedure on a coindexed object 1 I F08/0044 Resolving the type of a coarray or coindexed object 1 E F08/0046 VALUE attribute restrictions 1 I F08/0047 public generic with same name as private type 2 E F08/0048 Sequence association for coarrays 1 E F08/0049 ELEMENTAL functions with nonconstant type parameters 1 E F08/0050 Ordering requirements on definition of specification functions 1 E F08/0051 Pure procedure arguments with VALUE 1 E F08/0052 Private type-bound procedures 1 E F08/0053 Restrictions on generic declarations, generic resolution 2 E F08/0054 Requirements for needing an explicit interface 2 E F08/0055 G editing for reals 2 E F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE= 2 E F08/0057 Interoperability with empty types 2 E F08/0058 ENTRY point RESULT variable 2 E F08/0059 Auto-targetting requirements 2 E F08/0060 Procedure pointer assignment with an EXTERNAL target 2 E F08/0061 Description of the CONTIGUOUS attribute misworded? 2 C F08/0062 Mixing default initialization with DATA initialization 2 I F08/0063 G editing to a narrow output field 2 E F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE 2 E F08/0065 Should certain procedures in intrinsic modules be pure? 2 E F08/0066 Are certain expressions with pointer initialization constant? 2 E F08/0067 Passing arrays of extended type objects 2 E F08/0068 Pointer association and extended type arrays 2 E F08/0069 Which part of an effective argument becomes undefined? 2 E F08/0070 Finalization of INTENT(OUT) arguments 3 E F08/0071 Vector subscript target 2 E F08/0072 Final subroutines with corank 2 E F08/0073 Polymorphic auto-targetting 2 E F08/0074 Implicit type in BLOCK construct 3 E F08/0075 Pointer function reference as variable in assignment 3 E F08/0076 Pointer function reference in READ - Subsumed by F08/0075 2 E F08/0077 Function references as variables in DATA statements 2 E F08/0078 Are the IEEE values +0 and -0 distinguished 2 E F08/0079 NAMELIST and type specification 2 E F08/0080 Array constructors with polymorphic values 2 E F08/0081 Deallocation error handling 2 E F08/0082 Generic identifier and dtv arguments 3 E F08/0083 Type parameter default expressions allow circular dependence 3 E F08/0084 Pointer arguments to PURE functions 3 E F08/0085 Problems with PARAMETERs 3 E F08/0086 Implied-shape and separate PARAMETER statement 3 E F08/0087 Mixed-kind character assignment 3 E F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? 3 E F08/0090 What restrictions apply to initialization and PARAMETER? 3 E F08/0091 Derived type with no components 3 E F08/0092 Derived type parameter requirements 3 E F08/0093 Process exit status and error termination 3 E F08/0094 Procedure statement and double colon 3 E F08/0095 Is PRESENT allowed in specification and constant expressions 3 E F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? 3 E F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? 3 E F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? 4 I F08/0099 VOLATILE in specification expressions 4 E F08/0100 IMPORT statement and prior explicit declaration 4 E F08/0101 NAMELIST and multiple occurrences of a variable 4 E F08/0102 MERGE and polymorphism 4 E F08/0103 Pointers to internal procedures with different host instances 4 E F08/0104 IEEE Inquiry Functions 4 I F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? 4 E F08/0106 MOVE_ALLOC for a remote array 4 I F08/0108 ultimate components and coarrays 4 E F08/0109 LOCK_TYPE and unlimited polymorphic 4 E F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE 4 E F08/0113 Specifiers in image control statements 4 E F08/0115 ASYNCHRONOUS and argument passing 4 E F08/0116 Interoperable procedures 4 E F08/0117 TARGET and coindexed arguments 4 E F08/0118 Subobject of variable in variable definition context 4 E F08/0119 Branching to END BLOCK and END CRITICAL 4 E F08/0120 Is the name of a procedure pointer a local identifier? 4 E F08/0121 Add to introduction defined operations in specification exprs 4 E F08/0122 Types with coarray components 4 E F08/0123 SPACING intrinsic 4 E F08/0124 Coindexed object with polymorphic subcomponent 4 E F08/0126 Can cobounds be referenced in the same type declaration? 4 E F08/0127 May an initial line begin with a semicolon? 4 E F08/0129 Is CLASS(type) required to refer to a prior type definition? 4 E F08/0130 Does coarray allocation sync even with stopped images? 4 E F08/0131 Are the changes to C_LOC in the 2010 revision intentional? 4 E F08/0132 Can a procedure pointer be declared with an interface block? 4 E F08/0133 Is unallocated actual associated with nonallocatable dummy OK? 4 E F08/0134 in an image control statement 4 E F08/0135 Vector subscripted actual makes VALUE dummy undefinable? 4 E F08/0136 Argument correspondence with VALUE and ASYNCHRONOUS 4 E F08/0137 Result of TRANSFER when MOLD is an array with element size zero 4 C F08/0138 Type extension in submodules 4 E F08/0139 Is the name of an external procedure that has a binding label a local identifier? 4 E F08/0140 Assign to deferred-length coindexed character variable 4 E F08/0141 Can a statement function have a variable-length PDT result? 4 E F08/0142 Is useless module extension permitted? 4 E F08/0143 May a pure procedure have an INTENT(OUT) polymorphic component? 4 E F08/0144 Is nonadvancing I/O allowed during execution of DO CONCURRENT? 4 E F08/0145 Can initial-data-target be coindexed? 4 E F08/0147 Is generic resolution of elemental assignment done at runtime? 4 E F08/0148 Pointer subobject in structure constructor in pure procedure ---------------------------------------------------------------------- NUMBER: F03/0017 TITLE: Dummy procedure pointers and PRESENT KEYWORDS: Dummy argument, procedure pointer, PRESENT DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 2 QUESTION: Does the following program conform to the Fortran standard? procedure(real), pointer :: F => null() call s ( f ) contains subroutine S ( F ) procedure(real), optional, pointer :: F print *, present(f) end subroutine S end In the Fortran 2003 standard (ISO/IEC 1539-1:2004), the second paragraph of 12.4.1.3 requires that if the dummy argument does not have the POINTER attribute and the actual argument does, the actual argument shall be associated. It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute. ANSWER: The program is standard-conforming. The Fortran 2008 standard states "Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a nonoptional nonpointer dummy argument shall be pointer associated with a target." (12.5.2.3 paragraph 1). Since PRESENT is an intrinsic inquiry function, there is therefore no requirement on its actual argument that if it is a pointer it shall be associated. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 04-402 m170 F03/0017 submitted 04-402r2 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-213 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic KEYWORDS: Type-bound generic DEFECT TYPE: Clarification STATUS: No edits in F2008 Corrigendum 2 QUESTION: Q1. Does the following program unit conform to the Fortran standard? module M1 type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T type X real q contains procedure, pass(b) :: MyAdd_x => myadd generic :: operator(+) => myAdd_x end type X contains integer function MyAdd ( A, B ) class(t), intent(in) :: A class(x), intent(in) :: B myadd = a%x + b%q end function MyAdd end module Q2. Does the following program unit conform to the Fortran standard? module M2 interface operator(+) procedure MyAdd end interface type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T contains integer function MyAdd ( A, B ) class(t), intent(in) :: A real, intent(in) :: B myadd = a%x + b end function MyAdd end module Q3. If the interface block and type definition are exchanged in question 2, does the program unit conform to the Fortran standard? ANSWER: A1. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific bindings, one to myadd_t the other to myadd_x. A2. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific procedures, one being the module procedure myadd the other being the type-bound procedure myadd_t. A3. The ordering of the interface block and the type definition is immaterial. EDITS to 10-007r1: None SUBMITTED BY: Van Snyder HISTORY: 04-405 m170 F03/0018 submitted 04-405r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-214 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Module m12 Interface g1 Subroutine s End End Interface Interface g2 Procedure s End Interface End Module Program p12 Use m12 Interface g1 ! (1) Procedure s End Interface Interface g2 ! (2) Procedure s End Interface Call g1 Call g2 End Program It is clear that the interface block marked (2) is not conforming, since it violates C1209 which says "A procedure-name shall not specify a procedure that is specified previously in any procedure-stmt in any accessible interface with the same generic identifier." However, it is not clear whether the interface block marked (1) is conforming, since s was specified previously by an interface-body not a procedure-stmt, even though both (1) and (2) attempt to do the same thing, viz create a generic interface with a duplicate specific. An even more obscure example is Module mx12 Interface g3 Subroutine s End End Interface Private s End Program px12 Use mx12 Interface g3 Subroutine s End End Interface Call g3 End Program Here there is clearly no violation of C1209 but it is not obvious whether the ambiguity rules are applied or not. ANSWER: These examples were not intended to be conforming. An edit is supplied to clarify. EDITS to 10-007r1: [281:11-12] Replace C1209 entirely by "C1209 (R1201) An in a generic interface block shall not specify a procedure that is specified previously in any accessible interface with the same generic identifier." SUBMITTED BY: Van Snyder HISTORY: 04-406 m170 F03/0019 submitted 04-406r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-221 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: The , when it is a string of s, does not appear to be specified by the standard to be any particular kind of token. Or indeed whether it is one token per or one per . The answer to these questions determines whether blanks are allowed, disallowed, or optional, in the middle of a STOP statement in free form. Consider the following statements: (1) STOP 123 (2) STOP123 (3) STOP 1 2 3 Which, if any, of these statements are standard-conforming? ANSWER: Fortran 2008 has revised the syntax of the STOP statement. The is now a scalar integer constant expression or a scalar default character constant expression. Therefore only statement (1) is standard-conforming in free form. EDITS to 10-007r1: None. SUBMITTED BY: Malcolm Cohen HISTORY: 04-416 m170 F03/0021 submitted - Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-212r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 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 to 10-007r1: [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 operands of the operation or conversion, and as determined by the processor otherwise. 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] Clause 14.3, first paragraph, second bullet (IEEE_DIVIDE_BY_ZERO), 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 operands of the division, and as determined by the processor otherwise. 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+] Clause A.2, after the fifth bullet from the end of the clause "the extent to which a processor supports IEEE arithmetic (14)", 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-238r1 m193 Revised answer - Passed 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 m196 Failed WG5 ballot 1 N1876 13-246 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F03/0042 TITLE: IEEE funny values and Standard real generic intrinsic procedures KEYWORDS: IEEE-754, real math library DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: Is an infinite result from an infinite argument to a real math function exceptional (raises an exception)? Is a NaN result from a NaN argument to a real math function exceptional (raises an exception)? What are the results (value and exceptions) for the following (section 13.7.*) real math library functions [suggested results for most are included; no exception happens unless specified]: ABS(-0.0) returns +0.0 ABS(+/-infinity) returns +infinity ABS(NaN) returns a NaN ACOS(x), where |x|>1, returns a NaN and raises invalid ACOS(NaN) returns a NaN AINT(-0.0) returns -0.0 AINT(NaN) returns a NaN AINT(+infinity) returns +infinity AINT(-infinity) returns -infinity ANINT(-0.0) returns -0.0 ANINT(NaN) returns a NaN ANINT(+infinity) returns +infinity ANINT(-infinity) returns -infinity ASIN(x), where |x|>1, returns a NaN and raises invalid ASIN(NaN) returns a NaN ATAN(-0.0) returns -0.0 ATAN(+infinity) returns +pi/2 ATAN(-infinity) returns -pi/2 ATAN(NaN) returns a NaN ATAN2(NaN,x) returns a NaN ATAN2(y,NaN) returns a NaN ATAN2(+/-0.0, -0.0) returns +/-pi (and not raise invalid) ATAN2(+/-0.0, +0.0) returns +/-0.0 (and not raise invalid) ATAN2(+/-0.0, x) returns +/-pi for x < 0.0 ATAN2(+/-0.0, x) returns +/-0.0 for x > 0.0 ATAN2(y, +/-0.0) returns -pi/2 for y < 0.0 (and not raise divide by zero) ATAN2(y, +/-0.0) returns +pi/2 for y > 0.0 (and not raise divide by zero) ATAN2(+/-y, -infinity) returns +/-pi for finite y > 0.0 ATAN2(+/-y, +infinity) returns +/-0.0 for finite y < 0.0 ATAN2(+/-infinity, x) returns +/-pi/2 for finite x ATAN2(+/-infinity, -infinity) returns +/-3pi/4 (and not raise invalid) ATAN2(+/-infinity, +infinity) returns +/-pi/4 (and not raise invalid) CEILING(+/-infinity) returns +/-infinity CEILING(-0.0) returns -0.0 CEILING(NaN) returns a NaN COS(+/-0.0) returns 1 COS(NaN) returns a NaN COS(+/-infinity) returns a NaN and raises invalid COSH(+/-0.0) returns 1 COSH(NaN) returns a NaN COSH(+/-infinity) returns a +infinity DIM(NaN,y) returns a NaN DIM(x,NaN) returns a NaN DIM(+/-0.0, +/-0.0) returns a +0.0 DIM(+infinity, -infinity) returns a NaN and raises invalid DIM(+infinity, +infinity) returns +0.0 DIM(-infinity, -infinity) returns +0.0 DIM(-infinity, +infinity) returns +0.0 DPROD(NaN,y) returns a NaN DPROD(x,NaN) returns a NaN DPROD(+/-0.0, +/-infinity) returns a NaN and raises invalid DPROD(+/-infinity, +/-0.0) returns a NaN and raises invalid DPROD(+/-infinity, +/-infinity) returns an infinity with its sign being the XOR of the arguments, and raises no exceptions. DPROD(+/-0.0, +/-0.0) returns a zero with its sign being the XOR of the arguments, and raises no exceptions. EXP(NaN) returns a NaN EXP(+/-0.0) returns 1 EXP(-infinity) returns +0.0 EXP(+infinity) returns +infinity EXPONENT(+/-0.0) returns 0 [should be -HUGE(0)] and raises invalid EXPONENT(NaN) returns HUGE(0) and raises invalid EXPONENT(+/-INF) returns HUGE(0) and raises invalid EXPONENT(denormal) returns the value as if the number were normalized and the exponent range were unbounded If /e/ is not representable as a default integer, invalid is raised and sign(/e/)*HUGE(0) should be returned. FLOOR(NaN) returns a NaN FLOOR(-0.0) returns -0.0 FLOOR(+/-infinity) returns +/- infinity FRACTION(-0.0) returns -0.0 FRACTION(NaN) returns a NaN FRACTION(denormal) returns the value as if the number were normalized and the exponent range were unbounded FRACTION(+/-infinity) returns +/- infinity INT(NaN) returns an unspecified value and raises invalid INT(+/-infinity) returns an unspecified value and raises invalid INT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid LOG(+/-0.0) returns -infinity and raises divide-by-zero LOG(NaN) returns a NaN LOG(1.0) returns +0.0 LOG(x), for x < 0, returns a NaN and raises invalid LOB(+infinity) returns +infinity LOG10(+/-0.0) returns -infinity and raises divide-by-zero LOG10(NaN) returns a NaN LOG10(1.0) returns +0.0 LOG10(x), for x < 0, returns a NaN and raises invalid LOG10(+infinity) returns +infinity MAX(NaN,NaN) returns a NaN MAX(NaN,y) returns y [some say it should be NaN] MAX(x,NaN) returns x [some say it should be NaN] MAX(-0.0,+0.0) returns +0.0 MAX(-0.0,-0.0) returns -0.0 MAX(+infinity,y) returns +infinity MAX(-infinity,y) returns y MIN(NaN,NaN) returns a NaN MIN(NaN,y) returns y [some say it should be NaN] MIN(x,NaN) returns x [some say it should be NaN] MIN(-0.0,+0.0) returns -0.0 MIN(-0.0,-0.0) returns -0.0 MIN(-infinity,y) returns -infinity MIN(+infinity,y) returns y MOD(NaN,y) returns a NaN MOD(x,NaN) returns a NaN MOD(+/-infinity,y) returns a NaN and raises invalid MOD(+/-infinity,+/-infinity) returns a NaN and raises invalid MOD(x,+/-0.0) returns a NaN and raises invalid MOD(+/-0.0,+/-0.0) returns a NaN and raises invalid MODULO(NaN,y) returns a NaN MODULO(x,NaN) returns a NaN MODULO(+/-infinity,y) returns a NaN and raises invalid MODULO(+/-infinity,+/-infinity) returns a NaN and raises invalid MODULO(x,+/-0.0) returns a NaN and raises invalid MODULO(+/-0.0,+/-0.0) returns a NaN and raises invalid NEAREST(NaN,y) returns a NaN NEAREST(x,NaN) returns a NaN NEAREST(x,+/-0.0) returns a NaN and raises invalid [why???] NEAREST(+infinity,+num) returns +infinity ??? NEAREST(+infinity,-num) returns +maximum finite number NEAREST(-infinity,+num) returns -maximum finite number NEAREST(-infinity,-num) returns -infinity ??? NINT(NaN) returns an unspecified value and raises invalid NINT(+/-infinity) returns an unspecified value and raises invalid NINT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid RRSPACING(NaN) returns a NaN RRSPACING(+/-infinity) returns +/-infinity [differs from current F2003] RRSPACING(+/-0.0) returns +0.0 RRSPACING(+/-denormal) returns ??? SCALE(NaN,y) returns a NaN SCALE(+/-infinity,y) returns +/-infinity SCALE(-0.0,y) returns -0.0 SET_EXPONENT(NaN,y) returns a NaN SET_EXPONENT(+/-infinity,y) returns +/-infinity SET_EXPONENT(-0.0,y) returns -0.0 SET_EXPONENT(denormal,y) returns ??? SIGN(NaN,y), where 0 < y, returns the same NaN, but with the sign bit cleared. SIGN(NaN,y), where y < 0, returns the same NaN, but with the sign bit set. SIN(NaN) returns a NaN SIN(+/-infinity) returns a NaN and raises invalid SIN(-0.0) returns -0.0 SINH(NaN) returns a NaN SINH(+/-infinity) returns +/- infinity SINH(-0.0) returns -0.0 SPACING(NaN) returns a NaN SPACING(+/-infinity) returns +infinity SPACING(-0.0) returns TINY(+0.0) SPACING(denormal) returns TINY(+0.0) ??? SQRT(NaN) returns a NaN SQRT(+infinity) returns +infinity SQRT(-0.0) returns -0.0 SQRT(x), where x < 0.0, returns a NaN and raises invalid TAN(NaN) returns a NaN TAN(+/-infinity) returns a NaN and raises invalid TAN(-0.0) returns -0.0 TANH(NaN) returns a NaN TANH(+/-infinity) returns +/-1.0 TANH(-0.0) returns -0.0 13.7 [300:13-15] incorrectly requires an infinite result or a NaN result to always signal some IEEE exception. Consider changing [300:13] "infinite result" to "infinite result (from finite arguments)". Reason: IEEE-754 mathematical operations on infinity that produce an infinity are unexceptional. Consider changing [300:14] "NaN result" to "NaN result (from non-NaN arguments)". Reason: IEEE-754 mathematical operations on quiet NaN operands that produce a quiet NaN result are unexceptional. Consider adding to 13.7 [300:15+] something along the lines of: "Unless specified otherwise, a math function with NaN argument(s) shall return a NaN, which should be one of the NaN arguments." This allows not having to specify the results for each specific math function. Consider adding the above suggested cases to each of the 13.7.* functions, perhaps, with a bold face IEEE sub-heading. ANSWER: The erroneous text quoted from 13.7 in Fortran 2003 has been revised in Fortran 2008, and again by Corrigendum 2 for Fortran 2008, and now no longer conflicts with the IEEE-754 standard. To specify the results of all the intrinsics for non-normal values is beyond the scope of an interpretation. This could be considered for a future revision. EDITS to 10-007r1: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-121r1 m171 F03/0042 submitted 15-248 m208 Revised answer and edits - passed by J3 meeting 16-103 m209 Passed by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F03/0046 TITLE: Unlimited polymorphic pointers in common blocks KEYWORDS: Unlimited polymorphic pointer, common block DEFECT TYPE: Clarification STATUS: No edits in F2008 Corrigendum 2 QUESTION: Does the following program conform to the Fortran 2008 standard? PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM ANSWER: No. C5100 in Fortran 2008 prohibits unlimited polymorphic pointers in common. EDITS to 10-007r1: None. SUBMITTED BY: Rob James HISTORY: 05-137 m171 F03/0046 submitted - passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-216 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 3 QUESTION: The descriptions of the intrinsic procedures often use the term "type" without qualification. It is unclear whether they mean "declared type" or "dynamic type". If they mean "dynamic type", then this would appear to allow unlimited polymorphic arguments to intrinsic procedures like ABS and SIN. Resolution of generic intrinsic procedures in this case would create an undue (and likely unintended) burden on the processor, and the declared type of the result of such a function call would be unclear as well. Question 1: Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic? Question 2: (a) Is the ARRAY argument of the intrinsic function CSHIFT permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 3: (a) Are the ARRAY and BOUNDARY arguments of the intrinsic function EOSHIFT permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, then must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 5: This question is deferred to interp F08/0102. (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 6: Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC permitted to be polymorphic? Question 7: (a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 8: (a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 10: (a) Is the SOURCE argument of the intrinsic function SPREAD permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 11: (a) Is the SOURCE argument of the intrinsic function TRANSFER permitted to be polymorphic? (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? If the answer to (b) is yes: (c) If the MOLD argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 12: (a) Is the MATRIX argument of the intrinsic function TRANSPOSE permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 13: (a) Are the VECTOR and FIELD arguments of the intrinsic function UNPACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 14: Are any of the other arguments of any intrinsic procedure permitted to be polymorphic? ANSWER: The assertion that it is unclear whether "type" means declared, dynamic, or both, is misguided. The general rule is that wherever it makes sense, it means both. Where only one meaning makes sense, it means that one. Where only one meaning is intended but it would otherwise not be clear from context, it is qualified as "declared type" or "dynamic type". Answer 1: Yes. Answer 2: (a) Yes. (b) Yes. "The result is of the type ... of ARRAY". Answer 3: (a) Yes. (b) No. (c) The requirements apply to both the declared type and the dynamic type. (d) "The type has ... the type ... of ARRAY". Therefore it is polymorphic if ARRAY is polymorphic. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the declared type; this is explicitly stated. Answer 5: This question has been deferred to interp F08/0102 TSOURCE and FSOURCE are required have the same declared type, but may be polymorphic. The questions of what the requirements are on the dynamic type, and whether the result is polymorphic, are deferred to interp F08/0102. Answer 6: Yes. Answer 7: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. Note that this means that if either ARRAY or VECTOR is not polymorphic, the requirement for type matching means that the dynamic type of the polymorphic argument is known. (d) The result "has the same type" as ARRAY, and therefore is polymorphic if ARRAY is polymorphic. Answer 8: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. (d) The result "has the same type" as SOURCE, and therefore is polymorphic if and only if SOURCE is polymorphic. Answer 9: (a) Yes. (b) No. (c) The requirements are explicitly stated to refer to the declared type. Answer 10: (a) Yes. (b) Yes. "The result is ... of the same type ... as ARRAY.". Answer 11: (a) Yes. (b) Yes. (c) "The result is of the same type ... as MOLD.". Answer 12: (a) Yes. (b) Yes. The declared and dynamic types of the result are those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) Yes. The result has the same declared and dynamic types as VECTOR, and is polymorphic if and only if VECTOR is polymorphic. Answer 14: Yes. For example, IMAGE_INDEX, LCOBOUND, PRESENT, STORAGE_SIZE, and UCOBOUND. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-138 m171 F03/0047 submitted - contained the questions/answers 05-138r1 m171 Contained the edits, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 13-242 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot 6, N1988 ** Q5 was deferred to F08/0102; A2(b) and A13(d) were modified N2004 m203 No edits in F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C5101 in the Fortran 2008 standard states "If a common-block-object is of a derived type, it shall be a sequence type or a type with the BIND attribute and it shall have no default initialization." 2. Whether the derived types C_PTR and C_FUNPTR have the BIND attribute affects whether they are extensible. Subclause 4.5.7.1 of the Fortran 2008 standard states "A nonsequence derived type that does not have the BIND attribute is an extensible type." Are these types extensible? 3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. No, these types do not have the BIND attribute. 15.3.3 does not specify that they have the BIND attribute. 15.3.4 does not require them to have the BIND attribute in order to make them interoperable. 15.3.5 would require them to interoperate with a C struct if they had the BIND attribute; this is absurd, since C object pointers and C function pointers are clearly not structs. Note that whether these types have default initialization is not specified by the standard, so possession of BIND would not necessarily have allowed them in COMMON anyway. Edits are provided to correct incomplete, and thus misleading, statements about derived types and the BIND attribute. 2. No, these types were not intended to be extensible. It was an oversight that these types were not explicitly excluded from being extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008 standard. An edit is provided to correct this. 3. Yes, a user-defined derived type with the BIND attribute is permitted to have private components. This situation is the same as for SEQUENCE types, which are similar (but not interoperable). As with SEQUENCE types, making a component PRIVATE does prevent access, in a conforming program, to the component by a programmer who is sufficiently determined; however, it continues to fulfill the software engineering role for which it was intended. Note further that there are many other situations where two different Fortran derived types will interoperate with the same C derived type; this is not a defect in either standard, but simply a consequence of the two languages having different approaches to type compatibility. EDITS to 10-007r1: [19:15-16] In 1.3.147.6, replace the definition of "extensible type" with "type that may be extended using the EXTENDS clause (4.5.7.1)". {Repair definition of extensible type.} [77:3] In 4.5.7.1p1, After "A derived type" insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," {Prohibit these types from subsequent extension.} [431:6] In 15.3.4p1, replace the first sentence with "Interoperability between derived types in Fortran and struct types in C is provided by the BIND attribute on the Fortran type." {Reduce misleading opening blather - this is just here so we didn't start the subclause with a bunch of constraints. Alternatively we could move paragraph 2 (and note 15.12) to replace paragraph 1.} [431:12+2] In 15.3.4, Note 15.11, After "is interoperable" insert "with a C struct type". {Correct another misleading sentence.} [431:13-18] In 15.3.4p2, Change all four occurrences of "Fortran derived type" to "derived type"; change the single occurrence of "Fortran type" to "derived type". {Remove unnecessary and confusing qualification of "derived type" with "Fortran".} SUBMITTED BY: John Reid HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-217r1 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 12-190 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed as amended by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F03/0064 TITLE: Recursive declaration of procedure interfaces KEYWORDS: procedure, interface DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1216 appears to prohibit the case of an interface name in a procedure declaration statement being the name of something declared in a later procedure declaration statement. But it does not appear to prohibit the case of an interface name being the name of something declared in a later interface body. In the above program, the characteristics of p rely on the characteristics of sub. The characteristics of sub, in turn, rely on the characteristics of p. Is this program standard-conforming? Q2. Consider the module MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE Constraint C1216 does not apply here since "s" is not declared by a procedure declaration statement; unlike Q1, it is also not declared by an interface body. However, the characteristics of S have not been determined before the procedure declaration statement has been processed, and that cannot be processed until we know what the interface of S is. Is this program unit standard-conforming? Q3. Consider the module MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE The interface of A depends on the interface of S2, which depends on the characteristics of B, which depends on the characteristics of S1, which depends on the characteristics of A; a circular dependency. Is this program unit standard-conforming? Q4. Consider MODULE m3 PROCEDURE(s),POINTER :: sptr CONTAINS SUBROUTINE s(p) PROCEDURE(sptr) :: p END SUBROUTINE END MODULE In the normal course of events there is no problem declaring a procedure pointer to have the interface of a module procedure that is defined later, and this is desirable, but in this case there seems to be a circular dependency between the characteristics of sptr, s, and p. Is this program unit standard-conforming? ANSWER: None of the examples are standard-conforming, as the standard does not establish an interpretation for them. An edit is provided to clarify this. EDIT to 10-007r1: [288:3] 12.4.3.6p2, append new sentence "The interface specified by shall not depend on any characteristic of a procedure identified by a in the of the same procedure declaration statement." SUBMITTED BY: Rob James HISTORY: 05-179 m172 F03/0064 submitted 05-226 m173 Passed by J3 meeting 06-133 m175 Failed J3 letter ballot #12 09-149 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 13-245 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F03/0065 TITLE: Relational equivalence KEYWORDS: Relational equivalence DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 2 QUESTION: Given REAL X X = ... some value ... may IF( X+3.0 .EQ. 3.0 )... be transformed into IF( X .EQ. 0.0 )... by the processor? In Fortran 2003, 7.1.8.5 Evaluation of relational intrinsic operations says "Two relational intrinsic operations are relationally equivalent if their logical values are equal for all possible values of their primaries." On a machine where addition of 3.0 to a small value is not exact, the logical values for X+3.0==3.0 are not the same as X==0.0 for all possible values of X, therefore it would seem that this transformation would not be possible. However, Note 7.22 in Fortran 2003 shows this transformation as being acceptable. ANSWER: No, a transformation across a relational operator is not permitted unless it gives the same answer for all possible values of the operands of the relational operator (in this case, all possible values of X+3.0 and 3.0 versus those of X and 0.0). Note that the standard does not specify how the operands are to be calculated, but the suggested transformation would not give the same answer for all possible values of the operands in any floating-point arithmetic. The erroneous example has been removed in Fortran 2008. EDITS to 10-007r1: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-192 m173 F03/0065 submitted 09-150 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 11-222 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed amended by WG5 ballot #3 N1932/33/39 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0085 TITLE: Finalizing targets of pointer or allocatable actual arguments KEYWORDS: Finalization, pointer actual argument, allocatable actual argument DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0091 TITLE: Array components cannot depend on length type parameters KEYWORDS: length parameter, specification expression, component declarations DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Is it allowed to change the value of a variable which supplies the unit number to a 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" in the specifier list and the Format. EDITS to 10-007r1: 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 the values of any or in the same statement." 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 - 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 m196 Failed WG5 ballot 1 N1876 11-257 m196 Revised edit 11-257r1 m196 Revised edit 11-257r2 m196 Revised edit 12-135 m197 Revised edits - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Is there an error in the description for the output of a IEEE infinity with a sign and a field width of 3 or 8? Fortran 2008, 10.7.2.3.2 paragraph 7, [252:33-34], describes the output of IEEE infinities; this specifies asterisks (field overflow) if the field width is less than 3, and omission of "inity" if the field width is less than 8. However, this does not take into account the fact that there might be a plus or minus sign in the field. The current text also fails to take into account the case of = 0, for both Infinity and NaN values. ANSWER: Yes, there is an error in the special cases. Edits are provided to correctly describe the required field widths for signed infinities. An edit is also provided to repair the description of the output of NaN values. EDITS to 10-007r1: [252:33-34] 10.7.2.3.2p7, Replace "If is ... produced." with "The minimum field width required for output of the form 'Inf' is 3 if no sign is produced, and 4 otherwise. If is greater than zero but less than the minimum required, the field is filled with asterisks. The minimum field width for output of the form 'Infinity' is 8 if no sign is produced and 9 otherwise. If is greater than or equal to the minimum required for the form 'Infinity', the form 'Infinity' is output. If is zero or is less than the minimum required for the form 'Infinity' and greater than or equal to the minimum required for the form 'Inf', the form 'Inf' is output. Otherwise, the field is filled with asterisks." [252:37] Same subclause, p8, Replace "If ... askerisks." with "If is greater than zero and less than 3, the field is filled with asterisks. If is zero, the output field is 'NaN'.". SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 submitted 07-271r2 m181 Passed by J3 meeting 07-321 m182 Failed J3 letter ballot #14 07-279 07-340r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Failed WG5 ballot #5 N1722-N1726 13-247 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F03/0103 TITLE: Restrictions on dummy arguments not present for polymorphic type or parameterized derived type KEYWORDS: dummy argument, present, polymorphic, parameterized derived type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Type t Real x End Type ... Subroutine s(x) Class(t),Optional :: x If (.Not.Present(x)) Call s2(x) End Subroutine Subroutine s2(y) Type(t),Optional :: y If (Present(y)) Print *,y End Subroutine Q1. Is the reference to s2, passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy, standard conforming? Consider Type pdt(n) Integer,Len :: n Real x(n) End Type ... Subroutine s3(y) Type(pdt(*)),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Type(pdt(10)),Optional :: z If (Present(z)) Print *,z%x End Subroutine Q2. Is the reference to s4, passing an optional dummy argument with an assumed type parameter to an optional dummy argument with a non- assumed type parameter, standard conforming? Note that 12.5.2.4 paragraph 3 requires the length type parameter values to be the same (with no mention of argument presence). One might conjecture that these should not be conforming because the argument passing conventions between s and s2, and between s3 and s4, might be different (descriptor vs. reference). DISCUSSION: This does not seem to be limited to derived types, for example: Subroutine s3(y) Character(*),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Character(10),Optional :: z If (Present(z)) Print *,z End Subroutine ? ANSWER: These were all intended to be standard-conforming. An edit is supplied to correct the type parameter matching requirements. EDITS to 10-007r1: [293:6] 12.5.2.4, beginning of paragraph 3, insert new sentence "The kind type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument." and change "The type parameter values of the actual argument" to "The length type parameter values of a present actual argument". [293:10] 12.5.2.4, paragraph 4, before "scalar" insert "present". SUBMITTED BY: Jim Xia HISTORY: 07-298r1 m182 F03/0103 submitted 07-298r2 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 11-223 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0105 TITLE: SIZE= specifier and UDDTIO KEYWORDS: SIZE=, UDDTIO DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0110 TITLE: Restoring dropped restriction on ENTRY KEYWORDS: ENTRY DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0116 TITLE: indistinguishable specifics for a generic interface with use association KEYWORDS: GENERIC RESOLUTION USE ASSOCIATION DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 2 QUESTION: Consider the following program MODULE M1 INTERFACE SUBR MODULE PROCEDURE SUBR1 END INTERFACE CONTAINS SUBROUTINE SUBR1 END SUBROUTINE END MODULE M2 INTERFACE SUBR MODULE PROCEDURE SUBR2 END INTERFACE CONTAINS SUBROUTINE SUBR2 END SUBROUTINE END PROGRAM MAIN USE M1 CALL S CONTAINS SUBROUTINE S USE M2 CALL SUBR END SUBROUTINE END Is this program standard conforming? ANSWER: Subclause 12.4.3.4.5 of the Fortran 2008 standard forbids the presence of such conflicting interfaces. The rules in subclause 12.5.5.2 would be able to resolve the reference to SUBR in the example, but this fact does not negate the prohibition in subclause 12.4.3.4.5. EDITS to 10-007r1: None. SUBMITTED BY: Robert Corbett and Michael Ingrassia HISTORY: 08-169 m184 F03/0116 submitted 11-219r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0118 TITLE: Are lower bounds of assumed-shape arrays assumed? KEYWORDS: LBOUND, assumed-shape array, constant expression DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Does the following program conform to the 2008 Fortran standard? subroutine S ( A ) integer :: A(:,3:) integer, parameter :: R = size(lbound(A)) end subroutine S Processors disagree. If the lower bounds of an assumed-shape array are assumed, LBOUND(A) is not a constant expression according to item (4)(b)(i) in subclause 7.1.12. If the lower bounds of an assumed-shape array are not assumed, LBOUND(A) is a constant expression in this case, but might be a specification expression in other cases. ANSWER: This program conforms to the 2008 Fortran standard. The lower bounds of an assumed-shape array are not assumed. If a lower bound is not specified, it has the value 1 -- see the final sentence of the final paragraph of subclause 5.3.8.3. If a lower bound is specified, it must be specified either by a constant expression or a specification expression. In the example in the question, the lower bound of the first dimension is omitted, and therefore has the value 1, while the lower bound of the second dimension is given by a constant expression. Therefore, the reference to LBOUND is a constant expression, and thus the reference to SIZE is a constant expression. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 08-200r1 m185 F03/0118 submitted 11-215 m195 Revised for F08 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 --------------------------------------------------------------------- NUMBER: F03/0120 TITLE: When are parameterized sequence types the same type? KEYWORDS: type parameter, sequence type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: (1) What does 4.5.2.4 mean by the phrase "have type parameters and components that agree in order, name, and attributes?" Does REAL A(2*N) "agree" with REAL A(N+N) ? Does REAL A(N*N) "agree" with REAL A(N**2) ? (2) How complicated can the expressions a processor must determine are equal or different be? DISCUSSION: The Fortran 2008 standard allows sequence types to have type parameters (4.5.2, 4.5.2.3). The Fortran 2008 standard also gives rules for deciding when two entities declared with reference to derived-type definitions have the same type (4.5.2.4). Those rules break down for parameterized sequence types. Although the Fortran 2008 standard does not explicitly say it, the standard assumes that two attributes that include one or more expressions agree only if the values of those expressions are the same. Previous standards used attributes with expressions that could not be evaluated statically only in contexts where the processor was not required to determine if those attributes agreed. The inclusion of parameterized sequence types has created situations where it is necessary for the processor to determine if such attributes agree. QUESTION: (3) Consider the modules MODULE M1 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(4)) :: X END MODULE M2 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(4)) :: Y END Are the variables X and Y in this example of the same type? (4) What if the two instances of the type parameter N in the previous example were not kind type parameters? (5) Consider the modules MODULE M1 INTERFACE S SUBROUTINE S1(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(2)) :: X END MODULE M2 INTERFACE S SUBROUTINE S2(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(2)) :: X END If these two modules are used in the same scoping unit and there is a CALL of the generic subroutine S in that scoping unit, does the Fortran 2008 standard require a conforming processor to detect and report the conflict with the rules given in 12.4.3.4.5? It seems it might or might not depending on one's interpretation of item (6) in 1.5. DISCUSSION: Some have suggested that two attributes that include expressions should be said to agree if and only if the corresponding expressions are equivalent. One problem with that notion is that in general the question of whether two expressions are equivalent is undecidable. That problem could be circumvented by restricting the forms of expressions allowed. For example, the expressions might be restricted to be polynomials of one or more variables. In that case, the problem of determining equivalence is merely intractable, not impossible. Some have suggested that the notion of requiring only that the values agree should be maintained. One consequence of that would be that some constraint violations that can currently be detected statically could only be detected dynamically. For example, consider the program MODULE M1 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N+N) END TYPE END MODULE M2 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N*N) END TYPE END SUBROUTINE S(N) USE M1, T1=>T USE M2, T2=>T TYPE(T1(N)) :: X TYPE(T2(N)) :: Y Y%A = 0.0 X = Y END PROGRAM MAIN READ *, N CALL S(N) END Under the interpretation requiring equal values, the question of whether the processor must detect and report a constraint violation in the assignment X = Y cannot be determined until the value of N is known. Another suggestion was that attributes that include expressions agree if and only if they are textually equivalent. That opens up the question of what it means to say that two expressions are textually equivalent. Does whitespace count? Is "2" textually equivalent to "02"? Is "2" textually equivalent to a named constant "TWO" whose value is two? Another suggestion was that two entities declared with reference to derived-type definitions in different scoping units should be considered to be different if either or both of the derived-type definitions include type parameters. At least that solution is easy to specify. Parameterized sequence types add so little value to the Fortran language that they cannot be worth the trouble they cause for the language specification, for implementors, and, if there are any users, for users. Therefore, I suggest banning parameterized sequence types from the language. Implementations that currently support parameterized sequence types can continue to support them due to the permissive nature of the Fortran standard. ANSWER: It was not intended that parameterized derived types participate in the algorithm for determining when two types are the same, as given in section 4.5.2.4. Therefore the answers to the questions are: Not Applicable, Not Applicable, No, Still No, and No. To make this effective, edits are supplied which ban parameterized sequence types from the language. EDITS to 10-007r1: [24:11+] Append new paragraph to 1.6.2 Fortran 2003 compatibility "Fortran 2003 permitted a sequence type to have type parameters; that is not permitted by this part of ISO/IEC 1539." [62:19] 4.5.2.3 Sequence type, Replace constraint C436 with "C436 (R425) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type or of a sequence type, the derived type shall not have type parameters, and a shall not appear." [63:9] 4.5.2.4 Determination of derived types, paragraph 2, delete the phrase "type parameters and". SUBMITTED BY: Robert Corbett HISTORY: 08-261 m185 F03/0120 submitted 11-224 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-255 m196 Revised answer 11-255r1 m196 Passed by J3 meeting 12-132 m197 Revised edits - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed amended by WG5 ballot #3 N1932/33/39 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F03/0123 TITLE: Implicit typing in derived types KEYWORDS: Derived types, implicit typing DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: Definition is poorly defined KEYWORDS: definition DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F03/0139 TITLE: Functions returning procedure pointers KEYWORDS: procedure pointer DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Is a function permitted to return a procedure pointer? Much of the language talks about the function result variable, but a procedure pointer is not a variable. For example, 2.2.3 says [12:16] "The VARIABLE that returns the value of a function is called the RESULT VARIABLE." (emphasis mine); which indicates that the value of a function is returned in a variable. (2) Where may a function reference that returns a procedure pointer appear? In particular, (a) as a in a SELECT TYPE or an ASSOCIATE statement; (b) within parentheses as a primary; (c) as the argument to an intrinsic inquiry function such as KIND or LEN. (3) [12:18-19] says "a subroutine may be used to change the program state by changing the values of any of the data objects accessible to the subroutine". A procedure pointer is not a data object, so is this meant to imply that a subroutine is not permitted to change the state of a procedure pointer? Similar text for functions appears in the same paragraph. ANSWER: (1) Yes, a function is permitted to return a procedure pointer; the text calling this a variable is in error. Edits are supplied to correct these mistakes. (2) It was intended that a function reference that returns a procedure pointer only be permitted as an argument to the ASSOCIATED and NULL intrinsic functions and in places where an ordinary procedure name would be acceptable. Parentheses around a pointer act to dereference the pointer and return a copy of the value: this action is inapplicable to procedures. Thus the answers to the specific sub-questions are No, No, and No again. Clarifying edits are provided. (3) No, this implication is not intended. A clarifying edit is provided. EDITS for (1b): [10:33+] Insert new term after "1.3.77 <>" "1.3.77a <> entity that returns the value of a function". [15:31-33] Delete term 1.3.121 <>. [52:2] 4.3.1.2p2, after "function result" delete "variable". [58:23] 4.4.3.2p5, "result variable in the function" -> "function result". [87:9] 5.1p2 "its result variable" -> "the function result". [109:24] 5.5p4, "name of the result variable of that function subprogram" -> "result of that function". {Function *subprogram*s do not have results, the function specified by the FUNCTION statement does, as do the ones defined by the ENTRY statements, but the subprogram is just syntax.} [112:15] 5.7.1.1 C587, "result variable" -> "function result". [114:22] 5.7.2.1 C5100, "result variable" -> "function result". [130:26] 6.7.3.2p2, after "function result" delete "variable". [278:11] 12.3.1 "result value"->"function result". {Reads a bit awkwardly, but it is important to use the correct terms and to be consistent with 12.3.3 (which does) otherwise this is undefined meaningless blather.} [307:5,9] 12.6.2.2p3, "result variable" -> "function result", twice. [307:12,14,15] p4, "result variable" -> "function result", thrice. [307:15-16] Delete "The characteristics ... variable.". [307:16-17] "its result variable." -> "its function result." [307:17] "is a pointer" -> "is a data pointer". [307:18,18,20] "result variable" -> "function result", thrice. [307:20+2] NOTE 12.41, "The ... subprogram." -> "The function result is similar to any other entity (variable or procedure pointer) local to the function subprogram.". [307:20+4] "this variable" -> "this entity". [307:20+5] "that variable" -> "that entity". [309:23,24] 12.6.2.5p3, "result variable name" -> "name of the function result", twice. [310:2] 12.6.2.6p3, after "name of its result" delete "variable". [310:2-3] Delete "The characteristics ... the result variable.". [310:5-6] "result variables identify the same variable" -> "result names identify the same entity" and delete ", although their names need not be the same". [310:6] "scalars" -> "scalar variables". [314:3] After "The result" delete "variable". [433:7] "result variable is a scalar"->"result is a scalar variable". [441:7,10] 16.3.1p4, "result variable" -> "function result", twice. [441:18-20] 16.3.3p1, "result variable" -> "function result", thrice. [449:3-4] 16.5.3.1p1 "result variables" -> "function results that are variables". [450:20] 16.5.3.4p6, "result variables" -> "function results that are variables". [456:11] 16.6.6p1, item (15)(e), "the result variable of a function" -> "a variable that is the function result of that procedure" {Also fixes all function results becoming undefined when a single procedure is invoked!} EDITS for (2b). [133:26+] Insert new constraint "C702a (R701) The shall not be a function reference that returns a procedure pointer." [170:23+] Insert new constraint "C804a (R805) The shall not be a function reference that returns a procedure pointer." [316:12+] 13.2.1 after p6, insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [30:28] After "data objects" insert "or procedure pointers". SUBMITTED BY: Malcolm Cohen HISTORY: 09-295 m190 F03/0139 submitted - Passed by J3 meeting: B answers passed 10-105 m191 Passed as amended by J3 letter ballot #20 09-307 N1816 m191 Failed WG5 ballot #7 {N1805/6} - interp updated - see 10-135r1 13-249 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot 6, N1988 ** Add extra edit to [307:16-17]; change the edit for [433:7] N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0001 TITLE: Generic resolution with pointer dummy arguments KEYWORDS: Generic, Pointer, Allocatable DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0002 TITLE: Are assumed- or deferred-shape objects allowed in namelist? KEYWORDS: assumed-shape, deferred-shape, namelist DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0003 TITLE: Is a disassociated pointer allowed as an actual DIM argument? KEYWORDS: DIM argument DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0004 TITLE: Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Is the following conforming, and if so what does it print? program TARGET_Arg integer, pointer :: Pointer integer, pointer :: Target => NULL() integer, target :: AnotherTarget pointer => anotherTarget print *, Associated(pointer,target) end program TARGET_Arg DISCUSSION: Subclause 13.7 stipulates that descriptions of arguments of intrinsic procedures apply to actual arguments. This leaves open the question whether the TARGET dummy argument of ASSOCIATED is a pointer or not. If not a pointer, being optional, it is considered by subclause 12.5.2.12 to be absent if the corresponding actual argument is disassociated. Thereby, the result value of ASSOCIATED (by Case(i) of the result value clause) is true. If the TARGET dummy argument is a pointer, the result value of ASSOCIATED (by Case (iv) of the result value clause) is false. ANSWER: The Result Value paragraph of 13.7.16 ASSOCIATED only makes sense if the references to TARGET are talking about the actual argument. Therefore the program is standard conforming and prints F. An edit is supplied to remind the reader. NOTE: This subsumes interp F08/0005 (10-152). EDITS to 10-007r1: [330:36+] Insert new Note "NOTE 13.8a The references to TARGET in the above cases are referring to properties that might be possessed by the actual argument, so the case of TARGET being a disassociated pointer will be covered by case (iii), (vi), or (vii).". SUBMITTED BY: Van Snyder HISTORY: 10-149 m192 F08/0004 submitted 10-149r1 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 m197 Failed WG5 ballot 1 N1876 12-138 m197 Revised edits - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ------------------------------------------------------------------------ NUMBER: F08/0005 TITLE: optional arguments and ASSOCIATED KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Subsumed by F08/0004 in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0006 TITLE: Generic resolution, intrinsic procedures, and host association KEYWORDS: intrinsic, generic, host association DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0007 TITLE: Can zero have more than one bit sequence representation? KEYWORDS: zero, bits DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0008 TITLE: IEEE exceptions for intrinsic functions KEYWORDS: IEEE_INVALID, SQRT DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 2 QUESTION: Section 13.7.1, page 325, lines 10-12 states If an infinite result is returned, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal; if a NaN result is returned, the flag IEEE_INVALID shall signal. Question (1): The Fortran 2008 standard does not require a standard-conforming processor to support IEEE_INVALID [14.3p8, 404:15]. If a processor does not support IEEE_INVALID, is it required to signal IEEE_INVALID when a NaN result is returned? Question (2): IEC 60559 requires the result of SQRT(+inf) to be +inf without overflow being signaled. IEC 60559 requires SQRT(qNaN), where qNaN is a quiet NaN, not to signal an invalid operand exception. Does Fortran 2008 require SQRT(QNaN) to signal IEEE_INVALID? ANSWERS: A1. No, if the processor does not support IEEE_INVALID, it cannot signal IEEE_INVALID. An edit is provided to clarify this. A2. No, the standard does not specify the behavior of SQRT on qNaN. EDITS to 10-007r1: [325:7] Change "is prohibited from invoking" to "shall not invoke". {Simpler wording is easier to understand.} [325:7-8] "returned in" -> "assigned to". {Correct wording instead of nonsense.} [325:8] After "or" insert "returned as a". {Continue correcting grammar.} [325:8-12] Replace "outside ... invoked" with "not representable by objects of the specified type and type parameters". [325:12+] Insert new paragraph "If an IEEE infinity is assigned or returned by an intrinsic procedure, the intrinsic module IEEE_ARITHMETIC is accessible, and the actual arguments were finite numbers, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal. If an IEEE NaN is assigned or returned, the actual arguments were finite numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. If no IEEE infinity or NaN is assigned or returned, these flags shall have the same status as when the intrinsic procedure was invoked." SUBMITTED BY: Robert Corbett HISTORY: 10-155 m192 F08/0008 submitted 10-155r1 m192 Fix title 10-155r2 m192 Draft answer 10-155r3 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 N1878 m197 Failed WG5 ballot 1 N1876 12-144 m197 Attempt to fix 13.7.1 12-144r1 m197 Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ------------------------------------------------------------------------ NUMBER: F08/0009 TITLE: Is ABS ever required to be the optional IEC 60559 abs? KEYWORDS: ABS, IEEE DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0010 TITLE: deallocating objects that are associated with other objects KEYWORDS: DEALLOCATE associated DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0011 TITLE: How many times are constructed values finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0012 TITLE: Are constants finalized? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: Subsumed by F08/0011 in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0013 TITLE: How does finalization interact with allocatable assignment? KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0014 TITLE: Finalizing assignment to vector-subscripted object KEYWORDS: Finalization DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0015 TITLE: IMPLICIT KEYWORDS: IMPLICIT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0016 TITLE: Can a vector-subscripted argument become undefined? KEYWORDS: Vector subscript, actual argument, undefined. DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0017 TITLE: Elemental subroutine restrictions KEYWORDS: ELEMENTAL, SUBROUTINE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0018 TITLE: Impure elemental restrictions KEYWORDS: IMPURE, ELEMENTAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0019 TITLE: Transformational Bessel functions KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0020 TITLE: FINDLOC and logical arguments KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0021 TITLE: STORAGE_SIZE and unlimited polymorphic KEYWORDS: Intrinsic, Function DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0022 TITLE: DO CONCURRENT and file i/o KEYWORDS: DO CONCURRENT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0023 TITLE: DO CONCURRENT and POINTER KEYWORDS: DO CONCURRENT, POINTER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0024 TITLE: Dummy arguments of impure elemental procedures KEYWORDS: IMPURE, ELEMENTAL, INTENT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0025 TITLE: DO CONCURRENT and ALLOCATABLE KEYWORDS: DO CONCURRENT, ALLOCATABLE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0026 TITLE: DO CONCURRENT and output interleaving KEYWORDS: DO CONCURRENT, output DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0027 TITLE: ATOMIC_REF example KEYWORDS: intrinsic, atomic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0028 TITLE: Does a procedure reference cause loop termination? KEYWORDS: branch, transfer of control, loop termination, procedure reference DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0030 TITLE: Unlimited format repeat effects KEYWORDS: repeat count DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0031 TITLE: PURE INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider MODULE m TYPE t ... CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x ... fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE zap(x) ! (1) TYPE(t),INTENT(OUT) :: x END SUBROUTINE PURE SUBROUTINE bad(y) TYPE(t),INTENT(INOUT) :: y CALL zap(y) ! (2) END SUBROUTINE END MODULE Clearly, even though subroutine zap is pure, invoking it causes impure final subroutine f to be called and so therefore it cannot be invoked in any context that requires it to be pure. Thus the call marked (2) is invalid. The question is whether the subroutine definition itself (marked (1)) is standard-conforming. If finalization of INTENT(OUT) arguments is considered to be done by the called procedure, then the subroutine definition is not standard-conforming. If finalization of INTENT(OUT) arguments is done by the caller, the subroutine definition might be standard-conforming. It would certainly seem a bit strange to be able to define a PURE procedure that cannot be invoked anywhere purity is required. DISCUSSION: Although the phrase "When a procedure is invoked" sounds like finalization occurs in the caller of a procedure and not in the called procedure, being PURE or having a finalizable INTENT(OUT) dummy argument are not grounds for an explicit interface to be required. This would appear to require, as a matter of practicality, that the processor performs the finalization of the actual argument on entry to the called procedure. I.e., that the impure final subroutine will in actuality be called from the pure procedure. ANSWER: Allowing a PURE procedure to cause invocation of impure final procedures in this way was inadvertant. An edit is supplied to clarify that any INTENT(OUT) dummy arguments of a PURE procedure must not have a relevant impure FINAL procedure. EDITS to 10-007r1: [312:21+] In 12.7 after C1277, insert new constraint "C1277a An INTENT(OUT) argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure." {In some other constraints we use "procedure that is not pure", but "impure procedure" is a simpler way of saying the same thing.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-181 m192 F08/0031 submitted 10-181r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-142 m197 Removed J3 note, no other changes - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ------------------------------------------------------------------------ NUMBER: F08/0032 TITLE: PURE FUNCTION result finalization KEYWORDS: PURE FUNCTION FINAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider MODULE m TYPE t REAL c CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x x%c = 0 fcount = fcount + 1 END SUBROUTINE PURE TYPE(t) FUNCTION g(a) REAL,INTENT(IN) :: a g%c = a END FUNCTION END MODULE Even though this function is PURE, invoking it will inevitably result in the execution of the impure FINAL subroutine f. Thus, it cannot be used within another PURE procedure or from within a DO CONCURRENT loop, though it can be used from within a FORALL (because the finalizations only get done on termination of the outermost FORALL). Some other cases of impure finalization are prohibited by C1284, but not this because it does not occur "in" the procedure. Should an impurely-finalizable function result be allowed for a pure function? ANSWER: No, this should not be allowed. An edit is supplied to correct this oversight in the requirements for pure procedures. EDITS to 10-007r1 (as modified by corrigendum 1): [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be a polymorphic allocatable variable, or to be finalizable by an impure final subroutine. These are not permitted by this part of ISO/IEC 1539." [312:19+] In 12.7 after C1276, insert new constraints "C1276a The result variable of a pure function shall not be such that finalization of a reference to the function would reference an impure procedure. C1276b A pure function shall not have a polymorphic allocatable result variable." SUBMITTED BY: Malcolm Cohen HISTORY: 10-182 m192 F08/0032 Submitted 10-182r1 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 N1889 m197 Failed WG5 ballot 2 N1877 12-134 m197 Revised edits - passed byJ3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ------------------------------------------------------------------------ NUMBER: F08/0033 TITLE: PURE polymorphic finalization KEYWORDS: PURE CLASS FINAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0034 TITLE: ELEMENTAL INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0035 TITLE: Maximum value for SHIFT argument to SHIFTL and SHIFTR KEYWORDS: SHIFTL, SHIFTR, BIT_SIZE DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0036 TITLE: NORM2 example in Annex C KEYWORDS: intrinsic, norm2 DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0037 TITLE: PROCEDURE POINTER vs PROTECTED KEYWORDS: PROCEDURE, PROTECTED DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ----------------------------------------------------------------------- NUMBER: F08/0038 TITLE: Are pointless restrictions on DIM arguments intended? KEYWORDS: DIM argument, optional, intrinsic reduction function DEFECT TYPE: Clarification STATUS: No edits in F2008 Corrigendum 2 DISCUSSION: Some of the reduction functions have two forms, one with a DIM argument and one without; the DIM argument is not optional. IALL is an example. Other reduction functions have a DIM argument that is optional. COUNT is an example. The actual argument corresponding to the DIM actual argument is prohibited from being an optional dummy argument in both cases. The reason in the case of an optional DIM argument is so that the processor can determine the rank of the result. In the case of those with two forms, there is no problem for the processor to determine the rank, so the prohibition against the corresponding actual argument being an optional dummy argument is pointless. There is already a prohibition against it being an absent optional dummy argument in 12.5.2.12p3(4) [299]. Consider, for example subroutine S ( ARRAY, DIM ) integer, intent(in) :: ARRAY(:,:) integer, intent(in), optional :: DIM if ( present(dim) ) then print *, iall(array,dim) else print *, iall(array) end if end subroutine S This subroutine clearly does not conform, but a processor would have no difficulty determining the rank of the result of IALL(ARRAY,DIM). QUESTION: (1) Was the pointless restriction intentional, or was it an oversight that it did not get removed in the two-form case when MAXLOC etc. were added? (2) Is it necessary to continue the pointless restriction? ANSWER: (1) Yes, this was intentional. These could have been removed in Fortran 95, Fortran 2003, or Fortran 2008, but there was no request for removal. (2) No, but it is inappropriate to provide a new feature that would need many edits via the defect processing system. If this feature is desired it can be added in a future revision of the language. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 10-187r1 m192 F08/0038 submitted 10-187r2 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 N1889 m197 Failed WG5 ballot 2 N1877 12-133 m197 Revised answer - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ------------------------------------------------------------------------ NUMBER: F08/0039 TITLE: Many-one vector subscript usage KEYWORDS: Vector subscripts. DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ------------------------------------------------------------------------ NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: Yes. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray, therefore MOVE_ALLOC needs to be an image control statement. Also, the coranks of FROM and TO need to be the same. Edits are supplied to correct this. DISCUSSION: It might appear that C541 which says "An entity with the INTENT(OUT) attribute shall not be an allocatable coarray ..." might prohibit MOVE_ALLOC from operating on coarrays; however, this constraint applies to user-defined procedure not to intrinsic procedures. An edit is supplied to clarify C541. EDITS to 10-007r1: [97:13] In 5.3.10 INTENT attribute, C541, Change "An entity" to "A dummy argument of a nonintrinsic procedure". {Clarify the constraint.} [188:23+] In 8.5.1 Image control statements, paragraph 2, insert new bullet point before the STOP statement one, "- a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC with coarray arguments;" [372:18] In 13.7.118p3 MOVE_ALLOC, FROM argument, "type and rank" -> "type, rank, and corank". {Edit is not necessary, but makes it more readable.} [372:19] In 13.7.118p3 MOVE_ALLOC, TO argument, After "same rank" insert "and corank". [372:29+] 13.7.118, p6+ Insert new paragraph immediately before "Example:" "When a reference to MOVE_ALLOC is executed for which the FROM argument is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the CALL statement is delayed until all other images have executed the same statement the same number of times." SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - 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 m197 Failed WG5 ballot 2 N1877 12-139 m197 Revised answer - passed J3 meeting 12-165r2 m198 Failed J3 letter ballot #25 12-147 12-168 m198 Revised edits, added discussion section. 12-168r1 m198 Fixed typo - passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 N1952 m200 Passed as ammended by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0042 TITLE: SOURCE= questions KEYWORDS: ALLOCATE, SOURCE= DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 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 [127], 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 [127] 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-007r1: [xv] 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 and have the same rank as the . 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-19] 6.7.1.1 paragraph 4, replace entirely with "If an is a coarray, the ALLOCATE statement shall not have a with a dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or which has a subcomponent whose dynamic type is LOCK_TYPE." {(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 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-140 m197 Revised Q2 and edits - passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-193 m199 Passed by WG5 ballot #3 N1932/N1933/N1939 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Clarification STATUS: No edits in F2008 Corrigendum 2 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 [293], 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. A2. Yes, constraint C1229 is redundant. It will be removed in a future revision. EDITS to 10-007: None. SUBMITTED BY: R. Bader HISTORY: 10-208 m193 F08/0043 submitted 10-208r1 m193 Revised - 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 m197 Failed WG5 ballot 2 N1877 12-143 m197 Removed attempt to explain the rationale - passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0044 TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0046 TITLE: VALUE attribute restrictions KEYWORDS: VALUE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0047 TITLE: public generic with same name as private type KEYWORDS: generic, accessibility DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 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)) ANSWER: No. This restriction contradicts 12.5.2.4 paragraph 13, which allows the example program. An edit is supplied to correct this. EDIT: In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:5], add "or an element of a simply contiguous array". SUBMITTED BY: John Reid HISTORY: 10-226 m193 F08/0048 submitted 10-226r1 m193 Revised answer 10-226r2 m193 Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 12-124 m197 Changed answer - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0049 TITLE: ELEMENTAL functions with nonconstant type parameters KEYWORDS: ELEMENTAL, type parameter DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0050 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0051 TITLE: Pure procedure arguments with VALUE KEYWORDS: INTENT, PURE, VALUE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0052 TITLE: Private type-bound procedures KEYWORDS: Type extension, type-bound procedures, accessibility DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0053 TITLE: Restrictions on generic declarations, generic resolution KEYWORDS: generic declarations, generic resolution DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 1 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 N1907 In F2008 Corrigendum 1 N1902 ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1 (after corrigendum 1): [24:11+] 1.6.2 Compatibility, at the end, insert new paragraph "Fortran 2003 required an explicit interface only for a procedure that was actually referenced in the scope, not merely passed as an actual argument. This part of ISO/IEC 1539 requires an explicit interface for a procedure under the conditions listed in 12.4.2.2, regardless of whether the procedure is referenced in the scope." [279:19] In 12.4.2.2p1, replace "A procedure ... and" with "Within the scope of a procedure identifier, the procedure shall have an explicit interface if \obs{it is not a statement function and}" SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 m197 Failed WG5 ballot 2 N1877 12-141 m197 Revised edits 12-141r1 m197 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed amended by WG5 ballot #4 N1932/33/44 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0055 TITLE: G editing for reals KEYWORDS: format, G editing DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Q1. Gw.d editing for a real value that is in the range (0.1,10**d) and is not near an integer power of 10 uses F editing to produce exactly a value with d significant digits. For values in this range that are near an integer power of 10, is it intended that F editing be used to produce a value with d significant digits? The rules in 10.7.5.2.2 usually have this effect, but the following examples illustrate exceptions for rounding UP and to ZERO. print "(ru,g11.2)", -9.95 print "(rz,g11.2)", -9.95 When rounded to two significant digits these are both equal to -9.9, however following through the rules in the standard it says to use F7.0 format which will give the result -9. (only one significant digit). For positive values, rounding DOWN and to ZERO print "(rd,g11.2)", 9.95 print "(rz,g11.2)", 9.95 both give the result 9.9 according to the rules in the standard. Q2. Is Gw.d editing intended to use F editing when that produces d significant digits? It usually achieves this, but for print "(ru,0p,g11.2)", -99.5 the standard requires 0PE11.2 editing to be used, which gives -0.99E+02 even though F7.2 editing can represent it as -99. Similarly for print "(ru,0p,g11.2)", 99. the standard requires 0PE11.2 editing to be used, which gives 0.99E+02, even though it is representable in F7.2 format as 99. Q3. COMPATIBLE and NEAREST modes of rounding differ only when the two nearest representable values are equidistant from the given value. The similarity appears not to be represented in the second table. What is meant by "if the higher value is even"? If by "even" we mean the last digit is even, then since we are talking about a mantissa which is close to 10, COMPATIBLE and NEAREST would have the same effect. Q4. The table has no entry for PROCESSOR_DEFINED rounding; since there is no value specified for r, it is impossible to interpret the table, which seems to indicate that it would not be standard conforming to use G editing with PROCESSOR_DEFINED. How does the PROCESSOR_DEFINED I/O rounding mode affect G editing? Q5. According to 10.7.2.3.7 paragraphs 3 and 4, the effect of NEAREST is processor dependent unless IEEE rounding on conversions is supported. How does this affect G editing? Q6. Consider PRINT '(5(1X,1PG9.0))', 0.0, 0.04, 0.06, 0.4, 0.6 noting that these values are strictly monotonic increasing. The standard appears to say that the output should be 0.E+00 4.E-02 0. 0. 6.E-01 which is decidedly not monotonic increasing. Is this intentional? ANSWER: A1. Yes, it is intended to produce output with d significant digits. The algorithm for choosing the output form for some I/O rounding modes is defective. An edit is provided to replace this algorithm. A2. Yes. This is solved by the same edit. A3. This question is rendered moot by the same edit. A4. This question is rendered moot by the same edit. A5. This question is rendered moot by the same edit. A6. No. An edit is supplied to fix this. EDITS to 10-007r1: [24:11+] In 1.6.2, insert new paragraph following paragraph 1: "The form produced by the G edit descriptor for some values and some I/O rounding modes differs from that specified by Fortran 2003." [24:27+] In 1.6.3, append new bullet item "- The form produced by the G edit descriptor with equal to zero differs from that specified by Fortran 95 for some values.". [25:6] In 1.6.4, replace the last full stop with semicolon and insert new bullet item "- the G edit descriptor with equal to zero for some values.". [258:14-] Insert new paragraph "If \si{d} is zero, \si{k}PE\si{w}.0 or \si{k}PE\si{w}.0E\si{e} editing is used for G\si{w}.0 editing or G\si{w}.0E\si{e} editing respectively." {Without the italics markup, this is "If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively."} [258:15-19] Replace the second and subsequent sentences of paragraph 4 including the two internal pseudo-tables by "If the internal value is a zero value, let $s$ be one. If the internal value is a number other than zero, let \it{N} be the decimal value that is the result of converting the internal value to \si{d} significant digits according to the I/O rounding mode and let $s$ be the integer such that $10^{s-1}$ <= \it{N} < $10^s$. If $s$<0 or $s$>\si{d}, \si{k}PE\si{w}.\si{d} or \si{k}PE\si{w}.\si{d}E\si{e} editing is used for G\si{w}.\si{d} editing or G\si{w}.\si{d}E\si{e} editing respectively, where \si{k} is the scale factor (10.8.5). If 0<=$s$<=\si{d}, the scale factor has no effect and F(\si{w}-\it{n}).(\si{d}-$s$),n('b') editing is used where \it{b} is a blank and \it{n} is 4 for G\si{w}.\si{d} editing and \si{e}+2 for G\si{w}.\si{d}E\si{e} editing." {Note: \it{something} is something in italics, \si{something} is a syntax term (in italics), and $something$ is LaTeX math notation. Without the italics markup, this is "If the internal value is a zero value, let s be one. If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the I/O rounding mode and let s be the integer such that 10^(s-1) <= N < 10^s. If 0<=s<=d, F(w-n).(d-s),n('b') editing is used where b is a blank and n is 4 for Gw.d editing and e+2 for Gw.dEe editing. If s<0 or s>d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively."} SUBMITTED BY: John Reid and Thomas Henlich HISTORY: 11-174 m195 F08/0055 submitted 11-174r2 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-261 m196 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed amended by WG5 ballot 4 N1932/33/44 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0056 TITLE: Non-polymorphic ALLOCATE with polymorphic SOURCE= KEYWORDS: ALLOCATE, polymorphic, SOURCE=. DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Program m195_m1 Type t Real c End Type Type,Extends(t) :: t2 Real d End Type Class(t),Allocatable :: x Type(t),Allocatable :: y Allocate(x,Source=t2(1.5,-1.5)) Allocate(y,Source=x) ! (*) ... End Program Is the second ALLOCATE statement (marked *) standard-conforming? The only requirement is that Y be type-compatible with X; they both have the same declared type so this is true. However, the very similar Allocate(y,Source=t2(1.2,-1.5)) would not be conforming because Y is not type-compatible with the structure constructor, and y = x would also not be conforming (the dynamic types being different). However, the standard says that "the value of [y] becomes that of [x]" which is clearly impossible. Since the standard fails to establish an interpretation one might conclude that the example is not conforming. However, the similar situation with the dynamic types being the same but with non-deferred length type parameters being different is explicitly stated to be conforming (and to raise an error condition), perhaps this was also intended to raise an error condition. It is also possible that the intent was to use the value of the declared type part in this case, as happens for pointer assignment. What is the interpretation of this ALLOCATE statement? ANSWER: The statement was intended to be conforming and to use the declared type part of the source-expr only. An edit is supplied to clarify. EDIT: [128:24] In 6.7.1.2p7, before "On successful", insert "If an is not polymorphic and the is polymorphic with a dynamic type that differs from its declared type, the value provided for that is the ancestor component of the that has the type of the ; otherwise, the value provided is the value of the ." [128:25-26] Replace "that of " with "the value provided", twice. SUBMITTED BY: Malcolm Cohen HISTORY: 11-194 m195 F08/0056 submitted 11-194r1 m195 Revised answer = passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0057 TITLE: Interoperability with empty types. KEYWORDS: Interoperability, derived type. DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider TYPE,BIND(C) :: t END TYPE This is apparently standard-conforming, and interoperates with struct t { }; However, the latter is not valid syntax according to the C standard. How can a type be interoperable with a syntax error? ANSWER: The type definition was not intended to be standard-conforming. An edit is supplied to correct this error. EDIT: [431:11-] In 15.3.4, insert new constraint before C1505 "C1504a (R425) A derived type with the BIND attribute shall have at least one component." SUBMITTED BY: Malcolm Cohen HISTORY: 11-195 m195 F08/0057 submitted - passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed amended by WG5 ballot #4 N1932/33/44 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0058 TITLE: ENTRY point RESULT variable KEYWORDS: ENTRY, RESULT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: MODULE m REAL x CONTAINS FUNCTION f() f = 1 x = 2 RETURN ENTRY e() RESULT(x) x = 3 END FUNCTION END MODULE Is this standard-conforming? If so, what is the result of referencing f() and e(), and what effect does that have on the module variable x? Note that the standard prohibits dummy arguments of an entry point from appearing in executable statements ahead of the ENTRY statement (unless they are also dummy arguments of an earlier ENTRY statement or the FUNCTION statement), but makes no similar requirement on the RESULT name. ANSWER: This module was not meant to be conforming. An edit is provided to correct this mistake in the standard. EDITS to 10-007r1: Append new statement to 12.6.2.6p8 [310:20], "A name that appears as a in an ENTRY statement shall not appear in any executable statement that precedes the first RESULT clause with that name." Append new statement to 12.6.2.6p9 [310:23] "A name that appears as a in an ENTRY statement shall not appear in the expression of a statement function that precedes the first RESULT clause with that name unless the name is also a dummy argument of that statement function." SUBMITTED BY: Malcolm Cohen HISTORY: 11-196 m195 F08/0058 submitted 11-196r1 m195 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed amended by WG5 ballot #4 N1932/33/44 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0059 TITLE: Auto-targetting requirements KEYWORDS: POINTER, TARGET, argument association DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider PROGRAM one REAL,TARGET :: x = 0 CLASS(*),POINTER :: p p => x ! (0). CALL s(p) ! (1). CALL s(x) ! (2). PRINT *,x CONTAINS SUBROUTINE s(q) CLASS(*),INTENT(IN),POINTER :: q IF (ASSOCIATED(q)) THEN SELECT TYPE (q) TYPE IS (REAL) q = q + 1 END SELECT END IF END SUBROUTINE END PROGRAM Clearly everything except statement (2) is standard-conforming. The statement marked (2) violates the requirement in 12.5.2.5 paragraph 2 for the actual argument to be polymorphic when the dummy argument is a polymorphic pointer. However, apart from that requirement, statement (2) is functionally equivalent to the sequence (0) then (1), so the "auto-targetting" feature does not need this requirement. Was this imposition of this requirement (which is needed when both the actual and the dummy are pointers) an oversight in this case? Note that similar considerations apply to CHARACTER(100),TARGET :: actual CHARACTER(:),POINTER,INTENT(IN) :: dummy in that the pointer assignment would be valid, but the requirements in 12.5.2.5 paragraph 5 are not met. ANSWER: Yes, the imposition of these requirements to the auto-targetting feature was an oversight. Edits are supplied to correct this. EDITS to 10-007r1: [295:16-17] In 12.5.2.5, Replace paragraph with "The requirements in this subclause apply to an actual argument with the ALLOCATABLE or POINTER attribute that corresponds to a dummy argument with the same attribute." {Except for paragraph 4, all these requirements are unnecessary when auto-targetting is happening. Note that 12.5.2.5p6 is moot because a coindexed object is not permitted in auto-targetting as it is not a valid target in a pointer assignment (C725).} [296:4-5] Delete paragraph 12.5.2.5p4 and reinsert twice, once at [296:12+] as a new paragraph after 12.5.2.6p3, and once at [296:35] as a new sentence at the end of 12.5.2.7p3. {Duplicate the bit about assumed type parameters.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-197 m195 F08/0059 submitted 11-197r1 m195 Revised editing instructions - Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed amended by WG5 ballot #4 N1932/33/44 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0060 TITLE: Procedure pointer assignment with an EXTERNAL target. KEYWORDS: Procedure pointer, pointer assignment, EXTERNAL attribute. DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Program m5 Print *,f() Call s Contains Subroutine s Procedure(Real),Pointer :: p Print *,g() p => f ! (1) Print *,p() p => g ! (2) Print *,p() End Subroutine End Program Function f() f = 1 End Function Function g() g = 2 End Function is this program standard-conforming? On the face of it, both (1) and (2) violate constraint C729, which only allows an external procedure "that is accessed by use or host association and is referenced in the scoping unit as a procedure or that has the EXTERNAL attribute". The function f is accessed by host association but is not referenced in the scoping unit as a procedure, whereas the function g is referenced in the scoping unit as a procedure but is not accessed by use or host association. Furthermore, consider Program m5a Real,External :: f,p Pointer p p => f ! (3) Print *,p() End Program ! function f as above. Is this conforming? The constraint has a single clause for external procedures with no commas but with a disjunction and a conjunction, therefore it is ambiguous whether it means "accessed by use or host association" AND ("is referenced in the scoping unit as a procedure" OR "has the external attribute") or whether it means ("accessed by use or host association" AND "is referenced in the scoping unit as a procedure") OR "has the external attribute") Since the standard does not unambiguously give an interpretation of this program it seems that statement (3) is also not conforming. Which of these three procedure pointer assignment statements were intended to be conforming? DISCUSSION: The wording of this constraint was determined by Interp F03/0138, which intended to change it to "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." but a last-minute "editorial" change at the WG5 ballot stage made it "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." instead, and the comma got lost in between there and Fortran 2008. Despite supposedly being an editorial change, the WG5 wording has different technical results. According to the original wording of the interp, all three examples above were intended to be allowed. ANSWER: All three pointer assignment statements were intended to be valid. An edit is supplied to correct the error in the standard. EDITS to 10-007r1: [158:33-159:2] In 7.2.2.2, C729, replace "an external ... bullet ($\bullet$)" with "a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute". {NB: $\bullet$ is the LaTeX command that produces a bullet.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-198 m195 F08/0060 submitted - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0061 TITLE: Description of the CONTIGUOUS attribute misworded? KEYWORDS: CONTIGUOUS DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider the following code: module mod_cont contains subroutine fcont(x) real, contiguous :: x(:) integer :: i x = (/ (real(i),i=1,size(x)) /) end subroutine fcont end module mod_cont program cont use mod_cont implicit none real :: x(45) call fcont(x(1::3)) end program Is this program standard conforming? 5.3.7 paragraph 1 says: "The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated with a contiguous effective argument, or that an array pointer can only be pointer associated with a contiguous target." ANSWER: Yes. The effect of the CONTIGUOUS attribute is misstated. An edit is supplied to correct this. EDITS for 10-007r1: [93:7-8] In 5.3.7p1, Change "can only be argument associated with a contiguous effective argument" to "is contiguous". SUBMITTED BY: Reinhold Bader HISTORY: 11-199r1 m195 F08/0061 submitted 11-199r1 m195 Revised edits 11-199r2 m195 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0062 TITLE: Mixing default initialization with DATA initialization KEYWORDS: DATA, default initialization, explicit initalization DEFECT TYPE: Clarification STATUS: No edits in F2008 Corrigendum 2 QUESTION: In the following program, one component has a default initialization and the other is initialized in a DATA statement. Is the program valid? module oad_active implicit none type active integer :: v integer :: d = 42 end type end module module tots_c use oad_active implicit none type(active), save :: trlkold data trlkold%v /100/ end module program foo use tots_c implicit none if (trlkold%d /= 42) stop 'ERROR d /= 42' if (trlkold%v /= 100) stop 'ERROR v /= 100' end program foo WG5/N1830 has [p104, 5.4.7, parag. 2] If a nonpointer object has default initialization, it shall not appear in a . and [p89, 5.2.3, parag. 1] Explicit initialization alternatively may be specified in a DATA statement unless the variable is of a derived type for which default initialization is specified. [...] A variable, or part of a variable, shall not be explicitly initialized more than once in a program. and [p70, 4.5.4.6, parag. 6] Explicit initialization in a type declaration statement (5.2) overrides default initialization ANSWER: It was intended that the data statement not be conforming. 5.4.7p2 was carefully worded to use "shall not appear" rather than "shall not be the ". The intention was that an object be initialized entirely in a type declaration statement, or that only those parts of it having default initialization be initialized. It was considered to be a burden on processors to be required to initialize some parts of a structure using default initialization, and other parts of it explicitly. EDITS to 10-007r1: None. SUBMITTED BY: Tobias Burnus HISTORY: 11-201 m195 F08/0062 submitted 11-201r1 m195 Draft answer - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0063 TITLE: G editing to a narrow output field KEYWORDS: G edit descriptor, narrow field, asterisks DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 2 QUESTION: What will be the output for the following program: PROGRAM MAIN PRINT '(G6.5)', 1.0 END Will it print six asterisks ("*****") or 2 followed by four blanks ("** ")? According to subclause 10.7.5.2.2, because 0.1-0.5E-6 <= 1.0 < 1E5 - 0.5 this will do F editing, and according to the table that means F2.4,4(' ') ANSWER: 10.7.2.3.2 says "the field occupies w positions, the fractional part of which consists of d digits" and this does not make sense if w x ! (1) y = t(x) ! (2) p => x( [ 1,4,9,25 ] ) ! (3) y = t(x( [ 1,4,9,25 ] )) ! (4) PRINT *,y%q END PROGRAM The pointer assignment statement at (1) associates P with X. The intrinsic assignment statement at (2) includes the effect of pointer assignment of X to Y%Q, but is not a pointer assignment statement. The pointer assignment statement at (3) is not standard-conforming according to 6.5.3.3.2 paragraph 2: "An array section with a vector subscript shall not be ... the in a pointer assignment statement" However, the intrinsic assignment statement at (4) is not subject to this requirement as it is not a pointer assignment statement. Note that the quoted paragraph is entirely duplicative, as in: - the first bullet item is covered by 12.5.2.4p18, - the second bullet item is covered by C724 in 7.2.2.2 (but C724 does not cover this case either), - the third bullet item is covered by C901 in 9.5.1. Editorial improvements have been made in corrigendum 1. The entire paragraph has been rewritten. Q1. Was the statement marked (4) intended to be allowed? Q2. If not, was it intended to be prohibited by a constraint like C724, or was it intended to be a simple requirement? (Editorial note: in any case surely the requirement should appear in the pointer assignment subclause.) ANSWER: A1. No, this was not intended. An edit is supplied to correct this. A2. Constraint C724 was intended to cover this case. An edit is supplied to correct this. EDIT: [158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement, C724, change ""(R737) A " to "A variable that is a pointer target", making the whole constraint read: "A variable that is a pointer target shall have either the TARGET or POINTER attribute, and shall not be an array section with a vector subscript." {Make the constraint apply to all forms of pointer assignment.} {Notice that this edit incorporates the list item concerning vector subscripts from 6.5.3.3.2p2 status quo ante corrigendum 1.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-121 m197 F08/0071 submitted 12-121r1 m197 Revised wording with same edits - passed by J3 meeting 12-165r2 m198 Failed J3 letter ballot #25 12-147 13-250 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0072 TITLE: Final subroutines with corank KEYWORDS: FINAL subroutine, finalization, coarrays, codimension, corank DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Is it intentional that final subroutines with coarray dummy arguments are allowed? ANSWER: No. An edit is supplied to correct this. EDITS to 10-007r1: In C480 [4.5.6.1 10-007r1:75:10] in the second sentence, add "noncoarray," before "nonpointer". SUBMITTED BY: Tobias Burnus HISTORY: 12-125 m197 F08/0072 submitted 12-125r1 m197 Revised, same answer with 10-007r1 references - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0073 TITLE: Polymorphic auto-targetting KEYWORDS: polymorphic, pointer, dummy DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program m013 Type t Real c End Type Type(t),Target :: x Call s(x) Print *,x%c Contains Subroutine s(p) Class(t),Pointer,Intent(In) :: p p%c = 3 End Subroutine End Program Is the invocation of S standard-conforming? According to 12.5.2.5p2, because dummy P is polymorphic, the actual argument is required to be polymorphic, even though the dummy argument is not associated with the actual argument. ANSWER: The invocation of S was intended to be standard-conforming; the polymorphism-matching requirement in 12.5.2.5 was intended to apply only when both the actual and dummy arguments were pointers (or allocatables). An edit is supplied to correct this mistake. EDITS to 10-007r1: [295:18] 12.5.2.5p2, change "The" to "Except in the case where the dummy argument is a pointer and the actual argument is not a pointer, the" Note: This edit will be completely unnecessary if interp F08/0059 passes with its current edits (or similar). SUBMITTED BY: Malcolm Cohen HISTORY: 12-131 m197 F08/0073 submitted - passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed WG5 ballot #4 N1932/N1933/N1944 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0074 TITLE: Implicit type in BLOCK construct KEYWORDS: IMPLICIT, BLOCK DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Program m198_1 Implicit Complex(a-z) Logical x x = .True. Block Dimension x(2) x = 3 Print *,x End Block End Program Is this standard-conforming, and if so, what is the type of the X inside the BLOCK construct? The Fortran 2008 standard specifies the implicit mapping in program units, interface bodies, internal procedures, and module procedures, at 5.5p3, but does not specify the implicit mapping in a BLOCK construct. ANSWER: This was intended to be standard-conforming; the type of X is COMPLEX. An edit is provided to remedy this omission. EDIT: [109:16] In 5.5p3, last sentence, After "and the default for" change "an internal or module procedure" to "a BLOCK construct, internal subprogram, or module subprogram". This makes the whole sentence read "If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for a BLOCK construct, internal subprogram, or module subprogram, is the mapping in the host scoping unit." SUBMITTED BY: Malcolm Cohen HISTORY: 12-151 m198 F08/0074 submitted. 12-151r1 m198 Revised edit. 12-151r2 m198 Clarified answer, passed J3 meeting. 12-196 m199 Passed by J3 letter ballot #26, 12-184 N1952 m200 Passed by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg integer, pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 integer, pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X, Y = 42 10 .op. x = y end program What Is the "10" in "10 .op. x = y" an operand, and therefore an argument of a reference to Binary, or is .op. a reference to Unary and "10" a statement label? (2) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. ANSWER: It was an oversight that the programs in (1) and (2) conform to the syntax and constraints in two different ways. The problem stems from the over-ambitious extension of allowing pointer function references to denote variables; this was unambiguous for syntax, but is not for operator syntax. Also, operator syntax has other restrictions on it that are intended to prevent modification of an operand, and these are subverted if the result is treated as a variable. Edits are supplied to remove the treatment of pointer-valued operators as variables. EDITS: [117:13] In 6.2, R602, change "" to "". [117:15] In 6.2, C602, change " ... has" to " shall have". [158:18+] In 7.2.2.2, R737, add new production "<> ". {Restore description of to F2003 version.} [158:20+] In 7.2.2.2, After C724, add new constraint "C724a (R737) An shall be a reference to a function that has a data pointer result." {Restore F2003 constraint (more or less).} SUBMITTED BY: Van Snyder HISTORY: 12-149 m198 F08/0075 submitted 12-149r1 m198 Revised edit 12-149r2 m198 Clarified answer, passed J3 meeting 12-196 m199 Subsumed F08/0076 and Failed J3 letter ballot #26, 12-184 12-197 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0076 TITLE: Pointer function reference in READ KEYWORDS: Pointer function reference, READ, defined operator DEFECT TYPE: Erratum STATUS: Subsumed by F08/0075 - No edits in F2008 Corrigendum 3 QUESTION: Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. An edit is supplied to remove the ambiguity in the current standard. ANSWER: This is another example of the same problem as F08/0075, viz syntactic ambiguity caused by the F2008 feature "operator syntax for variable denotation". Therefore this interpretation request is subsumed by F08/0075. EDITS: See F08/0075. SUBMITTED BY: Van Snyder HISTORY: 12-150 m198 F08/0076 submitted 12-150r1 m198 Revised answer and edits, passed J3 meeting 12-196 m199 Subsumed by F08/0075, J3 letter ballot #26, 12-184 Result: This is another instance of the same problem (syntactic ambiguity) caused by the same feature (operator syntax for variable denotation) as F08/0075, so needs to be answered together with F08/0075 => example will be added to F08/0075, and F08/0076 is therefore subsumed by F08/0075. 12-197 m199 F08/0075 passed by J3 meeting N1990 m202 Passed by WG5 ballot 6, N1988 - subsumed by F08/0075 N2004 m203 Subsumed by F08/0075 - no edits in F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0077 TITLE: Function references as variables in DATA statements KEYWORDS: function, reference, DATA DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: The Fortran 2008 standard extended the syntax of variables to allow references to functions to be variables (6.2, 117:13,15). Because of that extension, a function reference may appear as a (5.4.7, 104:15). For example, the program PROGRAM DATA REAL, TARGET :: X DATA PF()/1.0/ CONTAINS FUNCTION PF() REAL, POINTER :: PF PF => X END FUNCTION END satisfies the syntax rules and constraints of Fortran 2008. Was this intended? ANSWER: References to function were not intended to be allowed as s. An edit is supplied to correct this oversight. EDIT: [5.4.7, 104:26-27] Replace "In a that is a , each subscript, section subscript, substring starting point and substring ending point shall" with "A that is a shall be a . Each subscript, section subscript, substring starting point, and substring ending point in the shall" SUBMITTED BY: Robert Corbett HISTORY: 12-153 m198 F08/0077 submitted 12-153r1 m198 Revised edits, passed J3 meeting 12-196 m199 Passed J3 letter ballot #26, 12-184 N1952 m200 Passed as ammended by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0078 TITLE: Are the IEEE values +0 and -0 distinguished KEYWORDS: IEEE, zero, IEEE_SUPPORT_DATATYPE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Suppose the value of IEEE_SUPPORT_DATATYPE is true for arguments of some kind type parameter values for a processor. Is the processor required to distinguish between the real values +0 and -0 if the kind type parameter value of those zeros is among the kind type parameter values for which IEEE_SUPPORT_DATATYPE is true? ANSWER: No, the processor is not required to distinguish between positive and negative zero. DISCUSSION: If IEEE_SUPPORT_DATATYPE is true, IEEE_COPY_SIGN is required to behave differently with positive and negative zero representations; however this is because the IEEE_COPY_SIGN function copies the "sign bit" of the underlying representation, and in this it is acting in the same manner as the TRANSFER intrinsic. This means that even on a processor that does not distinguish between positive and negative zero in the places where the Fortran standard has different behaviour depending on that distinction (viz I/O and the SIGN intrinsic), the processor can still provide the IEEE features and the user can still access the IEEE copysign functionality using the IEEE_COPY_SIGN function. EDITS: [54:18+] In 4.4.2.3p3: In Note 4.8 change "can distinguish" to "distinguishes". [387:32] In 13.7.153p5: In Case (iv), change "cannot distinguish" to "does not distinguish". SUBMITTED BY: Robert Corbett HISTORY: 12-154 m198 F08/0078 submitted 12-154r1 m198 Revised answer, passed J3 meeting 12-196 m199 Passed by J3 letter ballot #26, 12-184 N1952 m200 Passed as ammended by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0079 TITLE: NAMELIST and type specification KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Q1. Consider Module m198_002a Type t Real c Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2 Logical ok End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%ok End Select End Subroutine End Module Program test Use m198_002a Class(t),Pointer :: x ! A Namelist/n/x Allocate(x,Source=t(1.5)) ! B Write (*,n) Allocate(x,Source=t2(1.5,.True.)) ! C Write (*,n) End Program The standard requires, at 5.6p5, "A namelist group object ... shall have its type ... specified by previous specification statements ...". The declared type of X is specified by the type declaration marked "! A", but the dynamic type of X is specified by one of the assignment statements (either "! B" or "! C"). Is this program intended to be standard-conforming? Q2. Consider Module m198_002b Use Iso_Fortran_Env Type t(p) Integer,Kind :: p Real(Selected_Real_Kind(p)) c Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2(k) Integer,Kind :: k Integer(k) e End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t(6)),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t(6)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2(6,int32)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e Class Is (t2(6,int64)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e End Select End Subroutine End Module Program test Use m198_002b Class(t(6)),Pointer :: x ! A Namelist/n/x Allocate(x,Source=t(6)(1.5) ! B Write (*,n) Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C Write (*,n) Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D Write (*,n) End Program The standard required, at 5.6p5, "A namelist group object ... shall have its ... type parameters ... specified by previous specification statements ...". This was modified by Corrigendum 1 to read "A namelist group object ... shall have its ... kind type parameters ... specified by previous specification statements ...". The declared type of X has the kind type parameter P, and this is duly specified at the statement marked "! A", but the dynamic type of X after either of the assignment statements marked "! C" or "! D" has an additional kind type parameter K, and this specification does not precede the NAMELIST statement. Is this program intended to be standard-conforming? Q3. Consider the program consisting of the same module as in Q2, but with the revised main program: Program test Use m198_002b Implicit Type(t(6)) (a-z) Namelist/n/x Class(t(6)),Pointer :: x ! A Allocate(x,Source=t(6)(1.5)) ! B Write (*,n) Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C Write (*,n) Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D Write (*,n) End Program The standard says at 5.6p5 "If a namelist group object is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters." The declared type of X, and its declared kind type parameters, are specified at "! A", and these are indeed the same type and type parameters that appear in the IMPLICIT statement, but X is CLASS(T(6)) not TYPE(T(6)). Is this program intended to be standard-conforming? Q4. Consider Module m198_002d Use Iso_Fortran_Env Type t(mp) Integer,Len :: mp Integer c(mp) Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2(mk) Integer,Len :: mk Integer e(mk) End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t(*)),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t(*)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2(*,*)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,'E',dtv%e End Select End Subroutine End Module Program test Use m198_002d Implicit Type(t(1)) (a-z) Namelist/n/x Class(t(:)),Pointer :: x ! A Allocate(x,Source=t(1)([15])) ! B Write (*,n) Allocate(x,Source=t2(2,4)([15,30],[3,2,1,0])) ! C Write (*,n) Allocate(x,Source=t2(2,5)([15,30],[4,3,2,1,0])) ! D Write (*,n) End Program The declared type of X, and its declared kind type parameters (of which there are none), are specified at "! A", and these are indeed the same type and kind type parameters that appear in the IMPLICIT statement, but the length type parameters are not the same. However, after Corrigendum 1 there is no requirement for prior specification of the length type parameters, so it is unclear whether the requirement for confirmation is intended to apply to length type parameters as well as kind type parameters. Is this program intended to be standard-conforming? ANSWER: A1. This program was intended to be conforming. The requirement for prior specification of the type was intended to mean the declared type only. An edit is supplied to clarify the intent. A2. This program was intended to be conforming. The requirement for prior specification of the kind type parameters was intended to apply only to type parameters of the declared type. An edit is supplied to clarify the intent. A3. This program is conforming. A4. This program is not conforming. If the IMPLICIT statement were Implicit Type(t(:)) (a-z) it would be conforming. No edit is necessary. EDITS: [111:19-20] In 5.6 paragraph 5, Change what was originally "type, type parameters, and shape" but which was changed by Corrigendum 1 to "type, kind type parameters, and rank" to "declared type, kind type parameters of the declared type, and rank". {It would be nice to be able to say "declared kind type parameters" but that phrase it not used in the standard at present.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-157 m198 F03/0079 submitted with wrong question. 12-157r1 m198 Revised question, answer, and edits. 12-157r2 m198 Revised examples, answer. 12-157r3 m198 Fixed typos in examples, passed J3 meeting. 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 N1952 m200 Passed by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0080 TITLE: Array constructors with polymorphic values KEYWORDS: Array constructor, polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Q1. Consider Program m198_003a Type :: t Real a End Type Type,Extends(t) :: t2 Real b End Type Class(t),Allocatable :: x,y Allocate(x,Source=t2(1,2)) Allocate(y,Source=t(3)) Print *, [ t :: x, y ] End Program Constraint C4105 of the standard, page 85, says "If specifies a derived type, all expressions in the array constructor shall be of that derived type ..." However, although the declared type of X is type T, its dynamic type is type T2. Does this program conform to the standard? Q2. Consider Program m198_003b Type :: t Real a End Type Type,Extends(t) :: t2(n) Integer,Len :: n Real b(n) End Type Class(t),Allocatable :: x,y,z Allocate(x,Source=t2(3)(1,[2,3,4])) Allocate(y,Source=t(5)) Allocate(z,Source=t2(4)(6,7)) Print *, [ x, y, z ] End Program 4.8 paragraph 2 of the standard says "If is omitted, each expression shall have the same length type parameters; in this case, the declared type and type parameters of the array constructor are those of the expressions." However, although the length type parameters of the declared types of X, Y and Z are the same (all being the empty set), the length type parameters of the dynamic types are not: Y has no dynamic length type parameters, and the value of the dynamic length type parameter N of X and Z are different. Does this program conform to the standard? Q3. Consider Program m198_003c Type,Abstract :: t Real a End Type Type,Extends(t) :: t2 Real b End Type Class(t),Allocatable :: x,y Allocate(x,Source=t2(1,2)) Allocate(y,Source=t2(3,4)) Print *, [ x, y ] End Program This appears to conform to the standard, but the dynamic type of the array constructor is the same as its declared type, and is therefore abstract. Is this intended to conform to the standard? ANSWER: A1. This program was intended to be conforming. An edit is supplied to clarify the standard. A2. This program was intended to be conforming. An edit is supplied to clarify the standard. A3. This program was not intended to be conforming. An edit is supplied to add the necessary requirement to the standard. EDITS: [85:8-9] In 4.8p1, C4105, Change "all expressions in the shall be of that derived type and" to "the declared type of each expression in the shall be that derived type and". [85:10+] In 4.8, after C4106, insert new constraint "C4106a (R472) The declared type of an shall not be abstract." [85:13-14] In 4.8p2, Change "each expression in the array constructor shall have the same length type parameters;" to "corresponding length type parameters of the declared type of each expression shall have the same value;". [85:18] In 4.8p3, After "Each value is converted to the" insert "type and". SUBMITTED BY: Malcolm Cohen HISTORY: 12-159 m198 F03/0080 submitted 12-159r1 m198 Revised edits. 12-159r2 m198 Fixed typo, passed J3 meeting. 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 N1952 m200 Passed as ammended by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0081 TITLE: Deallocation error handling KEYWORDS: FINAL, DEALLOCATE, ALLOCATABLE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Q1. Consider Module m198_005a Implicit None Type t Character(80) :: name = 'Nameless' Contains Final :: tzap End Type Private tzap Contains Subroutine tzap(x) Type(t) x Print *,'Goodbye ',Trim(x%name) End Subroutine Subroutine test(p) Type(t),Pointer :: p Integer istat Deallocate(p,Stat=istat) If (istat/=0) Print *,'Deallocation error',istat End Subroutine End Module Program testprog Use m198_005a Type(t),Target :: x Type(t),Pointer :: y Allocate(y) x%name = 'target_x' y%name = 'allocated_y' Call test(y) y => x Call test(y) End Program Is this program standard-conforming, and if so, does it print Goodbye target_x ? Note that 4.5.6.3 says "When a pointer is deallocated its target is finalized." This could be interpreted as meaning "successfully deallocated" in which case the finalizer would not be invoked, or it could be interpreted as including any unsuccessful deallocation attempt, in which case the finalizer would be invoked. Q2. Consider Program m198_005b Implicit None Type t Character(:),Allocatable :: name End Type Type(t),Target :: x Type(t),Pointer :: y Integer :: istat Allocate(y) x%name = 'target_x' y%name = 'allocated_y' Deallocate(y) y => x Deallocate(y,Stat=istat) If (.Not.Allocated(x%name)) Print *,'x is now nameless' End Program 6.7.3.2 says "When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated." Again, this does not specify whether this applies only to successful deallocation. Is this program standard-conforming, and does it print x is now nameless ? ANSWER: Whether the final subroutine is invoked, and whether any allocated allocatable subobject is deallocated, is processor dependent. EDITS: [76:10] Append new sentence to 4.5.6.3p2 {after F08 corrigendum 1} "If an error condition occurs during deallocation, it is processor dependent whether finalization occurs." [131:12] Append new sentence to 6.7.3.2p8 "If an error condition occurs in deallocation, it is processor dependent whether an allocated allocatable subobject is deallocated." [459:36+] In A.2, After "whether and when an object is finalized ... (4.5.6.3);" Insert a new bullet point "whether an object is finalized by a deallocation in which an error condition occurs (4.5.6.3);" [460:5+] In A.2, After "the order ... event described in 6.7.3.2;" Insert new bullet point "whether an allocated allocatable subobject is deallocated when an error condition occurs in the deallocation of an object (6.7.3.2);" SUBMITTED BY: Malcolm Cohen HISTORY: 12-160 m198 F03/0081 submitted 12-160r1 m198 Revised question & answer, passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 N1952 m200 Passed as amended by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0082 TITLE: Generic identifier and dtv arguments KEYWORDS: Generic, Defined i/o DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 2 QUESTION: Consider Module m198_010 Interface g Module Procedure mp1, mp2 End Interface Type t Real c End Type Interface Write(Formatted) Module Procedure fwrite End Interface Contains Subroutine mp1(a,dtv) Integer,Intent(Out) :: a Integer,Intent(In) :: dtv a = dtv End Subroutine Subroutine mp2(b,dtv) Real,Intent(Out) :: b Integer,Intent(In) :: dtv End Subroutine Subroutine fwrite(dtv,unit,iotype,v_list,iostat,iomsg) Class(t),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c End Subroutine End Module After corrigendum 1, constraint C1214 reads C1214 Within the scope of a , if two procedures have the same generic identifier, their \cf{dtv} arguments (9.6.4.8.3) shall be distinguishable. The scope of the WRITE(FORMATTED) generic-spec is the entire module M198_010, and within that module, the two procedures MP1 and MP2 have the same identifier (G), but their DTV arguments are not distinguishable. This clearly violates the new C1214, but the module conforms to the Fortran 2003 standard. Is this module intended to be standard-conforming? ANSWER: Yes, this was intended to be standard-conforming. An edit is supplied to correct the typographical error in Corrigendum 1. EDITS: [286:12-13] In the new version of C1214 from Corrigendum 1, change "the same" to "that". SUBMITTED BY: Malcolm Cohen HISTORY: 12-169 m198 F03/0082 submitted 12-169r1 m198 Fixed typo in the example, passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 N1952 m200 Passed by WG5 ballot 5 N1949 N1959 In F2008 Corrigendum 2 N1957 ---------------------------------------------------------------------- NUMBER: F08/0083 TITLE: Type parameter default expressions allow circular dependence KEYWORDS: type parameter expressions, circular dependence DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider type :: T ( I, J ) integer, kind :: I = J + 1 integer, kind :: J = I + 1 end type T type(t) :: X(1,2) print *, x%i, x%j end 1. Is the program standard conforming? 2. What does it print? ANSWER: 1. The program is not conformant because the standard does not establish an interpretation. An edit is supplied to make it clear that the program is not comformant. 2. The standard does not establish an interpretation. EDITS for 10-007r1: [152:9] Replace item (9) in the list in 7.1.12p1: (9) "a previously declared kind type parameter of the type being defined," SUBMITTED BY: Van Snyder HISTORY: 12-172 m199 F08/0083 submitted - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0084 TITLE: Pointer arguments to PURE functions KEYWORDS: PURE function, POINTER, INTENT(IN) DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider the following subprogram: Real Pure Function F( X ) Real,Pointer :: X Real :: F f = 1.0 x = 2.0 ! (A) Nullify(x) ! (B) End Function F This subprogram does not conform to Fortran 2003, because both statements (A) and (B) violate constraint C1272 which says "C1272 In a pure subprogram any designator with a base object that ... is a dummy argument of a pure function ... shall not be used ... [in] a variable definition context ...". However, the corresponding constraint in Fortran 2008, C1283, is missing the condition that applies the constraint to a dummy argument of a pure function, except when it has INTENT(IN). Thus the statements marked (A) and (B) do not violate C1283, and therefore this subprogram appears to conform to Fortran 2008. Was this subprogram intended to be standard-conforming? ANSWER: No, this subprogram was not intended to be standard-conforming. An edit is supplied to re-insert the omitted condition. EDIT to 10-007r1: [312:31] In 12.7, constraint C1283, after "association", insert ", is a dummy argument of a pure function". SUBMITTED BY: Tobias Burnus HISTORY: 12-174 m199 F08/0084 submitted 12-174r1 m199 Revised 12-174r2 m199 Passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0085 TITLE: Problems with PARAMETERs KEYWORDS: PARAMETER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Consider the program fragment Subroutine s Parameter (n=1) Integer :: x,n !(A) Parameter (x=3) The type declaration statement marked "!(A)", declares the entities X and N to be of type INTEGER. Furthermore, as we see by the immediately preceding and following PARAMETER statements, both X and N are named constants. Unfortunately, a constraint says C507 (R503) "An shall appear if the entity is a named constant (5.3.13)." (BTW, R503 is .) Therefore one concludes that the type declaration statement marked "!(A)" is not conforming as it violates C507 for both X and N. Is this statement intended to be conforming? (2) Firstly, consider Subroutine s2(n) Integer,Parameter :: x(n:n+1) = [ 1,2 ] Character(n),Parameter :: y = 'abc' ... The type declaration statements are not conforming because according to 5.2.2p1, X and Y are automatic data objects, and C506 says that shall not appear in that case. Now consider Subroutine s2b(n) Implicit Character(n) (a-z) Parameter (y = 'abc') Integer :: x(n:n+1) Parameter(x=[1,2]) This is not valid Fortran 2003, because 5.2 contains the requirement: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. This also applies to PROCEDURE, EXTERNAL, and INTRINSIC statements." This requirement does not appear in F2008. However, there is no indication in the Introduction of this new feature. Is this extension to Fortran 2003 deliberate? ANSWER: (1) Yes, the type declaration statement was intended to be allowed. An edit is supplied to correct this mistake. (2) No, the omission of this requirement was inadvertent. An edit is supplied to correct this mistake. EDITS: [88:14] In 5.2.1, Replace constraint "C507 (503)" completely with "C507 (R501) If the PARAMETER keyword appears, shall appear in each ." {Fix Q1.} [88:14+] In 5.2.1, immediately after constraint C507, insert new constraint: "C507a An expression that specifies a length type parameter or array bound of a named constant shall be a constant expression." {Fix Q2.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-189 m199 F08/0085 submitted 12-189r1 m199 Passed by J3 meeting 13-237 m200 Failed as amended by J3 letter ballot #27 13-203 13-239 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0086 TITLE: Implied-shape and separate PARAMETER statement KEYWORDS: Implied-shape, PARAMETER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Program test1 Character(*) a,b(*) Dimension c(*) Parameter (a='123', b=['1','2','3']) Character(*),Parameter :: c = [ '44','55','66' ] Print *,a,b,c End The definition of the assumed-length character named constant A conforms to Fortran 77 to Fortran 2008. However, the definition of the implied-shape named constant B appears not to conform to Fortran 2008, as the standard says in 5.4.11p2 "A named array constant defined by a PARAMETER statement shall have its shape specified in a prior specification statement." On the other hand, the named constant C does not have such a requirement, so its definition would appear to be conforming. This apparent requirement on the named constant B would thus appear to be inconsistent with those on the named constant C, as well as inconsistent with the way that assumed length works, and with the general principle of allowing attributes to be specified either in a single type declaration statement or with separate specification statements. Is the program intended to conform to the Fortran standard? Q2. Consider Subroutine test2(a) Real,Dimension(*) :: a,c Parameter (c = [ 45.6 ]) a(:size(c)) = c End Subroutine The in the type declaration statement is ambiguous; if it is an then the declaration of A as an assumed-size array is erroneous, but if it is an then the declaration of C as an implied-shape array is erroneous. Is this program-unit intended to be standard-conforming? ANSWER: A1. Yes, the program was intended to conform to the Fortran standard. An edit is provided to modify the requirement for prior specification so as to allow this case. A2. Yes, the program is intended to conform to the Fortran standard. An edit is provided to add syntax to permit this unambiguously. EDITS to 10-007r1: [94:10] 5.3.8.1, R515, Change "" to "". {This will be the unambiguous implied-shape syntax.} [94:10+] Insert new production "<> ". {This will be the otherwise-ambiguous syntax.} [95:32] 5.3.8.5p1 Replace sentence "An assumed-size array is declared with an ." with "A dummy argument is declared to be an assumed-size array by an or an ." {Now two ways of declaring assumed size.} [95:33-] Insert new BNF term "R520a <> [ : ] *" [95:33] R521 , after "<>" Replace entire RHS "[ , ]... [ : ] *" with ", " {The unambiguous case has a list of s.} [95:37+] Insert new BNF rules and constraint "R521a <> C534a An object whose array bounds are specified by an shall be a dummy data object or a named constant." {The otherwise-ambiguous case. Note careful wording.} [96:24-25] 5.3.8.6p1 Replace sentence "An implied-shape array is declared... ." with "A named constant is declared to be an implied-shape array with an that is an or an ." {Now two ways of declaring implied shape.} [96:26] R522, Replace right-hand-side (after "<>") "[ : ] *" with ", ". {This is now the unambiguously implied-shape spec.} [96:28] p2, Change "s" -> "s" and "the " -> "its ", making the entire paragraph read: "The rank of an implied-shape array is the number of s in its ." {Change rank determination to accord with new syntax term.} [107:11] 5.4.11p1 "shape" -> "rank". {In the PARAMETER statement, only require the rank to be specified in a prior specification statement.} NOTE for future investigation: The current wording of C533 is slightly defective, as it does not clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as how that does indeed declare "the array bounds of a dummy data object". C533 should probably be reworded similarly to C534a. SUBMITTED BY: Bill Long HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm Cohen - passed by J3 meeting 13-237 m200 Failed letter ballot 13-235 m200 Revised with straw votes 13-235r1 m200 Passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ** Revised edits from draft corrigendum ballot - replace entire interp ---------------------------------------------------------------------- NUMBER: F08/0087 TITLE: Mixed-kind character assignment KEYWORDS: Mixed kind, character assignment DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: For a processor that supports both ASCII and ISO 10646 UCS-4 character kinds, assuming without loss of generality that Selected_Char_Kind('ASCII') is equal to 1 and that Selected_Char_Kind('ISO_10646') is equal to 10646, consider the following program: Module charkinds Integer,Parameter :: ascii = 1 Integer,Parameter :: ucs4 = 10646 End Module Module overload Use charkinds Interface Assignment(=) Module Procedure char_asg End Interface Contains Subroutine char_asg(a,b) Character(*,ascii),Intent(Out) :: a Character(*,ucs4),Intent(In) :: b Do i=1,Min(Len(a),Len(b)) a(i:i) = Achar(Mod(Iachar(b(i:i))+1,127)) End Do a(i:) = Repeat('*',Len(a)-Len(b)) End Subroutine End Module Program test Use overload Character(10,ascii) x x = ucs4_'Hello' Print *,'"',x,'"' End Program This program conforms to Fortran 95, which permitted user-defined assignment between all characters with different kinds. However, Fortran 2008 provides intrinsic assignment between ISO 10646 characters and ASCII characters, so user-defined assignment is not permitted (12.4.3.4.3 and Table 7.8). Thus there seems to be a contradiction between the Fortran 95 compatibility description in 1.6.3 and 12.4.3.4.3. Is the program intended to conform to Fortran 2008? And if it does, does it print "Hello " (intrinsic assignment) "Ifmmp*****" (user-defined assignment)? ANSWER: The program was not intended to conform to the standard. An edit is provided to remove the contradiction. EDITS: [24:14] 1.6.3p1, "Any" -> "Except as identified in this subclause, any". {No longer true.} [24:15] Split the sentence "The ..." introducing the list into a separate paragraph (which will be the third paragraph), and insert a new paragraph (as the second paragraph) as follows: "Fortran 95 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} [25:2+] 1.6.4, after p3, insert a new paragraph. "Fortran 90 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} SUBMITTED BY: Van Snyder HISTORY: 13-204 m200 F08/0087 submitted 13-204r1 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0088 TITLE: Can ALLOCATE with SOURCE= have side-effects in a PURE proc? KEYWORDS: Allocate, SOURCE=, PURE, side-effects DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: On comp.lang.fortran Ian Harvey brought up a pointer/PURE question. Given a type definition like type :: int_ptr integer, pointer :: i end type int_ptr And a PURE function like PURE function FUN (arg) type(int_ptr), intent(in) :: arg type(int_ptr), allocatable :: tmp FUN = 1 allocate (tmp, source=arg) tmp%i = 2 end function fun Is FUN standard conforming? Doesn't the use of source=arg allow the function to modify a global entity via the tmp%i = ...? There don't seem to be any constraints on what arg%i can point to, which means that the assignment to tmp%i can have side effects. Note that C1283(1) prevents usage like arg%i = 2 ANSWER: This was not intended to be standard-conforming. An edit is supplied to remedy this oversight. EDITS: [312:37] In C1283, delete "or" and add a new item "(4a) as the in a SOURCE= clause if the designator is of a derived type that has an ultimate pointer component, or" SUBMITTED BY: Dick Hendrickson HISTORY: 13-226 m200 F08/0088 submitted 13-226r1 m200 Edits added - passed by J3 meeting 13-262 m201 Passed J3 leter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0090 TITLE: What restrictions apply to initialization and PARAMETER? KEYWORDS: PARAMETER, initialization, conformable, type conversion DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider the programs Program m200c3_1 Integer :: a(10,10) Parameter (a = [ (i,i=1,100) ] ) Print *,a End Program Program m200c3_2 Parameter (b = 'ok') Print *,b End Program Program m200c3_3 Integer :: x(23) = [ 1 ] Print *,x End Program Program m200c3_4 Integer :: y = 'ok' Print *,y End Program The PARAMETER statement for the named constant A has an expression whose shape does not conform with that of A. The PARAMETER statement for the named constant B has an expression whose type does not conform to that of B. The for X is not conformable in shape. The for Y is not conformable in type. There appears to be no requirement either for shape or type conformance, in Fortran 2008 or in previous Fortran standards, except for initializing data pointers. Q1. Do any of these programs conform to Fortran 2008? Q2. If there is meant to be a requirement for the shapes to conform or for the types to be convertible, should this not be a constraint? ANSWER: A1. No, these programs do not conform to Fortran 2008, as no interpretation is established for any of them. Edits are provided to clarify this. A2. This is not a constraint. A future revision of Fortran might choose to mandate diagnosis of these errors. EDIT to 10-007r1: [88:30+] 5.2.1 Syntax, Insert new paragraph at end of subclause "If appears for a nonpointer entity, - its type and type parameters shall conform as specified for intrinsic assignment (7.2.1.2); - if the entity has implied shape, the rank of shall be the same as the rank of the entity; - if the entity does not have implied shape, shall either be scalar or have the same shape as the entity.". [107:12+] 5.4.11 PARAMETER statement, after p2, Insert new paragraph "The constant expression that corresponds to a named constant shall have type and type parameters that conform with the named constant as specified for intrinsic assignment (7.2.1.2). If the named constant has implied shape, the expression shall have the same rank as the named constant; otherwise, the expression shall either be scalar or have the same rank as the named constant.". SUBMITTED BY: Malcolm Cohen HISTORY: 13-229 m200 F08/0090 submitted - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N2004 m203 In F2008 Corrigendum 3 N2002 ------------------------------------------------------------------------ NUMBER: F08/0091 TITLE: Derived type with no components KEYWORD: Derived type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Program m7_1 Type empty End Type Type(empty),Target :: x Type(empty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? According to 16.5.3.2p2, item 1 is default integer etc, N/A item 2 is double precision etc, N/A item 3 is default character, N/A item 4 is C character, N/A item 5 is SEQUENCE type, N/A According to item (6), "a nonpointer scalar object of any type not specified in items (1)-(5) occupies a single unspecified storage unit that is different [from everything else]" If that analysis is correct, X occupies a single unspecified storage unit, not zero storage units, and therefore T should be printed. Q2. Consider Program m7_2 Type sempty Sequence End Type Type(sempty),Target :: x Type(sempty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? Now X falls into item 5, which makes it a "sequence of storage sequences corresponding to the sequence of its ultimate components"; there are no ultimate components, this makes it a zero-sized storage sequence and therefore F should be printed. This does not seem to be consistent with the apparent answer to Q1. Q3. Consider Program m7_3 Type numeric_empty Sequence End Type Type character_empty Sequence End Type Type(numeric_empty) a Integer b Character c Type(character_empty) d Equivalence(a,b) ! E1. Equivalence(c,d) ! E2. End Is this program conforming? According to the definitions in 4.5.2.3, NUMERIC_EMPTY is a numeric sequence type and therefore one might expect to be able to EQUIVALENCE it to an INTEGER. Similarly, CHARACTER_EMPTY is a character sequence type and therefore one might expect to be able to EQUIVALENCE it to a CHARACTER. However, NUMERIC_EMPTY is clearly also a character sequence type, and therefore statement E1 violates C592 because B is not character or character sequence. Similarly, CHARACTER_EMPTY is clearly also a numeric sequence type, and therefore statement E2 violates C591. It seems very strange to have a type that is simultaneously numeric and character sequence type. Q4. Consider Program m7_4 Type numeric_empty_2 Sequence Real c(0) End Type Type character_empty_2 Sequence Character(0) c End Type Type(numeric_empty_2) a Integer b Character c Type(character_empty_2) d Equivalence(a,b) ! E3. Equivalence(c,d) ! E4. End Does this program conform? According to the definitions in 4.5.2.3, NUMERIC_EMPTY_2 is a numeric sequence type and not a character sequence type, and conversely CHARACTER_EMPTY_2 is a character sequence type and not a numeric sequence type, and therefore the constraints for the statements at E3 and E4 are not violated. Thus this appears to be conforming, in contradiction to the example in Q3, even though the storage sequence of NUMERIC_EMPTY, NUMERIC_EMPTY_2, CHARACTER_EMPTY, and CHARACTER_EMPTY_2 are all the same. This does not look very consistent with the situation in Q3. ANSWER: A1. The program is conforming and prints T. A2. The program was not intended to conform; SEQUENCE makes no sense when there are no components. An edit is needed to correct this. A3. The program does not conform as a sequence type must have at least one component. A4. The program is conforming. The apparent design inconsistency is not an error in the standard. EDIT to 10-007r1: [62:19] 4.5.2.3, in constraint C436 After "appears," insert "the type shall have at least one component,". SUBMITTED BY: Malcolm Cohen HISTORY: 13-266 m201 F08/0091 submitted 13-266r1 m201 Revised - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0092 TITLE: Derived type parameter requirements KEYWORD: Derived type parameter DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider Type t1(a,a) Integer,Kind :: a Integer,Len :: a End Type Type t2(a) Integer,Kind :: a,a,a End Type These type definition appears to valid, in that (a) there is no requirement that a type parameter appears only once in the ; (b) there is no requirement that a type parameter appears in only one , and only once. Were these intended to be valid? What is their meaning? ANSWER: These were not intended to be valid, and they are not valid because the standard does not establish an interpretation for them. Unique names for type parameters can possibly be deduced from the scoping rules. Edits are supplied to make the requirements explicit. EDITS to 10-007r1: [61:19+] In 4.5.2.1, after C427 insert new constraint "C427a (R426) The same shall not appear more than once in a ." {Require unique names for type parameters.} [64:8] In 4.5.3.1, C438, after "shall appear" insert "exactly once". {Forbid multiple declarations of a type parameter, whether in the same or more than one.} SUBMITTED BY: Malcolm Cohen HISTORY: 13-267 m201 F08/0092 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0093 TITLE: Process exit status and error termination KEYWORD: ERROR STOP DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Many operating systems today (e.g. Posix-related ones) use a process exit status of zero to indicate successful execution, whereas nonzero indicates an error. (Occasionally nonzero values, e.g. 1, also indicate success.) Fortran STOP and ERROR STOP with an integer are recommended to use the as the exit status. The STOP statement without an integer is recommended to have an exit status of zero; this conforms to common practice since STOP initiates normal termination. The standard is silent on the effect of error termination, except in the case of an ERROR STOP (sans integer ) which is unexpectedly recommended to also return an exit status of zero. Q1. Is this intentional? Should the exit code for ERROR STOP not have been recommended to be nonzero? Q2. Should the recommendation for an ERROR STOP not also apply to error termination by other causes? ANSWER: A1. It was not intended to recommend returning "success" for error termination. An edit is supplied to correct this. A2. Yes, the recommendation for an ERROR STOP without an integer should also apply to other means of standard-defined error termination. An edit is supplied to correct this omission. EDIT to 10-007r1: [33:36+] 2.3.5, before Note 2.7, insert new note "NOTE 2.6a If the processor supports the concept of a process exit status, it is recommended that error termination initiated other than by an ERROR STOP statement supplies a processor-dependent nonzero value as the process exit status." {Recommendation for error termination other than by ERROR STOP.} [188:10+10] In 8.4, Note 8.30, Before "is of type character or does not appear" Insert "in a STOP statement". {Limit zero recommendation to STOP, not ERROR STOP.} [188:10+11+] At the end of Note 8.30, insert a new paragraph "If the in an ERROR STOP statement is of type character or does not appear, it is recommended that a processor-dependent nonzero value be supplied as the process exit status, if the processor supports that concept." {Specify nonzero exit for ERROR STOP.} [459:17+] After the bullet item "how soon an image terminates if another image initiates error termination (2.3.5);" Insert new bullet point "the recommended process exit status when error termination is initiated other than by an ERROR STOP statement with an integer (2.3.5);" {Probably unnecessary, seeing how it is only a recommendation, but maybe a good idea anyway.} SUBMITTED BY: Bill Long/Malcolm Cohen HISTORY: 13-268 m201 F08/0093 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed as amended by WG5 ballot 7, N1992 ** [460:24+] moved to [459:17+] N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0094 TITLE: Procedure statement and double colon KEYWORD: PROCEDURE, Interface block DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Fortran 2003 did not permit a double colon in the in an interface block. Fortran 2008 syntax seems to allow this, but it is not mentioned in the Introduction as a new F2008 feature. Is this apparent new feature deliberate? ANSWER: Yes, this new feature was intended. An edit is provided to add mention of it to the Introduction. EDIT: [xvi] Introduction, p2, "Programs and procedures:" bullet, After "empty CONTAINS section is allowed." Insert "A PROCEDURE statement can have a double colon before the first procedure name." SUBMITTED BY: Malcolm Cohen HISTORY: 13-274 m201 F08/0094 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0095 TITLE: Is PRESENT allowed in specification and constant expressions KEYWORD: PRESENT, optional dummy argument DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Subroutine s1(a) Integer,Optional :: a Logical,Parameter :: x = Present(a) Print *,x End Subroutine Does this program unit conform to the standard? 7.1.12 item (4) permits "a specification inquiry where each designator or function argument is ... (b) a variable whose properties inquired about are not (i) assumed, (ii) deferred, or (iii) defined by an expression that is not a constant expression," PRESENT is a specification inquiry (because it is an intrinsic inquiry function), and the standard does not say that the "presence" of an optional dummy argument is an assumed or deferred attribute, and it does not appear to be "defined by an expression" either. On the other hand, the standard does not say anything about what kind of property the presence is. Q2. Consider Subroutine s2(a) Integer,Optional :: a Real x(Merge(2,3,Present(a))) If (Present(a)) Then x = [ 1,2,a ] Else x = [ 1,2 ] End If Print *,x End Subroutine Does this program unit conform to the standard? It appears to satisfy the rules for specification expression, similarly to how it satisfies the rules for a constant expression, but then the standard is silent as to what sort of property "presence" is... Q3. Consider Subroutine s3(a) Character(*),Optional :: a Real x(Len(a)) Print *,Size(x) End Subroutine Does this program unit conform to the standard? Using the same reasoning as Q1 and Q2, it appears to conform, but if A is absent, LEN(A) is not permitted by 12.5.2.12. ANSWER: A1. Program unit S1 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. A2. Program unit S2 was intended to conform to the standard. An edit is provided to clarify that this is valid. A3. Program unit S3 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. EDITS to 10-007r1: [150:24] 7.1.11p2, item (9)(b) after "variable" insert ",that is not an optional dummy argument, ". {Prevent specification enquiries on optional dummy arguments.} [150:27+] 7.1.11p2, after item (9) entirely, insert "(9a) a specification inquiry that is a constant expression, (9b) a reference to the intrinsic function PRESENT," {Allow inquiries on optional dummy arguments that will not violate the rules in 12.5.2.12 when the dummy is absent, and allow PRESENT to be used.} [150:37] 7.1.11p4, item (1) after "intrinsic inquiry function" insert "other than PRESENT". {Remove PRESENT from list of specification inquiries, this fixes constant expressions.} SUBMITTED BY: Malcolm Cohen/Van Snyder HISTORY: 13-278 m201 F08/0095 submitted 13-278r1 m201 Passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0096 TITLE: Is VALUE permitted for an array in a BIND(C) procedure? KEYWORD: array, BIND(C), VALUE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider INTERFACE SUBROUTINE s(a) BIND(C) USE ISO_C_BINDING REAL(C_float),VALUE :: a(100) END END INTERFACE Q1. Does this interface conform to the Fortran standard? Q2. If so, what prototype does it interoperate with? ANSWER: A1. C does not have arrays that are passed by value, so this was not intended to conform to the Fortran standard. An edit is provided to clarify this. A2. This question is moot. EDITS to 10-007r1: [306:31] 12.6.2.2, C1255, after "(15.3.5, 15.3.6)" insert "that is not an array with the VALUE attribute," {Do not permit BIND(C) to have arrays by value.} {Note: TS 29113 replaces this same constraint.} [433:12] 15.3.7p2, item (4), after "any" insert "scalar". {Do not describe arrays by value in a prototype.} SUBMITTED BY: Malcolm Cohen HISTORY: 13-284 m201 F08/0096 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0097 TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)? KEYWORD: TYPE, CHARACTER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider CHARACTER*1, A TYPE(CHARACTER*1,) B The optional comma in the declaration of B looks ugly. Is this deliberate? ANSWER: No, this syntax was inadvertently allowed. An edit is provided to remove it. EDITS to 10-007r1: [51:26+] 4.3.1.1, after C406, insert new constraint "C406a (R403) In TYPE() the shall not end with a comma." SUBMITTED BY: Malcolm Cohen HISTORY: 13-285 m201 F08/0097 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0098 TITLE: How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? KEYWORD: LOCK DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider LOCK ( x, ACQUIRED_LOCK=n1, ACQUIRED_LOCK=n2, STAT=n3, STAT=n4 ) Is this conforming? Multiple STAT= are prohibited from a , but this is a so that does not apply. There is no constraint anywhere about how many ACQUIRED_LOCK= specifiers may appear. ANSWER: No, this was not intended to be conforming. No specifier was intended to be allowed to appear more than once. EDITS to 10-007r1: [194:2+] 8.5.6, after R864, insert new constraint "C852a No specifier shall appear more than once in a given ." SUBMITTED BY: Malcolm Cohen HISTORY: 13-286 m201 F08/0098 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N2004 m203 In F2008 Corrigendum 3 N2002 ---------------------------------------------------------------------- NUMBER: F08/0099 TITLE: VOLATILE in specification expressions KEYWORD: VOLATILE, specification expression DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: Is the following subprogram required always to print "T T"? subroutine Wobbly ( N ) integer, volatile :: N integer :: A ( n, n ) integer :: B ( n * n ) print *, size(a) == size(b), size(a,1) == size(a,2) end subroutine Wobbly ANSWER: No. There are three specification expressions in the subroutine, and the volatile variable N appears in each of them. Since, being volatile, the variable N might have a different value each time it is referenced, these three specification expressions might receive different values for their references to N. If that happens, the array sizes might well be different. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 13-298r1 m202 F08/0099 submitted 13-298r2 m202 Revised answer - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Q1. Does the following program fragment conform to the 2008 standard? subroutine S ( P ) interface subroutine Q ( X ) real, intent(inout) :: X end subroutine Q end interface interface subroutine P ( A ) import procedure (R) :: A end subroutine P end interface procedure (Q) :: R end subroutine S 12.4.3.3p2 says "If an entity that is made accessible by this means is accessed by host association and is defined in the host scoping unit, it shall be explicitly declared prior to the interface body." However, although the procedure R is declared in the host scoping unit it is not defined in the host scoping unit, so this is ineffective. Q2. If the IMPORT statement were changed to "IMPORT R", would that be conforming? 12.4.3.3p1 says "An entity that is imported in this manner and is defined in the host scoping unit shall be explicitly declared prior to the interface body." Again, procedure R is declared but not defined in the host scoping unit, so this requirement is ineffective. ANSWER: These examples were not intended to conform to the Fortran standard. An edit is provided. EDITS to 10-007r1: [282:7] 12.4.3.3p1, after "imported in this manner and is" change "defined" to "declared". [282:14] p2, after "is accessed by host association and is" change "defined" to "declared". SUBMITTED BY: Van Snyder HISTORY: 13-305 m202 F08/0100 submitted 13-305r1 m202 Revised answer & edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Program p1 Real :: x = 3, y = 4 Namelist /n/ x, y Write (*,n) End Program According to 5.6, "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, this stops short of saying that the order is the same, merely that it determines it. Perhaps it might be standard-conforming for a processor to always produce the values in reverse order, for example. 10.11.4 does not seem to address the issue of what the order is. Q1: Is the order meant to be the same? Consider Program p2 Real :: x = 3, y = 4 Namelist /n/ x, y, x Write (*,n) End Program This program did not conform to Fortran 90, but does conform to Fortran 2003 and later. The Fortran 2008 standard says (5.6p2): "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, there are only two variables in the NAMELIST statement, X and Y. Therefore it seems to be ambiguous whether the output should be something like &N X=3 Y=4 / or &N Y=4 X=3 / Some compilers produce &N X=3 Y=4 X=3 / but this is not an ordering of the variables X and Y. Q2. Is this program intended to conform to the standard, and if so, what is the intended output? ANSWER: A1. Yes, the order is meant to be the same. An edit is supplied to clarify this. A2. The program was intended to conform to the standard, and the output was intended to be the third option. An edit is supplied to correct the text in 5.6. EDITS to 10-007r1: [111:13-14] 5.6p2, replace entire paragraph with "The order in which the values appear on output is the same as the order of the s in the namelist group object list; if a variable appears more than once as a for the same namelist group, its value appears once for each occurrence". SUBMITTED BY: Malcolm Cohen HISTORY: 13-314 m202 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Program test Type t End Type Type,Extends(t) :: t2 End Type Class(t),Allocatable :: x,y Type(t),Allocatable :: a x = t() y = t2() a = t() Do i=1,2 Select Type (z=>Merge(a,x,i==1)) ! A Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(x,a,i==1)) ! B Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(a,y,i==1)) ! C Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(y,a,i==1)) ! D Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(x,y,i==1)) ! E Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do End Program According to the standard, the type of the result of MERGE is the same as the type of TSOURCE. One might imagine that this means that the result is polymorphic if and only if TSOURCE is polymorphic. This would be a slightly unusual and unexpected asymmetry. Also, the types of FSOURCE and TSOURCE have to be the same. If this means both the declared and dynamic types, one might imagine that this means that the result is polymorphic if and only if both FSOURCE and TSOURCE are polymorphic, since otherwise the non-polymorphic argument decides the type. On the other hand, if the type requirements are talking about the declared type only, one might imagine that the result is polymorphic if either TSOURCE or FSOURCE is polymorphic. However, in any case there would seem to be an error in the standard, since the result is specified to be the same as TSOURCE, rather than the same as whichever argument is chosen to be the result value; if this refers to the dynamic type, it is contradictory when FSOURCE is chosen as the result value. And if it does not refer to the dynamic type, there appears to be no statement which says what the dynamic type of the result is. Q1. Is the apparent asymmetry between the treatment of TSOURCE and FSOURCE intended? Q2. Which of the MERGE invocations A-E are polymorphic? Q3. When the result of MERGE is polymorphic, are the dynamic types of TSOURCE and FSOURCE permitted to be different? And if they are, is the dynamic type of the result the same as the chosen argument and not necessarily the same as TSOURCE? ANSWER: A1. There is no asymmetry between TSOURCE and FSOURCE, because they are required to have the same type and type parameters. This means that both the declared and dynamic types and type parameters must be the same. A2. Only MERGE invocation E is polymorphic. An edit is provided to clarify this. A3. No, the dynamic types and type parameters are required to be the same. Note that because MERGE is elemental, it needs the type and type parameters to be the same for both the declared and dynamic types, otherwise the principle that all elements of an array have the same (declared and dynamic) type and type parameters would be broken. EDITS to 10-007r1: [368:26] 13.7.110p4 (Result Characteristics), "Same as TSOURCE." -> "Same type and type parameters as TSOURCE. Because TSOURCE and FSOURCE are required to have the same type and type parameters (for both the declared and dynamic types), the result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." SUBMITTED BY: Malcolm Cohen HISTORY: 13-321 m202 F08/0102 submitted 13-321r1 m202 Revised example - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0103 TITLE: Pointers to internal procedures with different host instances KEYWORD: internal procedure, procedure pointer, host instance DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider: MODULE TYPES ABSTRACT INTERFACE SUBROUTINE SUBROUTINE() END SUBROUTINE SUBROUTINE END INTERFACE TYPE PPS PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR END TYPE PPS END MODULE TYPES SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTEGER I, J, N N = SIZE(PPA) DO I = 1, N CALL PPA(I)%SU_PTR() END DO PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N) END SUBROUTINE CPPS RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTERFACE SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE CPPS END INTERFACE IF (SIZE(PPA) .EQ. 3) THEN CALL CPPS(PPA) ELSE CALL OUTER( (/ PPA, PPS(INNER) /) ) END IF CONTAINS SUBROUTINE INNER() WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA) END SUBROUTINE INNER END SUBROUTINE OUTER PROGRAM MAIN USE TYPES INTERFACE RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE OUTER END INTERFACE TYPE(PPS),DIMENSION(0) :: PPA CALL OUTER(PPA) END PROGRAM MAIN Does this program print all true values? The procedure pointers are all associated with the internal procedure INNER, which might lead one to believe that the answer is yes (that is, they are all associated with the same target), but each procedure pointer at each nesting level has a different host instance, which might lead one to believe that the answer is no (and that therefore only one of each of the 3-element sequences printed will be T). ANSWER: No, the program does not print all true values; two procedure pointers to the "same" internal procedure are only associated if the host instances are also the same. An edit is supplied to the standard to clarify this. EDITS to 10-007r1: [330:20] 13.7.16p5 Case (ii), after "with TARGET" insert "and, if TARGET is an internal procedure, they have the same host instance". [330:22] Case (iii), after "same procedure" insert "and, if the procedure is an internal procedure, they have the same host instance". SUBMITTED BY: Robert Corbett HISTORY: 13-357 m202 F08/0103 submitted with four answers 13-357r1 m202 Selected answer, added edits - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 All references are to Fortran 2008 10-007r1. On comp.lang.fortran Francis Coudert asked The Fortran 2008 standard defines an inquiry function as an "intrinsic function, or function in an intrinsic module, whose result depends on the properties of one or more of its arguments instead of their values". 10-007r1 section 1.3.89 [11:27-30] I wonder: by that definition, how can the IEEE_SUPPORT_HALTING(FLAG) function from the IEEE_EXCEPTIONS intrinsic module be an inquiry function? Its result depends on the value of FLAG, not its properties. QUESTIONS: Question 1. Are the functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc intended to be inquiry functions? Question 2. Are they consistent with the definition of inquiry functions? Question 3. Are they allowed in Specification expressions? Question 4. Are they allowed in Constant expressions? ANSWERS: Answer 1. No. These intrinsic module functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc are not inquiry functions because their results depend on other than the properties of their arguments. Edits are provided to correctly identify these functions as transformational: [18:35-37] section 1.3.146 transformational function intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function Answer 2. No. Their current classification is inconsistent with the definition of inquiry functions. Answer 3. They should be allowed in specification expressions. Edits are provided to correct this. Answer 4. No. Only the 3 IEEE_* functions should be allowed in constant expressions, not the 3 C_* functions. Edits are provided to correct this. EDITS to 10-007r1: [150:28+] section 7.1.11 Specification expression, paragraph 2, after item (10), insert a new item: "(10a) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC (14), IEEE_EXCEPTIONS (14), or ISO_C_BINDING (15.2), where each argument is a restricted expression," [152:7-8] section 7.1.12 Constant expression, paragraph 1, replace item (8): "(8) a reference to the transformational function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE ARITHMETIC (14), where each argument is a constant expression," with: "(8) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant expression," [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.1, for procedure IEEE_SUPPORT_ROUNDING: change the "Class" column entry from "I" to "T". [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.2, for procedures IEEE_SUPPORT_FLAG and IEEE_SUPPORT_HALTING: change the "Class" column entries from "I" to "T". [418:16] section 14.11.27 IEEE_SUPPORT_FLAG (FLAG) or IEEE_SUPPORT_FLAG (FLAG, X), paragraph 2: "Inquiry function." -> "Transformational function." [418:32] section 14.11.28 IEEE SUPPORT HALTING (FLAG), paragraph 2: "Inquiry function." -> "Transformational function." [420:4] section 14.11.32 IEEE_SUPPORT_ROUNDING (ROUND_ VALUE) or IEEE_SUPPORT_ROUNDING (ROUND_VALUE, X), paragraph 2: "Inquiry function." -> "Transformational function." [426:19] section 15.2.3.2 C_ASSOCIATED (C_PTR_1 [, C_PTR_2]), paragraph 2: "Inquiry function." -> "Transformational function." [428:9] section 15.2.3.5 C_FUNLOC (X), paragraph 2: "Inquiry function." -> "Transformational function." [428:21] section 15.2.3.6 C_LOC (X), paragraph 2: "Inquiry function." -> "Transformational function." SUBMITTED BY: Dick Hendrickson HISTORY: 14-100 m203 F08/0104 submitted 14-100r1 m203 Answer proposed 14-100r2 m203 Passed by J3 meeting 14-192 m204 Passed as amended by J3 letter ballot 14-146 N2047 m206 Passed as amended by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute is not argument associated with the corresponding actual argument. Rather, it is associated with an anonymous data object whose value is copied from the actual argument before execution of the executable constructs of the subprogram commences, and before expressions in the specification part are evaluated. Therefore, it can successfully take part in asynchronous operations that both start and complete within that procedure call, independently of whether the corresponding actual argument has or has not the ASYNCHRONOUS attribute. There is no problem if a dummy argument has the VALUE attribute and the corresponding actual argument has the ASYNCHRONOUS attribute, independently of whether the dummy argument has the ASYNCHRONOUS attribute. Subclause 9.6.4.1, paragraph 6 [220:13-15], prohibits an actual argument that is part of a pending input storage sequence affector from being associated with a dummy argument that has the VALUE attribute. EDITS to 10-007r1: None. SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting 14-192 m204 Failed J3 letter ballot #30 14-146 14-269 m205 Revised answer - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Was it intended that MOVE_ALLOC can affect the allocation status of an array on an image other than the executing image? An example is F CALL MOVE_ALLOC(A,B[I]%A) ANSWER: No, it was not intended that the executing image can affect the allocation status of an array on an image other than the executing image. Edits are provided to correct this. EDITS to 10-007r1: 13.7.118 MOVE_ALLOC(FROM,TO), para 3: [372:18] In the description of FROM, after "It shall be allocatable", add "and shall not be a coindexed object". [372:19] In the description of TO, after "It shall be allocatable", add "and shall not be a coindexed object". SUBMITTED BY: John Reid HISTORY: 14-119 m203 F08/0106 submitted - passed by J3 meeting 14-192 m204 Passed by J3 letter ballot 14-146 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0108 TITLE: ultimate components and coarrays KEYWORD: ultimate components, coarrays DEFECT TYPE: Interpretation STATUS: In F2008 Corrigendum 4 QUESTIONS: 1. Is the declaration of V permitted: type :: one real, allocatable :: C[:] end type one type :: two type(one), allocatable :: A end type two type(two), pointer :: V(:) 2. Is the declaration of X permitted: type :: three real :: C end type three type :: four type(three), allocatable :: A[:] end type four type(four) :: X ANSWERS: 1. Type two is not conforming, because the entity A has a coarray ultimate component and C525 requires such an entity to be a nonpointer nonallocatable scalar. Therefore the declaration of V is not permitted. 2. X satisfies C525, so declaration of X is permitted. X has an ultimate (allocatable) coarray component (A[:]), and therefore according to C526 must be a dummy argument or have the SAVE attribute. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 14-163 m204 F08/0108 submitted 14-163r1 m204 Fixed examples in questions, revised answer - passed by J3 meeting 14-258 m205 Passed as amended by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0109 TITLE: LOCK_TYPE and unlimited polymorphic KEYWORD: LOCK_TYPE, unlimited polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is available. Q1. Is allocation of X%C permitted? TYPE t TYPE(LOCK_TYPE),ALLOCATABLE :: c END TYPE TYPE(t) :: x[*],y[*] ALLOCATE(y%c) ALLOCATE(x%c,SOURCE=y%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=L ) Q3. Is allocation of C permitted? class(*), pointer :: C allocate ( LOCK_TYPE :: C ) Q4. Is pointer assignment to C permitted? class(*), pointer :: C type(lock_type), intent(in), target :: L[*] c => L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE, SAVE :: C[:] TYPE(LOCK_TYPE), SAVE :: X[*] ALLOCATE(C[*],MOLD=X) ANSWER: A1. Allocation of X%C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A2. Allocation of C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A3. This allocation of C is permitted. It cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. Edits are given to fix C1302 to say "declared type" explicitly to avoid this confusion. Note that it is impossible to actually use the allocated target of C in any useful fashion; SELECT TYPE cannot access it because the associate-name would be a named lock variable, but it is not a coarray so that would not be allowed. So this is permitted, but useless, and because it is useless it is also harmless. A future revision could disallow this without the concomitant incompatibility inconveniencing any programs. A4. Pointer assignment to C is permitted. As in A3, this is useless but harmless. A future revision could disallow this without the concomitant incompatibility inconveniencing any programs. A5. This statement was intended to be permitted. An edit is supplied to correct the requirements. Note that the term "potential subobject component" is defined in interp F08/0124 and will be in F2008 Corrigendum 4: [6:7+] After definition 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component". EDITS to 10-007r1: [127:8-9] 6.7.1.1 Syntax, C642, Change "C_PTR," to "C_PTR or" Delete ", LOCK_TYPE ... LOCK_TYPE". [127:9+] Insert new constraint "C642a (R627) If SOURCE= appears, the declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." [127:18-19] 6.7.1.1, p4, Instead of the edit in Corr. 2, make this change to the 10-007r1 text: Change "If is" -> "If an ALLOCATE statement has a SOURCE= specifier and an that is". {There is no problem with MOLD=. "subcomponent" works ok here because we have an object not a type.} so p4 reads: "If an ALLOCATE statement has a SOURCE= specifier and an that is a coarray, shall not have a dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a subcomponent whose dynamic type is LOCK_TYPE." [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK_TYPE" -> "variable with declared type LOCK_TYPE". SUBMITTED BY: Van Snyder HISTORY: 14-164 m204 F08/0109 submitted 14-164r3 m204 As amended, passed by J3 meeting 14-258 m205 Failed the J3 letter ballot #31 14-233r1 15-253 m208 Revised - passed by J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed as amended by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 --------------------------------------------------------------------- NUMBER: F08/0112 TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider CHARACTER(80) text(0:100), msg INTEGER stat,istat(0:80) REAL,ALLOCATABLE :: x(:),y(:,:) ... ALLOCATE(x(10),STAT=stat,ERRMSG=text(stat)) ! A DEALLOCATE(x,STAT=stat,ERRMSG=text(stat)) ! B msg = '' ALLOCATE(y(999999,999999),STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! C msg = '' DEALLOCATE(x,STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! D In each of the statements labelled A-D, there is a dependency between the STAT= specifier and the ERRMSG= specifier (from STAT= to ERRMSG= in A and B, and from ERRMSG= to STAT in C and D). There appears to be no prohibition against this (though there are many prohibitions against other dependencies in ALLOCATE and DEALLOCATE). Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: These are not standard-conforming, as no interpretation is established for them. An edit is supplied to clarify this prohibition. EDITS to 10-007r1: [132:4] 6.7.4 STAT= specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG= specifier, p1, append "The shall not depend on the value of the .". SUBMITTED BY: Malcolm Cohen HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting 14-258 m205 Passed by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0113 TITLE: Specifiers in image control statements KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider CHARACTER(80) text(0:100),msg INTEGER stat,istat(2) REAL,ALLOCATABLE :: x(:) TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*] LOGICAL acq, aacq(0:80) ... SYNC ALL(STAT=stat,ERRMSG=text(stat)) ! A SYNC IMAGES (*,STAT=stat,ERRMSG=text(stat)) ! B SYNC MEMORY(STAT=stat,ERRMSG=text(stat)) ! C LOCK(lock,ACQUIRED_LOCK=acq, & STAT=istat(MERGE(1,2,acq)), & ERRMSG=text(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=stat,ERRMSG=text(stat)) ! E LOCK(alock(stat),STAT=stat) ! F msg = '' UNLOCK(alock(LEN_TRIM(msg)),STAT=stat, & ERRMSG=msg) ! G stat = 13 SYNC IMAGES(stat,STAT=stat) ! H msg = 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=stat, & ERRMSG=msg) ! I In each of the statements labelled A-F, there is a dependency between the STAT= specifier and the ERRMSG= specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK= specifier and the STAT= specifier (there is no dependency between ACQUIRED_LOCK= and ERRMSG= because the former is only set on successful execution and the latter is only set on an error condition). There appears to be no restrictions at all on any dependencies from ACQUIRED_LOCK=. In the LOCK statement (F), there is a dependency between the STAT= specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG= specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT= variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG= variable and the image set. Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: No interpretation is established and therefore these are not conforming. An edit is provided to clarify this. EDITS to 10-007r1: [190:16-] 8.5.4 SYNC IMAGES statement, insert new p1, "The value of shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the value of the , , or .". [195:2-] 8.5.7 STAT= and ERRMSG= specifiers..., insert new p1, "The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier. The shall not depend on the value of the , , or the in the ACQUIRED_LOCK= specifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 14-209 m204 F08/0113 submitted - passed by J3 meeting 14-258 m205 Passed by J3 letter ballot #31 14-233r1 N2047 m206 Passed by WG5 ballot 8 N2042/43 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0115 TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider PROGRAM Main INTEGER, ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') CALL async_read(array) CALL fred(array(::2)) ! Problematic? WAIT (11) PRINT *, array CONTAINS SUBROUTINE async_read(array) INTEGER, ASYNCHRONOUS, INTENT(INOUT) :: array(:) READ (11, *, ASYNCHRONOUS='yes') array END SUBROUTINE END PROGRAM SUBROUTINE Fred (arg) ! In general, an external procedure INTEGER :: arg(*) ! Otherwise unused CONTINUE ! In general, something that takes more time END SUBROUTINE Is the call to "Fred" standard-conforming? It is not excluded by 5.3.4p2, because 'array' is merely associated with 'arg' in subroutine Fred, and not used in any executable statement or specification expression there. However, if copy-in/out is used for argument passing and the actual i/o transfer occurs in between the copy-in and copy-out, the wrong answers will be given. ANSWER: This program was not intended to be conforming. An edit is provided to correct this oversight. EDITS to 10-007r1: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or" and insert a comma after "scoping uinit". SUBMITTED BY: Nick Maclaren HISTORY: 14-218 m205 F08/0115 submitted 14-218r1 m205 Revised 14-218r2 m205 Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: In all cases, Alf is a Fortran procedure like this: SUBROUTINE Alf (Arg) BIND(C,NAME='Alf') INTERFACE SUBROUTINE Arg () BIND(C) END SUBROUTINE Arg END INTERFACE CALL Arg END SUBROUTINE Alf Q1. Consider extern void Bert (void) { ; } int main (void) { Alf(Bert); } 15.5.1p2 requires a procedure defined by means other than Fortran to have the same binding label as the interface. Function Bert() has a binding label of 'Bert', but 15.5.2p2 states that the dummy argument Arg has no binding label, therefore 15.5.1p2 is not satisfied. Was this intended to be conforming? Q2. Consider static void Fred (void) { ; } int main (void) { Alf(Fred); } 15.5.1p2 requires a procedure defined by means other than Fortran to have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999. Function Fred() has no such name, as its definition has internal linkage. However, linkage in C affects only the visibility of the external name, and has no application to either types or values, whether in the form of function parameters or other pointers. Was this intended to be conforming? Q3. Consider extern inline void arg (void) { ; } int main (void) { Alf(Joe); } C99 6.7.4 describes the inline specifier. This does not prevent it from having external linkage, but "An inline definition does not provide an external definition for the function" i.e. despite having external linkage, there might be no external definition that could be invoked from Fortran. Was it not an oversight not to exclude inline in 15.5.1? ANSWERS: A1. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A2. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A3. A C function with no external definition is not "defined by means other than Fortran" so much as "not defined". This was not intended to be conforming. An edit is provided to clarify this situation. EDITS to 10-007r1: [436:15] 15.5.1 Definition and reference of interoperable procedures, p1, Append sentence "A C function that has an inline definition and no external definition is not considered to be defined in this sense.". In 15.5.1p2, apply these edits [436:16] After "means other than Fortran," delete "it shall", [436:17] Before "be describable" insert "it shall", after "the interface," insert "and", [436:18-19] Before "have a name" insert "if it is accessed using its binding label, it shall" and begin a bullet sub-list, and make the "have the same" bullet the second sublist item. This makes that whole paragraph read "If the procedure is defined by means other than Fortran, -- it shall be describable by a C prototype that is interoperable with the interface, and -- if it is accessed using its binding label, it shall - have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999, and - have the same binding label as the interface." {Note this wording uses "accessed" rather than "invoked" since it can be the argument of C_FUNPTR or the target in a procedure pointer assignment.} SUBMITTED BY: Nick Maclaren HISTORY: 14-221 m205 F08/0116 submitted 14-221r1 m205 Revised 14-221r2 m205 Further Revised - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Is the following program conforming and required to print 10, 10, 10 and 123, 123, 123? PROGRAM Main INTEGER, TARGET :: coarray(3)[*] coarray = 10*THIS_IMAGE() SYNC ALL IF (THIS_IMAGE() == 1) THEN SYNC ALL coarray = 123 SYNC ALL ELSE IF (THIS_IMAGE() == 2) THEN CALL Fred(coarray(:)[1]) ELSE SYNC ALL SYNC ALL END IF CONTAINS SUBROUTINE Fred (arg) INTEGER, TARGET :: arg(:) PRINT *, arg SYNC ALL SYNC ALL PRINT *, arg END SUBROUTINE Fred END PROGRAM Main DISCUSSION: This program is modifying an actual argument while it is associated with a dummy argument. That is normally prohibited by the anti-aliasing rules in 12.5.2.13, but these do not operate in the TARGET dummy argument case. However, coindexed actual arguments are accessing remote memory, so in general will be passed by copy-in/out; in this case permitting aliasing is not reasonable. ANSWER: The program is not intended to be conforming. Edits are provided to correct this oversight. EDITS to 10-007r1: [300:14] 12.5.2.13p1(3)(b) after "target other than" insert "a coindexed object or". [300:22] 12.5.2.13p1(4)(b) after "target other than" insert "a coindexed object or". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-223 F08/0117 submitted m205 14-223r1 Revised example and discussion - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does this program conform to the Fortran 2008 standard? type :: T integer :: C end type T type(t), parameter :: V = T(41) associate ( W => V ) w%c = 42 end associate end DISCUSSION: Because the selector is not permitted to appear in a variable definition context, the associate-name is not permitted to appear in a variable definition context. However, that does not affect subobjects of the associate-name. ANSWER: The associate-name is not permitted to appear in a variable definition context because no interpretation is established; however, it should be explicitly stated that this is not permitted. An edit is provided to clarify this. EDITS to 10-007r1: [170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801, Change " shall not appear" to "neither the nor any subobject thereof shall appear". [171:12] 8.1.3.3 Attributes of associate names, p2, Change "the associate name shall not appear" to "neither the associate name nor any subobject thereof shall appear". [184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836, Change " shall not appear" to "neither the nor any subobject thereof shall appear". SUBMITTED BY: Van Snyder HISTORY: 14-240r1 m205 F08/0118 submitted 14-240r2 m205 Revised question and answer - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Do the GO TO statements in the following conform to the Fortran 2008 standard? go to 1 block 1 end block go to 2 critical 2 end critical ANSWER: Branching to an END BLOCK or END CRITICAL statement from outside the construct was intended to be prohibited. Edits are provided to correct this omission. EDITS to 10-007r1: [172:13+] 8.1.4 BLOCK construct, after p3 (before NOTE 8.5), Insert new paragraph "It is permissible to branch to an only from within its BLOCK construct.". [173:21+] 8.1.5 CRITICAL construct, after p3 (before NOTE 8.6), Insert new paragraph "It is permissible to branch to an only from within its CRITICAL construct.". FUTURE REVISION: A future revision could make all of these constraints, and combine them into a single requirement as follows. [170:36 8.1.3.2p3] Delete the paragraph. [175:35-36 8.1.6.4p1] Delete "It is permitted ... DO construct." [175:40 8.1.6.4p2] Delete "Transfer of control ... ." [180:25 8.1.7.2p2] Delete "It is permissible ... IF construct." [182:26 8.1.8.2p3] Delete the paragraph. [185:26 8.1.9.2p9] Delete the paragraph. [187:7+ 8.2.1p1+] Insert constraint: "C847a If a branch target statement is an , , , , , , or , the branching statement that references the label of that branch target statement shall be within the construct completed by that branch target statement." SUBMITTED BY: Van Snyder HISTORY: 14-242 m205 F08/0119 submitted 14-242r1 m205 Revised question and answer 14-242r2 m205 Fixed typo in example - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Is the name of a procedure pointer a local identifier? The list of classes of local identifiers given in paragraph 1 of subclause 16.3.1 of J3/10-007r1 (page 440) does not include procedure pointers. ANSWER: Yes, if a procedure pointer is named, the name of the procedure pointer is a local identifier. An edit is provided to amend the oversight. EDITS to 10-007r1: [440:4, 16.3.1p1] In item (1) after "named constants," insert "named procedure pointers,". SUBMITTED BY: Robert Corbett HISTORY: 14-256 m205 F08/0120 submitted - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Fortran 2003 7.1.6 (Specification expressions), says on 141:12: A restricted expression is an expression in which each operation is intrinsic Fortran 2008 7.1.11 says on 150:8: A restricted expression is an expression in which each operation is intrinsic or defined by a specification function This new feature is not called out in the Introduction but should be. ANSWER: This was an oversight. An edit to correct the problem is supplied. EDITS to 10-007r1: Introduction, page xv. Add to the "Data declaration" list in paragraph 2: "A can be used in a specification expression." SUBMITTED BY: Steve Lionel HISTORY: 14-259 m205 F08/0121 submitted 14-259r1 m205 In edit, replace "defined operator" with "" - Passed by J3 meeting 15-121 m206 Passed as amended by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTIONS: Q1. Consider Module m Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] Contains Subroutine dubious Volatile x Volatile xco ... End Subroutine End Module Program bad Use m Volatile x Volatile xco ... End Program 5.3.19 C560 says "The VOLATILE attribute shall not be specified for a coarray that is accessed by use (11.2.2) or host (16.5.1.4) association." That means that the two "VOLATILE XCO" statements are not conforming. However, the "VOLATILE X" statements have essentially the same effect, but are unaffected by the constraint, which seems inconsistent. Was this constraint also intended to apply to objects with coarray components? Q2. Consider Program blockvolatile Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] ... Block Volatile x Volatile xco End Block 5.3.19 C561 says "Within a BLOCK construct (8.1.4), the VOLATILE attribute shall not be specified for a coarray that is not a construct entity (16.4) of that construct." That means that VOLATILE XCO is not standard-conforming. However, the constraint apparently does not apply to X, so VOLATILE X is standard- conforming, even though it has essentially the same effect as the forbidden case. Was this constraint intended also to apply to objects with coarray components? Q3. 5.3.19p1 says "A noncoarray object that has the VOLATILE attribute may be associated with an object that does not have the VOLATILE attribute..."; does this apply to objects with a coarray component? Q4. 12.4.2.2p1 says "A procedure other than a statement function shall have an explicit interface if it is referenced and ... (2) the procedure has a dummy argument that ... (c) is a coarray, ...." Is this intended also to apply to objects with coarray components? Q5. Consider: Program volatility Type t Real,Allocatable :: co[:] End Type Type(t) :: x Type(t),Volatile :: y ... Call s1(x) Call s2(x) ! Dummy is volatile, X is not. Call s1(y) ! Y is volatile, dummy is not. Call s2(y) Contains Subroutine s1(a) Type(t) :: a ... End Subroutine Subroutine s2(b) Type(t),Volatile :: b ... End Subroutine End Program 12.5.2.8p1 says "If the dummy argument is a coarray, the corresponding actual argument shall be a coarray and shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." That means that if the program were passing the component CO directly (and the TYPE(T) declarations in S1 and S2 were changed to REAL), the second and third calls would not be conforming because of the VOLATILE mismatch. It seems inconsistent that there is no requirement for VOLATILE to match when there are coarray components, since it has the same effect that X%CO is VOLATILE in S2 but not in the caller, and Y%CO is VOLATILE in the caller but not in S1. Was this requirement also intended to apply to objects with coarray components? Q6. 12.8.1 C1289 says "All dummy arguments of an elemental procedure shall be scalar noncoarray dummy data objects and shall not have the POINTER or ALLOCATABLE attribute." Is this intended also to apply to objects with coarray components? ANSWER: A1. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A2. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A3. No, this does not apply to objects with coarray components, as there is no way of giving the noncoarray parts of the object the VOLATILE attribute without giving the coarray part the VOLATILE attribute, which is forbidden. That the quoted text gives permission for a noncoarray to have the VOLATILE attribute does not override any other requirements in the standard. A4. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. A5. Yes, this requirement was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A6. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. EDITS to 10-007r1: [102:9] 5.3.19 VOLATILE attribute, C560, Between "for a coarray" and "that is accessed by use or" insert ", or a variable with a coarray ultimate component,". {A1.} [102:11] 5.3.19 VOLATILE attribute, C561, Between "for a coarray" and "that is not a construct entity" insert ", or a variable with a coarray ultimate component,". {A2.} [295:4+] 12.5.2.4 Ordinary dummy variables, p18+, add paragraph "If the dummy argument has a coarray ultimate component, the corresponding actual argument shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." {A5.} SUBMITTED BY: Nick Maclaren HISTORY: 14-228 m205 F08/0122 submitted 14-228r1 m205 Revised questions with answers - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following program Program test_spacing Real :: x, y, tiny_spacing, z x = Tiny(x) y = Nearest(x,1.0) tiny_spacing = y - x If (tiny_spacing>0) Then ! Probably IEEE arithmetic with subnormals: ! the spacing y - x is representable. Else ! Probably no subnormals, so y - z is not representable. tiny_spacing = Tiny(x) End If z = Spacing(x) If (z/=tiny_spacing) Then Print *,'FAIL' Else Print *,'ok' End If End Program Furthermore let us assume that the processor supports IEEE arithmetic with subnormals, and that default REAL is IEEE single precision. According to Fortran 95, the result for SPACING is: "If X is not zero, the result has the value b**(e-p), where b, e, and p are as defined in 13.7.1 for the model representation of X, provided this result is within range." therefore the program is expected to print the value "ok". However, according to Fortran 2008, the result for SPACING is: "If X does not have the value zero ..., the result has the value b**max(e-p,emin-1), where ..." Unsurprisingly, e-p is not equal to max(e-p,emin-1) for smallish numbers, and therefore the program would be expected to print the value "FAIL". However, there is no such incompatibility with Fortran 90/95 listed in clause 1, therefore the standard contradicts itself. (The value specified in Fortran 2008 also contradicts the Description of the function which says "Spacing of model numbers (13.4)", since it does not even attempt to return that value.) Is the new specification a deliberate incompatibility or a mistake? DISCUSSION: The description of SPACING was changed in Fortran 2003 by paper 01-361r2 "Comments on Section 13", which contains no justification for this technical change and indeed does not even mention it is a technical change - there is just the bare edit (buried in a huge list of bare edits) with no indication as to why. This would seem to indicate that the technical change is an inadvertent error (presumably the paper simply forgot about subnormal numbers and assumed the new formula gave the same result as the old one). ANSWER: The new wording of SPACING inadvertently changed the return values when IEEE subnormal values were available. An edit is provided to correct this mistake. EDITS to 10-007r1: [389:4-5] 13.7.157 SPACING (X), p5 Result Value, Change "max(e-p,emin-1)" to "e-p" where e and p are in italics. After "that of X" insert ", provided this result is representable; otherwise the result is the same as that of TINY (X).", Change "; if there are two such values" to "If there are two extended model values equally near to X,". This makes the whole paragraph read: If X does not have the value zero and is not an IEEE infinity or NaN, the result has the value b**(e-p), where b, e, and p are as defined in 13.4 for the value nearest to X in the model for real values whose kind type parameter is that of X, provided this result is representable; otherwise the result is the same as that of TINY (X). If there are two extended model values equally near to X, the value of greater absolute value is taken. If X has the value zero, the result is the same as that of TINY (X). If X is an IEEE infinity, the result is an IEEE NaN. If X is an IEEE NaN, the result is that NaN." where "b**(e-p)" represents the typesetting of $b^{e-p}$ and throughout the edits, "b", "e" and "p" are in italics. SUBMITTED BY: Malcolm Cohen HISTORY: 14-263 m205 F08/0123 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following type definitions and object declarations: Type t1 Class(*),Allocatable :: bad End Type Type t2 Type(t1),Allocatable :: oops End Type Type(t1) x[*] Type(t2) y[*] Do the following subroutine calls conform to the Fortran 2008 standard? Call s1(x[2]) Call s2(y[2]) DISCUSSION: If Y[2]%OOPS and Y[2]%OOPS%BAD are both allocated they are subobjects, but only OOPS is a subcomponent of Y[2]. Since OOPS is not polymorphic and BAD is not a subcomponent, this clearly does not violate C617. That seems inconsistent since in both cases a copy of the coindexed variable would necessarily copy the polymorphic BAD component. ANSWER: The intent of C617 was to prevent copying a polymorphic subobject of a coindexed object. Since a subobject is not always a subcomponent, an edit is provided to correct the mistake of using the term "subcomponent" in C617. EDITS to 10-007r1: [6:7+] After the definition of <> (1.3.33.2), insert new term "1.3.33.2a <> nonpointer component, or potential subobject component of a nonpointer component" {We need a new term to describe this properly.} [119:13 C617] Replace "subcomponent" with "potential subobject component". SUBMITTED BY: Van Snyder HISTORY: 14-262 m205 F08/0124 submitted - Passed by J3 meeting 15-121 m206 Passed by J3 letter ballot 14-279 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0126 TITLE: Can cobounds be referenced in the same type declaration? KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Do the following declarations conform to the Fortran 2008 standard? integer :: A[5,*] = ucobound(a,1) ) integer :: C[5,ucobound(c,1),*] integer :: B[5,*], C[ucobound(b,1),*], D(ucobound(c,1)) ANSWER: 7.1.11p8 says "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the ...." This does not establish an interpretation for any of the declarations. The intent of interpretation F95/000090 was that the third one be allowed, while the first and second be prohibited.0104 Edits are provided to correct this oversight. EDITS to 10-007r1: [10-007r1:151:7-8 7.1.11p8] Replace "a type parameter or an array bound" with "a type parameter, array bound, or cobound" and replace "the type parameter, or array bound" with "the type parameter, array bound, or cobound". SUBMITTED BY: Van Snyder HISTORY: 15-102 m206 F08/0126 submitted 15-102r2 m206 Passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0127 TITLE: May an initial line begin with a semicolon? KEYWORDS: Semicolon DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: The Introduction to ISO/IEC 1539-1:2010, page xvi, states "A line in the program is permitted to begin with a semicolon." Therefore, do the following 3 lines constitute a valid program. ;PROGRAM bad PRINT *,'No' END PROGRAM ANSWER: No, the example is not a valid program as it does not satisfy the syntax rules and constraints. As stated in 3.3.2.5 and 3.3.3.4, a semicolon may be used to terminate a statement. That is not the case in the example, since there is no statement before the semicolon. The semicolon does not appear anywhere else in the Fortran syntax and therefore the example does not conform. An edit is supplied to the Introduction to clarify the change in Fortran 2008. EDITS to 10-007r1: [xvi] Introduction, bullet "Programs and procedures:", Replace "A line in the program is permitted to begin with a semicolon." with "A free form continuation line can begin with zero or more blanks followed by a semicolon." SUBMITTED BY: Malcolm Cohen HISTORY: 15-105 m206 F08/0127 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0129 TITLE: Is CLASS(type) required to refer to a prior type definition? KEYWORDS: CLASS, type definition DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does the CLASS(T) declaration of X in the following conform? recursive subroutine S ( N, X ) integer :: N class(t), optional :: X type :: T integer :: Q end type T ... ANSWER: Although subclause 4.3.1.3 does not require the in a CLASS specifier to refer to a previously-defined type, it was intended that CLASS declarations with be parallel to TYPE declarations. In a TYPE declaration (4.3.1.2), the specified derived type is required to be previously defined, or accessed by use or host association. Therefore the example ought not to conform. Edits are provided to correct this oversight. EDITS to 10-007r1: [52:6+] 4.3.1.3 CLASS, p1+, insert new paragraph: "Where a data entity other than a component is declared explicitly using the CLASS specifier to be of derived type, the specified derived type shall have been defined previously. If the data entity is a function result, the derived type may be specified in the FUNCTION statement provided the derived type is defined within the body of the function or is accessible there by use or host association. If the derived type is specified in the FUNCTION statement and is defined within the body of the function, it is as if the function result variable were declared with that derived type immediately following its ." {This is essentially identical to 4.3.1.2p1, except for the replacement of "TYPE" with "CLASS" and the addition of "other than a component" (4.3.1.2p1 does not mention components, but it ought to because otherwise it would contradict C440), but that's a different question.} SUBMITTED BY: Van Snyder HISTORY: 15-127 m206 F08/0129 submitted 15-127r1 m206 Passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0130 TITLE: Does coarray allocation sync even with stopped images? KEYWORDS: ALLOCATE, DEALLOCATE, coarray, synchronization, stopped DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Example 1: Consider the trivial program Program m206c7e1 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Stop 'Image 1 is now stopping' End If Allocate(x(100)[*],Stat=stat) ! If (me==2) Print *,'Arrived' !***A ! If (stat==0) Error Stop 'INCONCEIVABLE' If (stat/=Stat_Stopped_Image) Error Stop 'Bad STAT' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***B End Do End Program Q1. On images other than image 1, does execution ever reach the statement with comment "!***A"? 6.7.1.2 Execution of an ALLOCATE statement, p4 says "When an ALLOCATE statement is executed for which an allocate-object is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the statement is delayed until all other images have executed the same statement the same number of times." The second sentence seems to say that execution on images>1 is delayed forever, since image 1 will never execute that ALLOCATE statement. Example 2: Consider the program Program m206c7e2 Use Iso_Fortran_Env Implicit None Real(real32), Allocatable :: x(:,:,:,:)[:],y(:,:,:,:) Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Allocate(y(1000,1000,1000,1000)) !***C End If Allocate(x(1000,1000,1000,1000)[*],Stat=stat) !***D ! If (me==1 .And. stat==0) Error Stop 'Inconceivable!' ! If (stat==0) Print *, 'ALLOCATE ok on image', me !***E ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***F End Do End Program For purposes of discussion, let us assume that each image has 6 Terabytes of memory available to it for dynamic allocation. The ALLOCATE statement commented "!***C" will allocate 4 terabytes of memory on image 1. Execution of the ALLOCATE statement commented "!***D" will attempt to allocate 4 terabytes on each image; this will fail on image 1 as there is insufficient memory available, but could succeed on other images. Q2. Is the success of an ALLOCATE statement the same on every image, or may it fail on some images and succeed on others? That is, might the statement commented "!***E" execute the PRINT on some images (but not all). Q2 continuation: If the answer is that the ALLOCATE must either succeed or fail on all images, can the STAT= value differ by image (for example, might a processor return a different STAT= code for "no memory on this image" and "no memory on some other image"). Example 3: Consider the program Program m206c7e3 Use Iso_Fortran_Env Implicit None Real, Allocatable :: x(:)[:] Integer :: me[*],i Integer stat me = This_Image() If (Num_Images()<3) Error Stop 'Need at least 3 images' If (me==1) Then Call do_something_that_takes_a_very_long_time End If Allocate(x(100)[*],Stat=stat) !***G ! If (stat==0) Error Stop 'INCONCEIVABLE' ! Do i=1,Num_Images() If (me[i]/=i) Error Stop 'me not right?' !***H End Do End Program Let us imagine that the processor operates some form of "timeout" mechanism, for example, if an image fails to reach a synchronization point within an hour of the first image reaching that statement, an error is returned. (If the slow image subsequently reaches that statement, one might conjecture that it will also get an error, but probably STAT_YOU_ARE_TOO_SLOW rather than STAT_TIMEOUT). In the example above, let us assume that the ALLOCATE statement commented "!***G" fails, e.g. with a timeout error as we imagined above. Q3. After resolution of question 1, which images are synchronized after execution of an ALLOCATE statement that fails? That is, is execution of the statements commented "!***B" (in Q1), "!***F" (in Q2) and "!***H" (above) permitted, or are they impermissible references to variables in unordered segments? In the case of "!***B", one might conjecture that all the non-stopped images are synchronized. In the case of "!***F" the text of the standard appears to require that image 1 has to wait for all the other images, but it might equally be conjectured that that is a mistake and that since it knows straightaway that it cannot satisfy the memory allocation it should be allowed to return straightaway without synchronizing, i.e. the "!***F" is not allowed. In the case of "!***H", image 1 has still not even reached the ALLOCATE statement (after an hour of the others waiting), so it would seem that it is impossible for it to have synchronized as required by the standard, and therefore that (for i==1 at least) the execution of "!***H" is not allowed. Q4. When allocation of a coarray is involved, and an error occurs (e.g. as in the examples above, plus other cases), under what situations does the coarray in question become allocated? In particular, can a coarray be allocated on some images but not others? If the answer is that the coarray never becomes allocated, that means that in the case of a stopped image, the remaining images cannot allocate any coarray. Q5. Do the answers to Q1-Q4 also apply to DEALLOCATE statements? ANSWER: A1. In the case of stopped images, the requirement in 6.7.1.2 was only intended to apply to the non-stopped images. An edit is provided to correct this mistake. A2. Allocation of a coarray was intended only to succeed if it succeeds on all images. An edit is provided to add this missing requirement. (A2 continuation) There was not intended to be any requirement that a nonzero STAT= value be the same on each image. No edit is provided to add such a requirement. A3. After execution of an ALLOCATE statement that returns an error other than STAT_STOPPED_IMAGE, there was not intended to be any requirement for synchronization. An edit is provided to correct this mistake. A4. The coarray can become allocated on an image if and only if it can become allocated on all other images. An edit is provided to add this requirement. The consequence in the case of a stopped image is indeed that no image can subsequently change the allocation status of any coarray. A5. Yes, the answers also apply to DEALLOCATE statements. Corresponding edits are supplied. EDITS to 10-007r1: [128:15-17] 6.7.1.2 Execution of an ALLOCATE statement, p4, Change "On each image" to "If no error condition other than STAT_STOPPED_IMAGE occurs" Change "all other images" to "all non-stopped images". {A1,A3: Synchronization only applies to successful allocations and to allocations that fail only due to STAT_STOPPED_IMAGE.} Append a sentence requiring allocation success consistency for coarrays, making the whole paragraph read: "When an ALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition other than STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2) following the statement is delayed until all non-stopped images have executed the same statement the same number of times. The coarray shall not become allocated on an image unless it is successfully allocated on all non-stopped images." {A2,A4: Last sentence is the consistency requirement.} [131:16-19] 6.7.3.2 Deallocation of allocatable variables, p11, Change "On each image" to "If no error condition other than STAT_STOPPED_IMAGE occurs" Change "all other images" to "all non-stopped images". Append a sentence requiring deallocation consistency, making the whole paragraph read: "When a DEALLOCATE statement is executed for which an is a coarray, there is an implicit synchronization of all images. If no error condition other than STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2) following the statement is delayed until all non-stopped images have executed the same statement the same number of times. If the coarray is a dummy argument, its ultimate argument (12.5.2.3) shall be the same coarray on every image. The coarray shall not become deallocated on an image unless it is successfully deallocated on all non-stopped images." SUBMITTED BY: Malcolm Cohen HISTORY: 15-133 m206 F08/0130 submitted 15-133r1 m206 Passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2094 m209 Modified by 1st Corrigendum 4 ballot N2088/89/90 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0131 TITLE: Are the changes to C_LOC in the 2010 revision intentional? KEYWORDS: C_LOC, interoperability DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: The description of C_LOC in the intrinsic module ISO_C_BINDING permits noninteroperable array arguments that are contiguous, provided the type and kind are interoperable. This was not permitted by the previous revision of ISO/IEC 1539-1, which required all type parameters to be interoperable (and only exempted allocatable arrays from the "interoperable variable" requirement); however this is not listed in the Introduction as a change. For example, each of the following is apparently permitted as arguments to C_LOC by the requirements in Fortran 2008 but not in Fortran 2003: CHARACTER(13,C_char),TARGET :: x(100) CHARACTER(14,C_char),TARGET :: y REAL(C_float),CONTIGUOUS :: dummy1(:) INTEGER(C_int),CONTIGUOUS,POINTER :: z(:) (the CONTIGUOUS attribute does not exist in Fortran 2003). and also REAL(C_float) :: dummy2(:) INTEGER(C_int),POINTER :: z2(:) when dummy1 is argument-associated with a contiguous array, and z2 is pointer-associated with a contiguous array. Was this change intended? ANSWER: Yes, this change was intentional. An edit is provided to add this to the Introduction. EDITS to 10-007r1: [xvi] Introduction, "Intrinsic modules" bullet point, Before "The function C_SIZEOF" insert new sentence "A contiguous array variable that is not interoperable but which has interoperable type and kind type parameter (if any), and a scalar character variable with length>1 and kind C_CHAR, can be used as the argument of the function C_LOC in the intrinsic module ISO_C_BINDING, provided the variable has the POINTER or TARGET attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 15-132 m206 F08/0131 submitted 15-132r1 m206 Revised edits 15-132r2 m206 Revised question - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0132 TITLE: Can a procedure pointer be declared with an interface block? KEYWORDS: procedure pointer, interface block DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the program PROGRAM c11 INTERFACE REAL FUNCTION F() END FUNCTION END INTERFACE POINTER F EXTERNAL G F => G PRINT *,F() END PROGRAM REAL FUNCTION G() G = 206 END FUNCTION According to 12.4.3.2 paragraph 5, F is an external procedure (and seems to be missing). There is no mention of the possibility of a procedure pointer in the subclause on interface blocks. Is this intended to be standard-conforming? ANSWER: Yes, this is intended to be standard-conforming. An edit is supplied to correct the mistake in 12.4.3.2. EDITS to 10-007r1: [281:26] In 12.4.3.2 Interface block, paragraph 5, After "specific interface for an external procedure" change "or a dummy procedure" to ", dummy procedure, or procedure pointer". {Add procedure pointer for the list of things this can declare.} [281:25-28] Same paragraph, After "interface body, the procedure is a dummy procedure" change "; otherwise" to ". If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure or procedure pointer". {Correct how we establish what it is.} This makes that whole paragraph read: An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an explicit specific interface for an external procedure, dummy procedure, or procedure pointer. If the name of the declared procedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a dummy procedure. If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy procedure or procedure pointer, it is an external procedure. {Note careful wording to avoid saying that a dummy procedure is not a procedure pointer, since a dummy procedure pointer is indeed both a dummy procedure and a procedure pointer.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-136 m206 F08/0132 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0133 TITLE: Is unallocated actual associated with nonallocatable dummy OK? KEYWORDS: OPTIONAL, ALLOCATABLE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Does the following program conform to the 2008 standard? program P integer, allocatable :: I(:) call s ( i ) contains subroutine S ( A ) integer, intent(in), optional :: A(:) if ( present(a) ) then print *, 'A = ', a else print *, 'A is not present' end if end subroutine S end program P Subclause 6.7.1.3 says, concerning an unallocated allocatable variable, "It shall not be supplied as an actual argument corresponding to a nonallocatable dummy argument, except to certain intrinsic inquiry functions." On the other hand, subclause 12.5.2.12 says a dummy argument "is not present if the dummy argument ... does not have the ALLOCATABLE ... attribute, and corresponds to an actual argument that ... has the ALLOCATABLE attribute and is not allocated...." ANSWER: The intent was that the program conforms, and prints "A is not present", as specified by subclause 12.5.2.12. Edits are provided to correct this mistake. EDITS to 10-007r1: [10-007r1:129:8 6.7.1.3 p1, second item in bulleted list] Insert "nonoptional" before "nonallocatable". SUBMITTED BY: Van Snyder HISTORY: 15-141 m206 F08/0133 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0134 TITLE: in an image control statement KEYWORDS: stat=, image control statement DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Was it intended to allow or in an image control statement to be coindexed? For example, was it intended that this statement SYNC IMAGES(1, stat = is[2]) be allowed? It seems undesirable to involve image 2 when synchronizing the executing image with image 1. ANSWER: No, it was not intended to allow the or in an image control statement to be coindexed. An edit is provided to correct this oversight. EDITS to 10-007r1: [190:5+] Add constraint "C851a (R859) A or in a shall not be a coindexed object. SUBMITTED BY: John Reid HISTORY: 15-144 m206 F08/0134 submitted - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0135 TITLE: Vector subscripted actual makes VALUE dummy undefinable? KEYWORDS: VALUE, definable, vector subscript DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: 12.5.2.4p18 [295:3-4] says "If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes." This would seem to be a strange requirement when the dummy argument has the VALUE attribute (and so is not argument-associated with the actual argument anyway). Consider program P1 real :: X(3) call S1 ( X ( [ 1, 3, 2 ] ) ) contains subroutine S1 ( A ) real, value :: A(:) A = 3 print *, A end subroutine end program and PROGRAM p2 REAL :: x(3) = [ 10,20,30 ] OPEN(10,ASYNCHRONOUS='YES',FORM='UNFORMATTED') CALL s2( x( [ 1,2,2,1 ] ) ) CONTAINS SUBROUTINE s2(a2) REAL,VALUE,ASYNCHRONOUS :: a2(:) READ(10,ASYNCHRONOUS='YES') a2 PRINT *,'reading...' WAIT(10) PRINT *,a2 END SUBROUTINE END PROGRAM Are these two programs standard-conforming? In particular, is the assignment to A permitted in S1, and is the dummy argument a2 permitted to have the ASYNCHRONOUS attribute in s2. ANSWER: These two programs were intended to be standard-conforming. Subclause 12.5.2.3 states that a VALUE dummy argument is associated with a definable data object and not with the actual argument. An edit is supplied to correct this mistake. EDITS to 10-007r1: [295:3] 12.5.2.4 Ordinary dummy variables, p18, after applying the changes in F2008 Corrigendum 1, between "is nonelemental" and "and the actual argument", insert ", the dummy argument does not have the VALUE attribute,". This makes that whole sentence read "If the procedure is nonelemental, the dummy argument does not have the VALUE attribute, and the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes." SUBMITTED BY: Van Snyder HISTORY: 15-148 m206 F08/0135 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed as amended by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0136 TITLE: Argument correspondence with VALUE and ASYNCHRONOUS KEYWORDS: VALUE, ASYNCHRONOUS, coindexed, contiguous DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following three programs and discussions: program P1 real, asynchronous :: X[*] call S1 ( X [ 1 ] ) contains subroutine S1 ( A ) real, value, asynchronous :: A a = 3 end subroutine S1 end program P1 Program P1 appears to violate C1238 which says "An actual argument that is a coindexed object with the ASYNCHRONOUS or VOLATILE attribute shall not correspond to a dummy argument that has either the ASYNCHRONOUS or VOLATILE attribute." but the dummy argument is not associated with the actual argument so it is unclear why that should be the case. program P2 real, asynchronous :: X(3) call S2A ( X ) contains subroutine S2A ( A ) real, asynchronous :: A(:) call S2B ( A(1:3) ) end subroutine S2A subroutine S2B ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S2B end program P2 This appears to violate C1239 which says "If an actual argument is a nonpointer array that has the ASYNCHRONOUS or VOLATILE attribute but is not simply contiguous (6.5.4), and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS attribute." but again, it is unclear why that should matter for a VALUE dummy argument. program P3 real, target :: X(3) real, pointer, asynchronous :: Y(:) y => x call S3 ( y ) contains subroutine S3 ( A ) real, value, asynchronous, contiguous :: A(:) a = 3 end subroutine S3 end program P3 This program appears to violate C1240 which says "If an actual argument is an array pointer that has the ASYNCHRONOUS or VOLATILE attribute but does not have the CONTIGUOUS attribute, and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an array pointer or an assumed-shape array that does not have the CONTIGUOUS attribute." but it is unclear why this should matter for a VALUE dummy argument. Are those programs intended to be standard-conforming? ANSWER: Yes, all those programs were intended to be standard-conforming. There is no need for those constraints to apply to dummy arguments with the VALUE attribute, because a VALUE dummy argument is not associated with the actual argument but with an anonymous definable data object. Edits are supplied to correct the mistakes in the constraints. EDITS to 10-007r1: [295:6] 12.5.2.4 Ordinary dummy arguments, C1238, Between "VOLATILE attribute" and "." insert ", unless the dummy argument has the VALUE attribute". [295:9] Same subclause, C1239, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute". [295:13] Same subclause, C1240, After "ASYNCHRONOUS attribute" insert ", but does not have the VALUE attribute". SUBMITTED BY: Van Snyder HISTORY: 15-149 m206 F08/0136 submitted 15-149r4 m206 Fix answer and typos - passed by J3 meeting 15-187 m207 Passed by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0137 TITLE: Result of TRANSFER when MOLD is an array with element size zero KEYWORDS: TRANSFER, zero-sized scalar DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following examples: Example 1: CHARACTER(0),PARAMETER :: nothing1(100) = '' PRINT *,SIZE(TRANSFER(111014,nothing1)) Example 2: TYPE empty END TYPE ! When the physical representation of empty() has size zero; ! this is not required but does seem to be permitted. TYPE(empty),PARAMETER :: nothing2(1) = empty() PRINT *,SIZE(TRANSFER(111014,nothing2)) Example 3: TYPE nonempty REAL c(0) END TYPE TYPE(nonempty),PARAMETER :: nothing3(0) = nonempty(0.0) PRINT *,SIZE(TRANSFER(111014,nothing3)) According to Fortran 2008, 13.7.168, the result of TRANSFER in this case is an array of rank one whose "size is as small as possible such that its physical representation is not shorter than that of SOURCE". However, the size of a zero-length character is zero and the size of the above derived types may be zero, no matter how many array elements there are, so these examples do not seem to be well-defined. Also consider the following examples, with nothing1 defined as in example 1. Example 4: CHARACTER(0) :: source1 = '' PRINT *,SIZE(TRANSFER(source1,nothing1)) Example 5: CHARACTER(999) :: source2(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source2,nothing1)) In these cases the physical representation of an element of MOLD has size zero, but then so does the physical representation of the SOURCE argument. According to the quoted text, that would mean that TRANSFER should return a zero-sized array, i.e. the examples will print zero. Example 6: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source3(0) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source3,maybe_nothing)) Example 7: CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument. CHARACTER(999) :: source4(10) = REPEAT('!',999) PRINT *,SIZE(TRANSFER(source4,maybe_nothing)) In these examples, the physical representation of MOLD is not known at compile time, but depends on the length of the dummy argument. Using the analysis above, example 6 would seem to be conforming (and print zero), while example 7 would seem to be conforming if and only if the length of maybe_nothing is nonzero at execution time. Which of the examples are conforming? If any of examples 1-3 are conforming, what value is printed? ANSWER: Example 1 is not conforming, and if the derived types have size zero in examples 2 and 3, those examples are also not conforming, as no interpretation is established for them. An edit is provided to clarify that they are not valid. Examples 4-6 are conforming, and the value zero is printed. Example 7 is conforming if and only if the length of maybe_nothing is not zero. The same edit clarifies that the zero-length case is not valid. EDITS to 10-007r1: [393:18] 13.7.168 TRANSFER, p3 Arguments, MOLD, append "If the storage size of SOURCE is greater than zero and MOLD is an array, a scalar with the type and type parameters of MOLD shall not have a storage size equal to zero.". {It is ok for MOLD itself to have storage size zero, in the case where MOLD is a zero-sized array but the storage size of a scalar with its type and type parameters would be greater than zero.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-152 m206 F08/0137 submitted - passed by J3 meeting 15-187 m207 Passed as amended by J3 letter ballot 15-159 N2080 m207 Passed by WG5 ballot 9 N2061/62 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0138 TITLE: Type extension in submodules KEYWORDS: submodules, deferred type-bound procedures DEFECT TYPE: Clarification STATUS: In F2008 Corrigendum 4 QUESTION: Consider the following code: module mod_a implicit none type, abstract :: t_a contains procedure(p_a), deferred :: p end type t_a abstract interface subroutine p_a(this, q) import :: t_a class(t_a), intent(inout) :: this class(*), intent(in) :: q end subroutine end interface end module mod_a submodule(mod_a) imp_p_a type, extends(t_a) :: t_imp real :: b contains procedure :: p => psub ! (A) end type t_imp contains subroutine psub(this, q) class(t_imp), intent(inout) :: this class(*), intent(in) :: q ... ! don't care end subroutine psub end submodule imp_p_a Constraint C465 in 10-007r1 reads "C465 (R448) The procedure-name shall be the name of an accessible module procedure or an external procedure that has an explicit interface." Therefore it would appear that statement (A) above is not standard conforming since PSUB is not the name of a module procedure. Q1. Is this correct? If so, extension of a derived type with a deferred type-bound procedure cannot be done within the specification part of a submodule. Q2. Was this intended? ANSWER: A1. No, this is not correct. A module procedure is a procedure that is defined by a module subprogram (1.3.112.4). A submodule program unit contains a module-subprogram-part (R1116), and this contains a (possibly-empty) sequence of module-subprogram's (R1107). Therefore, PSUB is defined by a module subprogram and is therefore a module procedure. Therefore, the statement that is commented "(A)" is standard-conforming. A2. Moot. EDITS to 10-007r1: None. SUBMITTED BY: R. Bader HISTORY: 15-160 m207 F08/0138 Submitted 15-160r1 m207 Revised 15-160r2 m207 Revised example passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 No edits in F2008 Corrigendum 4 N2094/N2097 --------------------------------------------------------------------- NUMBER: F08/0139 TITLE: Is the name of an external procedure that has a binding label a local identifier? KEYWORDS: binding label, local identifier DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the program fragment containing the external subprograms: Subroutine s() Bind(C,Name='Hello') Print *,'Hello' End Subroutine Subroutine s() Bind(C,Name='World') Print *,'World' End Subroutine This does not conform to Fortran 2003, and is not listed as an extension in the Introduction to Fortran 2008, but the rules for global names seem to indicate that this is now conforming. Is this extension deliberate? ANSWER: Yes, this was a deliberate change to the Fortran standard. An edit is provided to mention this in the Introduction. EDITS to 10-007r1: [xvi] Introduction, paragraph 2, bullet "Programs and procedures", append to paragraph "The name of an external procedure that has a binding label is a local identifier and not a global identifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 15-177 m207 F08/0139 submitted - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0140 TITLE: Assign to deferred-length coindexed character variable KEYWORDS: Cobounds, type declaration DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Q1. Consider the program: Program p1 Type t Character(:), Allocatable :: C End Type Type(t) x[*] Allocate ( Character(42) :: x%c ) Sync All If (This_Image()==1) x[2]%c = 'stuff' End Program Is the assignment permitted? Q2. Consider Program p2 Type t Character(:), Pointer :: C End Type Type(t) x[*] Allocate ( Character(42) :: x%c ) Sync All If (This_Image()==1) x[2]%c = 'stuff' End Program Is the assignment permitted? ANSWER: A1. This is not permitted, as it violates the requirement in 7.2.1.2 Intrinsic assignment statement, paragraph 2, which states that if the variable (in an intrinsic assignment statement) is coindexed, its deferred length type parameters shall be the same as the corresponding type parameters of the expression. There is a grammatical error in this requirement; an edit is supplied to correct the grammatical error. A2. This was intended to be permitted, but was inadvertently caught in the prohibition that was intended to apply only to allocatable variables. An edit is supplied to correct this error. EDITS to 10-007r1: [153:25] 7.2.1.2p2, after "coindexed object,", delete "the variable", [153:26] before "shall not be" insert "the variable", [153:27] before "shall not have" insert "the variable", [153:28] after "deferred length type parameter" insert "of the variable" making the whole paragraph read "If is a coindexed object, - the variable shall not be polymorphic, - the variable shall not have an allocatable ultimate component, and - each deferred length type parameter of the variable shall have the same value as the corresponding type parameter of .". SUBMITTED BY: Van Snyder HISTORY: 15-161 m207 F08/0140 submitted 15-161r1 m207 Revised question and answers 15-161r2 m207 Passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0141 TITLE: Can a statement function have a variable-length PDT result? KEYWORDS: Statement function, parameterized derived type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider MODULE m207c006 TYPE string(n) INTEGER,LEN :: n CHARACTER(n) :: v END TYPE END MODULE PROGRAM test USE m207c006 CALL s(3) CALL s(7) CONTAINS SUBROUTINE s(n) TYPE(string(n)) sf TYPE(string(n)) var(3) sf(nn) = var(nn) var(1) = string(n)('123456789') var(2) = string(n)('abcdefgh') PRINT *,sf(1),sf(2) END SUBROUTINE END PROGRAM If this is conforming, it would appear that the output ought to be 123abc 1234567abcdefg However, for the following reasons, perhaps this is not intended to be conforming. (1) A statement function of type character is required to have a constant length type parameter. There is no such requirement on a statement function of parameterized derived type. This seems inconsistent, since one can wrap a variable-length character in a parameterized derived type. (2) A statement function is not permitted to invoke a nonintrinsic function that requires an explicit interface (and having a PDT result requires an explicit interface), nor is it permitted to contain a structure constructor. This would seem to render such a statement function almost completely useless, since all it can do is to choose between PDT constants or variables, or use an intrinsic function such as TRANSFER to construct the result. (3) Statement functions were declared to be obsolescent long before the addition of parameterized derived types to the standard. It has been general policy not to "improve" obsolescent features. This would seem to indicate that statement functions were not intended to be capable of having parameterized derived type in the first place. Q1. Are statement functions of parameterized derived type intended to be conforming? Q2. If so, are statement functions of parameterized derived type with nonconstant length type parameters intended to be conforming? Q3. If so, is the expected output from the example program above as described? ANSWER: A1. No, statement functions were not intended to be permitted to be of parameterized derived type. The exception for statement functions from the explicit interface requirements was overlooked. An edit is provided to prohibit these. A2, A3. Moot. EDITS to 10-007r1: [24:11+] 1.6.2 Fortran 2003 compatibility, insert new paragraph "Fortran 2003 permitted a statement function to be of parameterized derived type; this part of ISO/IEC 1539-1 does not permit that." {Previous corrigenda have already inserted incompatibility paragraphs.} [311:34+] 12.6.4 Statement function, after C1275, insert constraint "C1275a A statement function shall not be of a parameterized derived type." SUBMITTED BY: Malcolm Cohen HISTORY: 15-179 m207 F08/0141 submitted 15-179r1 m207 Revised edits - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0142 TITLE: Is useless module extension permitted? KEYWORDS: SUBMODULE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: If a module declares no separate module procedure, it cannot have a useful submodule as such a submodule has nothing to provide. Its module procedures and variables cannot be referenced by any program. Should useless extension have been prohibited? ANSWER: Yes. Permitting such extension would require the implementation to export the private details of a module merely for the purpose of compiling a useless submodule. An edit is provided to require the ancestor of a submodule to have declared a separate module procedure. EDITS to 10-007r1: [275:18] 11.2.3 Submodules, C1113, After "shall be the name of a nonintrinsic module" insert "that declares a separate module procedure". SUBMITTED BY: Daniel Chen HISTORY: 15-209 m207 F08/0142 submitted - passed by J3 meeting N2093 m209 Passed by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0143 TITLE: May a pure procedure have an INTENT(OUT) polymorphic component? KEYWORDS: PURE, INTENT(OUT), polymorphic DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider: Type t Class(*),Allocatable :: c End Type ... Pure Subroutine zap(x) Type(t),Intent(Out) :: x x%c = 'I wonder if that invoked an impure procedure?' End Subroutine Is this program standard-conforming? ANSWER: No, this is not standard-conforming. Corrigendum 1 of Fortran 2008 added the constraint "C1284a A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure." The type declaration statement with INTENT(OUT) causes the deallocation of the polymorphic component X%C, and is therefore not allowed. However, this is difficult to understand, so a clarifying edit is provided. EDITS to 10-007r1: In Clause 12.7, para, 2, in 10-007r1 [312:23+], in the constraint added by Corrigendum 1, "C1278a An INTENT (OUT) dummy argument of a pure procedure shall not be polymorphic." after the word "polymorphic" insert "or have a polymorphic allocatable ultimate component". SUBMITTED BY: Malcolm Cohen HISTORY: 15-211 m207 F08/0143 submitted - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0144 TITLE: Is ADVANCE= allowed during execution of DO CONCURRENT? KEYWORDS: nonadvancing I/O, DO CONCURRENT DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider program P integer :: I do concurrent ( I = 1:10 ) write ( *, '(I5)', advance='NO' ) I end do write ( *, * ) end program P Q1. Is this conforming and if so, what output is produced? program Q integer :: I logical :: L(10) = .FALSE. real :: X(10) = 0 do concurrent ( I = 1:10 ) if ( mod(i,2) == 0 ) then read ( *, '(g15.6)', advance='no' ) X(I) else read ( *, '(l3)', advance='no' ) L(I) end if end do print *, X, L end program Q2. Is this conforming and what kind of output would be expected? ANSWER: No, these programs are not conforming as no interpretation is established for them. It was intended that the ADVANCE= specifier not be permitted within a DO CONCURRENT construct. An edit is provided to address this oversight. EDITS to 10-007r1: [10-007r1:178:16+ 8.1.6.7p1] after the fourth bullet point, add new bullet point: " o A DO CONCURRENT construct shall not contain an input/output statement that has an ADVANCE= specifier." SUBMITTED BY: Van Snyder HISTORY: 15-213 m207 F08/0144 submitted 15-213r1 m207 Option 2 selected, edit revised - passed by J3 meeting N2093 m209 Passed as amended by J3 LB #35/WG5 ballot #11 [2091/92/93] N2102 m209 In F2008 Corrigendum 4 as amended N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0145 TITLE: Can initial-data-target be coindexed? KEYWORDS: initialization, pointers, coarrays DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: In pointer assignment, the standard is quite clear that data-target cannot be coindexed: C725 (R737) A data-target shall not be a coindexed object. And there are a couple of notes related to this: NOTE 7.45 A data pointer and its target are always on the same image. A coarray may be of a derived type with pointer or allocatable subcomponents. For example, if PTR is a pointer component, Z[P]%PTR is a reference to the target of component PTR of Z on image P. This target is on image P and its association with Z[P]%PTR must have been established by the execution of an ALLOCATE statement or a pointer assignment on image P. NOTE 7.46 A pointer assignment statement is not permitted to involve a coindexed pointer or target, see C723 and C725. This prevents a pointer assignment statement from associating a pointer with a target on another image. If such an association would otherwise be implied, the association status of the pointer becomes undefined. For example, a derived-type intrinsic assignment where the variable and expr are on different images and the variable has an ultimate pointer component. Fortran 2008 added the ability to specify an initial-data-target in pointer initialization: R505 initialization is = constant-expr or => null-init or => initial-data-target R506 null-init is function-reference C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = appears in initialization, the entity shall not have the POINTER attribute. C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it (4.5.4.6). Initial-data-target is defined in 4.5.4.6 and the only relevant constraint for it is: C461 (R443) The designator shall designate a nonallocatable variable that has the TARGET and SAVE attributes and does not have a vector subscript. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be a constant expression. The definition of "data-pointer-initialization compatible" is: "A pointer variable or component is data-pointer-initialization compatible with a target if the pointer is type compatible with the target, they have the same rank, all nondeferred type parameters of the pointer have the same values as the corresponding type parameters of the target, and the target is contiguous if the pointer has the CONTIGUOUS attribute." Given this, is initializing a pointer to a coindexed object permitted? For example: program test integer, save, target :: C[*] integer, pointer :: P => C[3] ! Permitted? end While ordinary pointer assignment to a coindexed object is prohibited by C725, there is no corresponding constraint prohibiting such association by way of data pointer initialization. Note that 16.5.2.5p1(2) says that pointer-assigning to a target on a different image causes the pointer to become undefined. Since the initialization occurs on all images, and it's not possible to restrict the target to only the same image, the effect would be to make a program that does this nonconforming. ANSWER: No, this was not intended to be permitted. A clarifying edit is provided. EDITS to 10-007r1: [70:3] 4.5.4.6 In the first sentence of C461, insert ", noncoindexed" after "nonallocatable" so that the sentence reads: C461 (R443) The designator shall designate a nonallocatable, noncoindexed variable that has the TARGET and SAVE attributes and does not have a vector subscript. SUBMITTED BY: Steve Lionel HISTORY: 15-216 m208 F08/0145 submitted - passed by J3 meeting 16-103 m209 Passed by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0147 TITLE: Is generic resolution of elemental assignment done at runtime? KEYWORDS: Type-bound defined assignment, Allocatable DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider Module da_module Type t Real c End Type Interface Assignment(=) Module Procedure edasgn End Interface Contains Elemental Subroutine edasgn(a,b) Type(t),Intent(Out) :: a Type(t),Intent(In) :: b a%c = -b%c End Subroutine End Module Program edatest Call test(10,10,13) Contains Subroutine test(n,n2,m) Use da_module Type(t) :: x(n),z(m) Type(t),Allocatable :: y(:) x%c = [ (i,i=1,n) ] z%c = [ (i,i=1,m) ] Allocate(y(n2),Source=t(0)) y = x ! A Print 1,y 1 Format(*(1X,F0.1,:)) y = z ! B Print 1,y End Subroutine End Program According to 7.2.1.2 Intrinsic assignment statement, an assignment statement is an intrinsic assignment statement if (and only if) it is not a defined assignment statement. According to 7.2.1.4 Defined assignment statement, a defined assignment statement needs to have a subroutine that defines the assignment "x1 = x2". For elemental subroutines (item (5)(b)), that is true only if "x1 and x2 are conformable" which when x1 and x2 are both arrays, means "has the same shape". For the example above, in the assignment marked (A), x and y will be conformable (as both n and n2 are equal to 10), making that a defined assignment, thus the PRINT statement after it would print -1.0 -2.0 -3.0 -4.0 -5.0 -6.0 -7.0 -8.0 -9.0 -10.0 while in the assignment statement marked (B), y and z will not be conformable (n2 being 10 and m being 13), making it an intrinsic assignment. In this case, because Y is allocatable it will be reallocated, and so the output from the second PRINT statement would be 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 However, this would seem to violate the fundamental principle that generic references are resolvable at compile time. It would also seem to be nearly useless since if the variable is not allocatable the shapes are required to conform anyway. Is this feature intended to work like this? ANSWER: No, this was a mistake. Edits are provided to remove the runtime generic resolution. After the edits: 1) The assignment A is defined assignment and is conforming (from first edit). 2) The assignment B is defined assignment but is not standard conforming, since the shapes differ (from second edit). 3) For a defined assignment statement, auto-reallocation of allocatables does not occur, as that is only done by an intrinsic assignment statement. EDITS to 10-007r1: [24:11+] 1.6.2 Fortran 2003 compatibility, insert new incompatibility "Fortran 2003 interpreted assignment to an allocatable variable from a nonconformable array as intrinsic assignment, even when an elemental defined assignment was in scope; this part of ISO/IEC 1539 does not permit assignment from a nonconformable array in this context.". {The unintended extension is weird and violates our own principles, but is not in itself contradictory or ambiguous so this is an incompatibility.} [157:14] 7.2.1.4 Defined assignment statement, p2, item (5)(b), Change "$x_1$ and $x_2$ are conformable" to "$x_2$ is scalar or has the same rank as $x_1$". {$x_1$ is TeX for italics x subscript 1.} [157:16] Same subclause, p3, append new sentence "If the subroutine is elemental, $x_2$ shall have the same shape as $x_1$." {Retain conformability as a normal requirement instead of as a condition.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-219 m208 F08/0147 submitted - passed by J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed as amended by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ---------------------------------------------------------------------- NUMBER: F08/0148 TITLE: Pointer subobject in structure constructor in pure procedure KEYWORDS: pointer subobject, structure constructor, pure procedure DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 4 QUESTION: Consider the module program P type :: T1 integer, pointer :: P1 end type T1 type :: T2 type(t1) :: P2 end type T2 type(t1), target :: V1 allocate ( V1%p1, source = 42 ) contains pure subroutine S ( ) type(t2) :: A 1 a = t2(v1) a%p2%p1 = a%p2%p1 + 1 end subroutine S end program P Item (3) in the list in constraint C1283 in subclause 12.7 prohibits an object that is accessed by host or use association (and other categories) to be the in a structure constructor that corresponds to a component that has the POINTER attribute. It is silent concerning type constructors for types that have potential subobject components with the POINTER attribute. Is the statement labeled 1 permitted? If so, was that intended? ANSWER: The statement labeled 1 was inadvertently allowed because V1 corresponds to a component of the structure constructor for type T2 that does not have the POINTER attribute. An edit is provided to correct this mistake. EDITS to 10-007r1: [312:35 12.7p2 C1283(3)] Replace this list item by "(3) as the corresponding to a component in a if the component has the POINTER attribute or has a pointer component at any level of component selection," SUBMITTED BY: Van Snyder HISTORY: 15-249 m208 F08/0148 submitted 15-249r1 m208 fix typos - passed J3 meeting 16-103 m209 Passed as amended by J3 letter ballot #34 16-101 N2087 m209 Passed by WG5 ballot #10 N2085/86 N2102 m209 In F2008 Corrigendum 4 N2094/N2097 ----------------------------------------------------------------------