J3/14-279 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #32 revised - due 9-Jan-2015 Date: 2014 November 25 Enclosed in the next letter ballot on Fortran interpretations. The rules for interpretation handling 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. 12 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #205. 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/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? --- --- F08/0110 Interdependence of specifier values in input/output statements --- --- F08/0115 ASYNCHRONOUS and argument passing --- --- F08/0116 Interoperable procedures --- --- F08/0117 TARGET and coindexed arguments --- --- F08/0118 Subobject of variable in variable definition context --- --- F08/0119 Branching to END BLOCK and END CRITICAL --- --- F08/0120 Is the name of a procedure pointer a local identifier? --- --- F08/0121 Add to introduction defined operations in specification exprs --- --- F08/0122 Types with coarray components --- --- F08/0123 SPACING intrinsic --- --- F08/0124 Coindexed object with polymorphic subcomponent 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, 9-Jan-2015, in order to be counted. Thanks /Stan ------------------------------------------------------------------------ NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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, 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/output storage sequence affector from being associated with a dummy argument that has the VALUE attribute. EDIT 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 ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: 1. Are the following INQUIRE statements permitted? LOGICAL :: Exist, Opened INQUIRE ( FILE='fred', EXIST=exist ) INQUIRE ( UNIT=42, OPENED=opened ) 2. Is the following INQUIRE statement permitted? INTEGER :: U INTERFACE FUNCTION P ( A ) INTEGER, INTENT(IN) :: A INTEGER, POINTER :: P END FUNCTION P END INTERFACE INQUIRE ( FILE='fred', NUMBER=u, POS=p(u) ) 3. Is the following READ statement permitted? INTEGER :: STATS(42) NAMELIST /IN/ V READ ( *, IN, IOSTAT=STATS(V) ) ANSWERS: 1. According to 9.12p5 [243:3-5] "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." the INQUIRE statements are prohibited because the values of the variables EXIST and OPEN depend upon the values of the FILE= and UNIT= specifiers, respectively. They were intended to be permitted. Edits are provided to correct this mistake. 2. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statement is not prohibited because U is not a subscript or substring bound. According to 7.1.4p2 [139:3-4] "The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." the INQUIRE statement is not prohibited because, although U is assigned a value, it is not evaluated. The INQUIRE statement was intended to be prohibited. Edits are provided to correct this mistake. 3. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." and 9.12p7 [243:9-11] "In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if any, shall not be associated with any entity in the ... ...." and 9.12p8 [243:12-14] "In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an array element reference, its subscript values shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the ." the READ statement is not prohibited because V does not "depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." Although V is input from namelist, it is not "the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier." The READ statement was intended to be prohibited. Edits are provided to correct this mistake. EDITS to 10-007r1: [243:3-5 9.12p5] Within the second sentence, provided by Corrigendum 2, replace "values of any or" with "value of any". Append ", or be affected by data transfer caused by that statement". That sentence becomes "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT=, or SIZE= specifier shall not depend on the value of any in the same statement, or be affected by data transfer caused by that statement." {Using "data transfer" instead of "" covers the namelist case.} [243:6-7 9.12p6] Replace "value of any subscript or substring bound" with "denotation". Replace "depend ... " with "be affected by the data transfer, the processing". The paragraph becomes "The denotation of a variable that appears in a specifier in an input/output statement shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the or in that statement." After the paragraph, insert a note: NOTE 9.nn The semantics of how a variable is denoted is its "denotation"; this includes such things as component and array element selection. Anything that affects this process is prohibited in this context; that includes the values of any subscripts used, and if the variable is specified by a pointer function reference, anything that affects the evaluation of that function. {Using "data transfer" instead of "" covers the namelist case.} [243:9 9.12p7] "Insert "ID=," before "IOSTAT". {Not mentioned in a question, but was a problem.} [243:12-14 9.12p8] Repairing the paragraph would make it equivalent (if not identical) to 9.12p6, as revised above. Therefore, delete the paragraph. SUBMITTED BY: Van Snyder HISTORY: 14-193 m204 F08/0110 submitted 14-193r1 m204 Revised 14-272r1 m205 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0115 TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or". SUBMITTED BY: Nick Maclaren HISTORY: 14-218 m205 F08/0115 submitted 14-218r1 m205 Revised 14-218r2 m205 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [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 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [300] 12.5.2.13p1(3)(b) append to the end of the paragraph "or a coindexed object". [300] 12.5.2.13p1(4)(b) append to the end of the paragraph "or a coindexed object". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-223 F08/0117 submitted m205 14-223r1 Revised example and discussion - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ) 1 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: [170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801, Between "" and "shall not appear" insert "or any subobject of ". [171:12] 8.1.3.3 Attributes of associate names, p2, Between "the associate name" and "shall not appear" insert "or any subobject of the associate name". [184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836, Between "" and "shall not" insert "of any subobject of ". SUBMITTED BY: Van Snyder HISTORY: 14-240r1 m205 F08/0118 submitted 14-240r2 m205 Revised question and answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [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 constraints: "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." "C847b If a branch target statement is a , the branching statement shall be within the range of the corresponding ." 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 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 emend the oversight. EDITS: [440:4, 16.3.1p1] Replace "named constants, named" with "named constants, named procedure pointers, named". SUBMITTED BY: Robert Corbett HISTORY: 14-256 m205 F08/0120 submitted - Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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. EDIT to 10-007r1: Introduction, page xv. Add to the "Data declaration" list in paragraph 2: "A may 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 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [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+, "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 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 inadvertant 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 inadvertantly 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", 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}$. SUBMITTED BY: Malcolm Cohen HISTORY: 14-263 m205 F08/0123 submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: [6:7+] After 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" {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 ----------------------------------------------------------------------