ISO/IEC JTC1/SC22/WG5 N1816 Result of the interpretations ballot 7, N1806 Key for the Result line: Y Vote passes unconditionally. C Vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N Vote fails. Returned to J3 for further work. F95/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0098 0022 0024 0034 0039 0063 0071 0078 0090 0112 Bader Y Y Y Y Y Y Y N C Cohen C N N N Corbett N N Y C N N Y C Y Y Long Y Y Y C C C Y Y C Y Maclaren Y Y Y C Y Y Y Moene Y Y Y Y Y Y Y C Y Y Muxworthy Y Y Y C Y C Y Y Y Y Reid Y Y Y Y N Y Y Y Y Y Sleightholme Y Y Y Y Y Y Y Snyder Y Y Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result Y Y Y Y C C Y Y C Y F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0119 0122 0125 0126 0127 0129 0130 0131 0132 0133 Bader Y Y Y Y Y Y Y Y Cohen C N Corbett Y Y Y Y Y Y Y N Y Y Long Y Y Y Y Y Y Y Y Y Y Maclaren Y Y Y Y Y Y Moene C Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y N Y Y Y Y Sleightholme Y Y Y Y Y Y Y Y Y Snyder Y Y Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result Y Y Y Y Y Y Y Y Y Y F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0134 0135 0136 0137 0138 0139 0140 0141 Bader Y Y Y Y N Y Y N Cohen C C C N Corbett Y Y Y N N Y Y Y Long Y C Y Y Y Y Y Y Maclaren Y Moene Y Y Y Y Y Y Y Y Muxworthy Y C Y Y C C Y Y Reid Y N Y Y Y C Y Y Sleightholme Y Y Y Y Y Y Snyder Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Result Y C Y Y C N Y C Comments and reasons for NO votes F95/0098 Corbett no Assumed-length character dummy functions are an obsolescent feature included for FORTRAN 77 compatibility. The answer given here is incompatible with the specification of assumed-length character dummy functions in FORTRAN 77. Section 15.2 of the FORTRAN 77 standard [page 15-2, 5-8] states If a character function is referenced in a program unit, the function length specified in the program unit must be an integer constant expression. Item (4) in the last paragraph of Section 4.4.4.1 of the Fortran 2003 standard [page 41, 34-37] should be interpreted as specifying the same requirement. The proposed interpretation requires variable amounts of space to be allocated for character returning functions. The FORTRAN 77 standard was designed to allow implementations that use only static storage allocation. Thus, the proposed implementation cannot be the interpretation intended by the FORTRAN 77 standard. .................................................................... F03/0022 Corbett no Note 14.2 strongly suggests that the restriction imposed by the text in question was intended. The change in the proposed interpretation serves no purpose for any architecture of which I am aware. .................................................................... F03/0034 IEEE_LOGB() Muxworthy comment The style of the two new cases would be more consistent with that of the existing cases if the order of the conditions were reversed ("If X is infinite and IEEE_SUPPORT_INF(X) is true ..." etc). This applies also to F2008. Long comment I agree with David's comment that the wording of the edits should be inverted to be "If X is ... and IEEE_SUPPORT_... is true, ..." Corbett comment The proposed interpretation is compatible with the 1985 edition of IEEE Std. 754. The definition of logb changed in the 2008 edition of IEEE Std. 754. I do not object to using the old definition of logb (I voted C, not N), but it might be worth noting the difference. Cohen comment Robert Corbett suggests noting the difference between IEEE_LOGB and the definition of "logb" in 754-2008 (the 754 committee having decided to change it from the 754-1985 version). This would not make sense in the context of a Fortran 2003 interp (since we have no time machine); nor, since the normative reference in Fortran 2008 is also to 754-1985, is it necessary there. .................................................................... F03/0039 - HYPOT() Maclaren comment The reason given in the third paragraph is misleading, even erroneous. It would be true if the NaN stood for an unknown numeric value (perhaps infinite), but is not true if the NaN stands for the result of an improper calculation. For example, HYPOT(1.0,LOG(-1.0)) - see 14.3 paragraph 5. Note that the IEEE committee has (effectively) taken the decision to ignore such NaN values (as well as true not-a-number values - i.e. out-of-band ones) in functions like HYPOT (see section 9.2.1 of IEEE 754-2008). Better wording would be: HYPOT(X,Y) when X and/or Y is an infinity (even if the other is a NaN) shall be +infinity. Reason: that is specified in the IEEE 754-2008 standard (section 9.2.1). It is mathematically correct if the NaN value is replaced by a zero, any finite number, or any infinity. ...... Long comment Nick's comments about the IEEE nonconformance of the proposed change might be considered for 13.7.69 "HYPOT (X, Y)" in F08 09-007r3[353:18-27]. The HYPOT defined in Note 14.7 is not really claimed to be the official IEEE HYPOT, but rather is a contrivance to illustrate the setting and getting of IEEE flags. I would argue that if we decide to include the suggested edit, it defeats the current comment of "Try the fast algorithm first". With this new code, the algorithm is no longer fast. The comment should be deleted. Further, instead of somewhat obscure HYPOT = SQRT(-1.0) why not be clear about the intent and write HYPOT = IEEE_VALUE(X, IEEE_QUIET_NAN) However, the initial sentence of the Discussion section notes that "if either X or Y is a NaN, the [statement HYPOT = SQRT( X**2 + Y**2 ) ] will set HYPOT to a NaN..." which is exactly what the inserted code does. So the proposed edit adds no useful functionality and causes the code to run slow. It seems better to not add the new code and, instead, add a comment line in the code noting that a NaN argument would result in a NaN result. It might also make Fred Tydeman happier if the Note pointed out that the example is not an implementation of the IEEE HYPOT function (at least it's not a valid one). I believe that Fred (and maybe Nick) would be happy of the name of the function were something other than HYPOT, to avoid confusion with the IEEE HYPOT function. ...... Reid no The IEEE floating-point is carefully designed to handle NaNs and infinities in the hardware. It is inappropriate to add explicit code that duplicates it. It is specially inappropriate in this case, where the aim is for fast execution whenever possible. The intended effect on the reader may be achieved with this alternative for the first edit. [page 389]. Subclause 14.11, Note 14.17, after the comment "! The processor clears the flags on entry" insert "! If either X or Y is a NaN, the first executable statement ! will set HYPOT to a NaN without signaling an exception." ..... Cohen no The suggested edit is not valid Fortran. Any of the following responses would be acceptable. (a) ANSWER: The HYPOT example in note 14.17 illustrates the use of the features of this section to provide reliable software that is fast in the uncomplicated case. It is not intended to be the C "hypot" function. {No DISCUSSION.} EDIT: None. (b) ANSWER: The HYPOT example in note 14.17 illustrates the use of the features of this section to provide reliable software that is fast in the uncomplicated case. It is not intended to be the C "hypot" function. DISCUSSION: In fact, if either X or Y is a NaN, the first executable statement will set HYPOT to a NaN without signaling an exception. The slower code in the IF construct will therefore not be executed and a NaN will be returned, which is consistent with the way NaNs are handled by intrinsic operators, see paragraph 3 of section 6.2 of the IEEE International Standard. EDIT: [388] After the "Try a fast algorithm first" comment, insert "! (If either X or Y is a NaN, this will set HYPOT to a NaN ! without signaling an exception.)" ..... Corbett no The proposed change obscures the point that the example given in Note 14.17 is intended to make. ................................................................. F03/0063 Procedure pointers in BLOCK DATA program units Muxworthy comment Nit-pick: In the edit for [98:21] "allocatable" should read "allocatable," ..... Long comment 1) I agree with the comment of David that a comma should be inserted after 'allocatable' in the edit instructions for the edit at [98:21]. 2) In 5.5.2.3 "Common association" at [100:12-15] there are three sentences beginning "A procedure pointer shall be storage associated ...." through the end of the paragraph. Should these three sentences be deleted? Corresponding reference in 09-007r3 is [115:35-38] 5.7.2.4 "Common association", paragraph 6. 3) It seems like in item (8) in the list of 16.4.3.1."Storage sequence", [416:23-24] "pointer" should be "data pointer". If procedure pointers can be in a storage sequence, then a list item (9) should be created for them, and text similar to [100:12-15] might be used. In 09-007r3, [451:33-36] in 16.5.3.2 "Storage sequence". ..... Cohen no As Bill Long pointed out, this version leaves junk in the standard that thinks procedure pointers are allowed in COMMON blocks. Therefore the edits need to include [100:12-15] Delete "A procedure ... type parameters.". As for Bill's other suggestion re the definition of storage sequence, I don't think that matters since procedure pointers should not appear therein. OTOH, I have no objection to his suggested [416:23-24] "pointer"->"data pointer" and this is a certainly a good idea for F2008. I also agree with David Muxworthy's suggested change for the [98:21] edit (insert comma after allocatable). ........... Corbett no Reason not given. ...................................................................... F03/0078 Moene comment This answer might come back to haunt us. People who want to follow IEEE 754 strictly *need* the assurance that the text of the program is followed verbatim, because, although X(I) / A is mathematically equivalent to X(I) * (1/A), it certainly isn't in IEEE 754 arithmetic (compilers do this to turn division by a loop-invariant into a cheaper multiplication). ....... Corbett comment I agree with the comments of others that the proposed interpretation makes the IEEE modules less useful. ...................................................................... F03/0090 - Polymorphic array constructors Long comment Should the edit for [68:9] also be applied to [68:11]? The is effectively a declaration of the type of the constructor, so saying "declared type" seems clearer. It also results in more parallel language - two paragraphs saying how the declared type is determined, followed by a paragraph saying that the dynamic type is the same as the declared type. ...... Cohen no Technical objection: 1. There is no edit that prohibits an array contructor ac-value from being unlimited polymorphic (i.e. CLASS(*)); we should state this directly, not make people infer it from more difficult rules. Proposed fix: [67:19+] Insert new constraint "An shall not be unlimited polymorphic.". Philosophical maunderings: 2. The answer impedes any future extension to allow polymorphic array constructors. The obvious way to prevent closing the door to future extension is to prohibit an ac-value from being polymorphic. Possible change: [67:19+] Insert different new constraint instead "An shall not be polymorphic.". 3. The situation in point 2 above is a bit unfriendly. Furthermore the comment that a function can be used to safely construct a polymorphic array is slightly naive: this requires separate processing for each potential dynamic type, so does not scale well. Possible response: Change the answer to allow polymorphic array constructors. ..... Bader no The answer to question (2) appears to be overly restrictive; If the first two edits are adopted and the restriction is added that the dynamic type of all element values must be the same, question (3) would also be satisfactorily answered. ....................................................................... F03/0112 comment Bader I do not understand the answers provided in the interp text. In detail: "Preventing the first argument from having the POINTER attribute violates F90." If this statement refers to the Fortran 90 or Fortran 95 standard, it appears to be simply untrue. In these standards, the code from Q2. would be rejected since it was not allowed to specify INTENT for entities with the POINTER attribute. In the Fortran 2003 context - as indicated in the answer - no problem occurs with specifying these attributes. Indeed, producing polymorphic entities is impossible to do without using these attributes. Perhaps this should be mentioned in the answer rather than referencing past and therefore irrelevant standards. "Preventing the second argument from having the ALLOCATABLE attribute would introduce a prohibition not specified by TR 15581, and might therefore be viewed as an incompatibility that ought to be announced in subclause 1.5." Considering it is not possible to use such an interface as a specific in defined assignment as indicated by the suggested NOTE, it is unclear to me what purpose this sentence has. Perhaps it can be simply omitted? Furthermore, the interp's argumentation would surely also apply to defined operations. Should NOTE 12.9 not be correspondingly changed or removed? ................................................................... F03/0119 Moene comment Do we want to lift the restriction prohibiting example 2 in the future ? ................................................................... F03/0129 Reid no The third edit should be [396:5-7] Replace "; if ... one." with ". If the type is character, it is interoperable if and only if the value of its length type parameter is one." Reason: It makes no sense to talk about the length type parameter being interoperable. ...... Cohen comment John Reid writes: >The third edit should be >[396:5-7] Replace "; if ... one." with > ". If the type is character, it is interoperable if and only if > the value of its length type parameter is one." > Reason: It makes no sense to talk about the length type parameter > being interoperable. Au contraire, it makes reasonable sense given "A Fortran intrinsic type with particular type parameter values is interoperable ..." In any case the existing edit is superior, the suggested edit is contradicted by the existence of CHARACTER with KIND/=C_CHAR. ..................................................................... F03/0131 Corbett no The proposed interpretation imposes unnecessary limitations on the optimizations allowed. Variables should not acquire the SAVE attribute by contagion. ..................................................................... F03/0133 Cohen no This interp should be marked as a duplicate of interp F03/0046, which in fact it is. F03/0046 is currently failing as a result of inconsistencies between it and F03/0053. I think it would be best to consider the original (0046 and 0053) together and not just to pass one of them. I apologise for raising this duplicate. ..................................................................... F03/0135 Interaction between RESULT, recursion, and host generic Muxworthy comment The edit at [276:36+] should read "that scoping unit" rather than "the scoping unit" for consistency with the other cases. ....... Long comment I agree with David that the "the" in the first edit should be "that". In addition, the "(a2)" in the first edit would normally be denoted "(a1)" (even though the actual numbering is automated). It would save people looking for the missing a1. ..... Reid no A subprogram and its scoping unit are not the same thing, see the definition at [12:1]. In both edits, add "of" after "scoping unit is". ..... Cohen comment I agree with David Muxworthy's change to the edit for [276:36+] ("the"->"that"). I agree with John Reid that the word "of" should be added after "scoping unit is" in both edits. ................................................................... F03/0137 Corbett no The proposed interpretation makes codes that once conformed to the written requirements of the standard nonconformant. Furthermore, there is no obvious way to mechanically translate those codes into conforming codes. The restriction offered in the proposed interpretation should be rejected. ................................................................... F03/0138 External as Muxworthy comment The proposed edit results in rather opaque English. Changing "association, referenced" to "association and is referenced" gives a slight improvement. The constraint would then be: 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 (•), 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. ....... Bader no The answer to (2) does not provide a rationale. Do I understand correctly that it is the "CALL X" statement in example1 which establishes X to be known as an external procedure? If so, why is having "X" on the right hand side of a procedure pointer assignment considered insufficient for the same purpose? ....... Corbett no I agree with Reinhold Bader's observation that the targets of procedure pointer assignments should be assumed to be procedures. ....... Cohen comment Reinold Bader asks why is having "X" on the right hand side of a procedure pointer assignment considered insufficient Mostly because "p => x" does not give any visual clue that X is a procedure. Partly also because it would be problematic if we added user-defined pointer assignment. Procedure pointers (and their targets) are modelled closely on dummy procedures (and their corresponding actual procedures); those require an explicit EXTERNAL attribute, but we felt that in the case of a procedure reference (e.g. "CALL x") in the scoping unit it was sufficiently obvious and unlikely to be problematic that we could diverge from the argument requirements in that case. Finally, it was not our intent to require compiler (and user) inference of procedureness of being a target in the pointer assignment case; omission of wording here was accidental. Post-finally, should we ever allow user-defined pointer assignment, we definitely would not want inference as that would clash with generic resolution. ........................................................................ F03/0139 Reid comment In the edit for [407:21-22] change "which" to "that". ..... Muxworthy comment The edit at [417:18] should be: Change "of the result variables" ... ..... Cohen comment The word "which" in the edit for [407:21-22] is correct. ........................................................................ F03/0141 Bader no While I agree with the answer, I think the proposed edit is more confusing than clarifying (a procedure name does not have an interface). I'd suggest adding suitable text to 11.2.1 instead, perhaps something like [252:24+] The interface of any local identifier of a procedure is that of the procedure, except that its name is replaced by the local identifiers' name. ...... Cohen no On reflection, I agree with Reinhold Bader's comment that the edit does not really make sense. Here is an alternative edit: [260:2] After "scoping unit" insert ", except that if the interface is accessed by use association, there may be more than one local name for the procedure". {Yes, here we really do want "may", because we are giving permission.} If it's not otherwise clear, we might want to also say "If a procedure is accessed by use association, each access shall be to the same procedure declaration or definition."