12-nnn To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #26 - due 12-Oct-2012 Date: 12-Sep-2012 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 10 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #198. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F08/0040 MOVE_ALLOC for coarrays --- --- F08/0074 Implicit type in BLOCK construct --- --- F08/0075 Pointer function reference as variable in assignment --- --- F08/0076 Pointer function reference in READ --- --- F08/0077 Function references as variables in DATA statements --- --- F08/0078 Are the IEEE values +0 and -0 distinguished --- --- F08/0079 NAMELIST and type specification --- --- F08/0080 Array constructors with polymorphic values --- --- F08/0081 Deallocation error handling --- --- F08/0082 Generic identifier and dtv arguments The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Friday, 12-Oct-2012, in order to be counted. Thanks /Stan ------------------------------------------------------------------------ NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: that is, the dummy arguments of MOVE_ALLOC do not technically have corank. An edit is supplied to clarify C541. EDITS to 10-007r1: [97:13] In 5.3.10 INTENT attribute, Change "entity" to "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 ---------------------------------------------------------------------- NUMBER: F08/0074 TITLE: Implicit type in BLOCK construct KEYWORDS: IMPLICIT, BLOCK DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 Submitted. 12-151r1 m198 Revised edit. 12-151r2 m198 Clarified answer, passed J3 meeting. ------------------------------------------------------------------------ NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 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? ANSWER: It was an oversight that this program conforms to the syntax and constraints in two different ways. An edit is supplied to remove the ambiguity. EDITS: [45:7] 3.3.1p1 append new sentence "The first nonblank character of a statement that is not part of a statement shall not be a digit." SUBMITTED BY: Van Snyder HISTORY: 12-149 m198 F08/0075 submitted 12-149r1 m198 Revised edit. 12-149r2 m198 Clarified answer, passed J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0076 TITLE: Pointer function reference in READ KEYWORDS: Pointer function reference, READ, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ? ANSWER: 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. EDITS: [212:2+] 9.6.1, After R910, insert constraint "C909a (R910) shall not begin with an operator." SUBMITTED BY: Van Snyder HISTORY: 12-150 m198 F08/0076 submitted 12-150r1 m198 Revised answer and edits, passed J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0077 TITLE: Function references as variables in DATA statements KEYWORDS: function, reference, DATA DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 , not an . Each subscript, section subscript, substring starting point, and substring ending point in the shall" SUBMITTED BY: Robert Corbett HISTORY: 12-153 m198 Submitted 12-153r1 m198 Revised edits, passed J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0078 TITLE: Are the IEEE values +0 and -0 distinguished KEYWORDS: IEEE, zero, IEEE_SUPPORT_DATATYPE DEFECT TYPE: Clarification STATUS: Passed by J3 meeting 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: None. SUBMITTED BY: Robert Corbett HISTORY: 12-154 m198 Submitted 12-154r1 m198 Revised answer, passed J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0079 TITLE: NAMELIST and type specification KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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),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. ---------------------------------------------------------------------- NUMBER: F08/0080 TITLE: Array constructors with polymorphic values KEYWORDS: Array constructor, polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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_003a 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 ] 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.8, 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;". SUBMITTED BY: Malcolm Cohen HISTORY: 12-159 m198 F03/0080 submitted 12-159r1 m198 Revised edits. 12-159r2 m198 Fixed typo, passed J3 meeting. ---------------------------------------------------------------------- NUMBER: F08/0081 TITLE: Deallocation error handling KEYWORDS: FINAL, DEALLOCATE, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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.3p1 "If an error condition occurs in 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:33+] In A.2, After "whether and when an object is finalized ... (4.5.6.3);" Insert 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 ---------------------------------------------------------------------- NUMBER: F08/0082 TITLE: Generic identifier and dtv arguments KEYWORDS: Generic, Defined i/o DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 READ(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 ----------------------------------------------------------------------