From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Oct 5 11:41:47 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id A74B035690B; Wed, 5 Oct 2011 11:41:47 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-3-a-1.mail.uk.tiscali.com (mk-filter-3-a-1.mail.tiscali.co.uk [212.74.100.54]) by www.open-std.org (Postfix) with ESMTP id D197B3567FB for ; Wed, 5 Oct 2011 11:41:44 +0200 (CEST) X-Trace: 679208131/mk-filter-3.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/2.101.23.235/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.101.23.235 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGUljE4CZRfr/2dsb2JhbAAMNqYZhH0sJT0WGAMCAQIBSw0IAr8fhykEjk+FHoUVjDA X-IronPort-AV: E=Sophos;i="4.68,490,1312153200"; d="txt'?scan'208";a="679208131" Received: from host-2-101-23-235.as13285.net (HELO [127.0.0.1]) ([2.101.23.235]) by smtp.tiscali.co.uk with ESMTP; 05 Oct 2011 10:41:41 +0100 Message-ID: <4E8C2654.7080606@stfc.ac.uk> Date: Wed, 05 Oct 2011 10:41:40 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: WG5 Subject: Interps ballots Content-Type: multipart/mixed; boundary="------------010107010401060202000500" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------010107010401060202000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the final version of N1878, the result of interps ballot 1. Malcolm persuaded me to change the result of F08/0014 to be C because Bill did not raise any technical points. Also, here is the first draft of the preliminary result of interps ballot 1. I would like to explain two of my decisions and invite comments: F08/0026, Long vote. I don't think the edit allows the output of Q1. It says "If records are written to a sequential file by more than one iteration, the ordering between records written by different iterations is indeterminate." F08/0040, Snyder vote. I believe that J3 has already considered making MOVE_ALLOC an image control statement and rejected the idea. J3 should not be asked to reconsider this unless a majority in the WG5 vote request it. --------------010107010401060202000500 Content-Type: text/plain; name="N1884-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1884-1.txt" ISO/IEC JTC1/SC22/WG5 N1884-1 Preliminary result of the interpretations ballot 1, N1877 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. F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 Long Y Y Y Y Y N Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y C Snyder Y Y Y Y Y Y Y Y Y Y Result N C Y Y N Y Y N Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 Long N Y Y Y Y Y Y N Y Y Muxworthy Y Y Y Y Y C Y C Y Y Reid Y Y Y Y Y Y Y N Y Y Snyder N Y Y Y Y Y Y Y Y N Result Y Y Y N N Y Y N Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0042 0043 0044 0046 0047 0049 0050 0051 0052 0053 0054 Long N Y Y Y Y Y Y Y Y Y C Muxworthy Y Y Y C Y Y Y Y Y C Y Reid N Y Y C Y C Y Y Y C Y Snyder N Y Y Y Y Y Y Y Y C Y Result Y Y N C C Y Y Y Y Comments and reasons for NO votes .................................................................... F08/0026 Long NO vote: The example for Q1 shows output in the other order from what would occur for sequential execution of the loop. Q1 asks if allowing this was intentional. A1 says No, it was not intentional. Yet, the edit supplied says that the output is, in fact, allowed. I think that the answer A1 should be Yes. The edit is still desirable as a response to Q2/A2. .................................................................... F08/0031 Long NO vote: The proposed constraint requires that the INTENT(OUT) attribute on the dummy argument be visible to the code that would perform the finalization. This requires that the "as a matter of practicality" condition in the second paragraph of the DISCUSSION in fact always be true. This seems a bit weak for a constraint in the standard. A non-constraint would be better. I also found the wording of the proposed constraint, "shall not be such that..." unnecessarily vague. Something more direct would seem preferred, such as "The type of an INTENT(OUT) argument of a pure procedure shall not specify an impure final subroutine." Snyder NO vote: If a procedure has a polymorphic intent(out) dummy argument, the processor can't know if an impure final procedure would be invoked. Therefore, the specified new constraint (C1277a) can't be a constraint. My answer would be yes if F08/0033 passes. .................................................................... F08/0032 Long comment: I found the wording of the proposed constraint, "shall not be such that..." unnecessarily vague. Something more direct would seem preferred, such as "The type of the result value of a pure function shall not specify an impure final subroutine." .................................................................... F08/0036 Muxworthy comment: The edit draws attention to the definition of NORM2. This contains a recommendation on computation, at [375:4], which is the only 'recommendation' in subclause 13. Should it not be a Note, or be omitted altogether? .................................................................... F08/0037 Reid comment: The final edit is in 10.4 p8. .................................................................... F08/0038 Long NO vote: The text in 13.2.4, on which the subsequent edits depend, relies on a poorly defined concept of "reduction". In particular, some of the "reductions" that are cited in the edits are not what people normally think of as reductions (i.e. ones that return a result that is the same type as the input). It might be better in 13.2.4 to refer to Transformational functions that have a DIM argument. That is unambiguous. It would also cover the cases that currently would not be considered "reductions": FINDLOC, MAXLOC, MINLOC, ALL, ANY, PARITY, and THIS_IMAGE. Also, the COUNT intrinsic [338:31] seems to be missing from the list. Seems like an oversight. Muxworthy comment: Yes to the principle. I have not checked the edits pending the outcome of F08/0003. Reid NO vote I agree that it is desirable to describe all the functions with optional DIM arguments as a pair of specifics, one with the argument and one without. Doing this comprehensively makes F08/0003 redundant. It would be better to declare F08/0003 redundant and include all the edits here. There is no need for many of the edits in F08/0003. A bigger change in 13.2.4 p1 is needed. I suggest: [13.2.4p1 316:24-26] Replace the two sentences "These functions ... dummy arguments" by "An added DIM argument specifies the dimension to be reduced." .................................................................... F08/0040 Snyder NO vote We agreed that MOVE_ALLOC is useful, else we wouldn't have added it. I prefer that a call to it be an image-control statement. .................................................................... F08/0042 Long NO vote The example for Q2: program example2 real,allocatable :: x[:] allocate(x) x = 3 end says that it does not conform to the standard because of 6.7.1.1p4. This is irrelevant. It fails to conform to the standard because it violates C634. The allocate statement is required to be allocate(x[*]) at which point there is no SOURCE= issue involved. At a minimum, the example needs to be replaced with one that illustrates something related to SOURCE=. Reid NO vote I think the new C633 should have the words "and have the same rank as " added at the end, as in the old C633. Snyder NO vote The revised C633 allows the possibility that an that is an array can be allocated without an and a scalar . My vote would be yes if there were an additional sentence something like "If does not appear, shall not be a scalar." .................................................................... F08/0046 Muxworthy comment: The edit should be to page xv. Reid comment: The edit is on page xv. .................................................................... F08/0049 Reid comment: In the first edit, add "constant" before "expression" to avoid ambiguity. .................................................................... F08/0053 Muxworthy comment: In the edit, the reference to (9.6.4.8.3) should immediately follow "arguments". Reid comment: In the edits, remove "Editor:" twice (not our style for corrigendum edits). At the end of the first edit, add "(9.6.4.8.3)" and delete the sentence "Insert ...". Snyder comment: The word "nvocation" in Question (2) should be "invocation". .................................................................... F08/0054 Long comment: This proposes a fix to something that is broken in both F2003 and F2008. Since the change is only in F2008, it then a change from F2003 that should be listed in 1.6.2? --------------010107010401060202000500 Content-Type: text/plain; name="N1878.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1878.txt" ISO/IEC JTC1/SC22/WG5 N1878 Result of the interpretations ballot 1, N1876 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. F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0030 0048 0085 0091 0096 0105 0110 0121 0123 0124 Bader Y Y Y Y Y Y Y Y Y Y Cohen C Y Y Y C Y Y Y Y Y Corbett N Y Y Y N Y N C Y Y Long Y Y Y Y C Y Y C Y Y Muxworthy Y Y Y Y N Y Y Y Y Y Reid N Y Y Y C Y Y Y Y Y Snyder N C Y Y N Y Y N Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Y Result N C Y Y N Y Y N Y Y F03/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0128 0001 0002 0003 0004 0006 0007 0008 0009 0010 Bader Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y N Y Y Corbett Y Y Y Y Y Y Y N Y Y Long Y Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y N N Y Y Y Y Y Snyder Y Y Y Y Y Y C N Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Y Result Y Y Y N N Y Y N Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0011 0013 0014 0015 0016 0017 0018 0019 0020 Bader Y Y Y Y Y N Y Y Y Cohen Y Y C Y Y Y Y Y Y Corbett Y Y Y Y Y Y Y Y Y Long Y Y N Y C C Y Y Y Muxworthy Y Y Y Y Y Y Reid Y Y Y C C Y Y Y Y Snyder Y Y Y Y Y Y C Y Y Whitlock Y Y Y Y Y Y Y Y Y Xia Y Y Y Y Y Y Y Y Y Result Y Y C C C Y Y Y Y comments and reasons for NO votes .................................................................... F03/0030 Cohen comment: Van's comment on 13.7.1 also being wrong is well taken, but refers to an issue that is separate from that considered by the interpretation. In my opinion 13.7.1 should be fixed in a separate interp, e.g. F08/0008 which actually does ask about intrinsic functions. Corbett NO vote The proposed interpretation and edits make no sense unless one assumes that the intent is to redefine and repurpose the function IEEE_SUPPORT_DATATYPE. If that is the intent, the interpretation and edits should address the issue directly instead of modifying seemingly unrelated text. Reid NO vote I agree with Bob Corbett that it is inappropriate to refer to IEEE_SUPPORT_DATATYPE since 14.9 makes it clear that support requires: "for at least one rounding mode, the intrinsic operations of addition, subtraction and multiplication shall conform whenever the operands and result specified by IEC 60559:1989 are normal numbers". To avoid a conflict with IEC 60559:1989, I suggest that the words in the first two bullets points of 14.3 be changed to apply only to cases where the operands are normal numbers. Snyder NO vote Edits could be construed to introduce a contradiction between 13.7.1 and 14.3. My vote would be yes if the penultimate sentence of 13.7.1p2 began "If support is provided and an infinite result...." .................................................................... F03/0048 Snyder comment: In the second paragraph of the answer, "possibility" should be "possibly" .................................................................... F03/0096 Cohen comment I agree that adding "in the same statement" to the end of the sentence in the second edit would be an improvement. I do not agree with the comments about SIZE=; both it and the input-items depend on the input file contents, but I don't see how it depends on the input-items directly. Corbett NO vote The second proposed edit prohibits the value of a SIZE= specifier from depending "on any ." That seems to require the value of a SIZE= specifier to be constant. Long comment The wording of the second edit suggests that the SIZE= value returned cannot depend on the input list, which is not what is intended. I think this can be corrected by adding " the values of" after "shall not depend on" in the edit. Muxworthy NO vote I agree with Robert Corbett's comment. Reid comment In the second line of the question change "an" to "a". Snyder NO vote My vote would be yes if the sentence introduced at the end of 9.12p5 included "in the same statement" (as does the existing sentence in that paragraph). .................................................................... F03/0110 Corbett NO vote The last sentence of the proposed interpretation contradicts the conformance clause of the standard. .................................................................... F03/0121 Corbett comment Fortran programmers need the functionality proposed in the request for interpretation. The mechanism proposed corresponds to what many Fortran programmers already assume to be the case. The committee should either adopt the proposed mechanism or provide an alternative mechanism. Long comment My reading of the original question included a desire to say that the result value for REAL(X, KIND=wp), for a particular value of X, is the SAME result value independent of the context in which the function reference appears. After all, it would not really be a "function" in the normal sense if that were not the case. The subsequent discussion in the ANSWER section could cast doubt on whether this basic requirement is actually true. It would be better to explicitly state that REAL for a particular set of arguments always returns the same result value independent of the context. Snyder NO vote Un ugly unsatisfying answer that appears to have been crafted by a politician trying to evade the real issue, perhaps because of a deficit of knowledge of issues important in numerical analysis. I don't understand the necessity for REAL not to do what it says it does. The answer simply confirms a contradiction. My answer would be yes if the answer were that REAL(,KIND=k) returns a value that is the same value that a REAL variable of kind k would have, if were to have been assigned to that variable. After all, REAL is a function, and therefore has a result variable to which its result value is assigned. .................................................................... F08/0003 Reid NO vote There are too many edits for what is really a small correction. It would be much better to leave all the optional DIM arguments as optional and use the form of words used for COUNT. This would more than halve the number of edits. .................................................................... F08/0004 Reid NO vote As the question points out, the descriptions of arguments apply to actual arguments. In the example, Target is a disassociated pointer so TARGET in the description is present and is a disassociated pointer. 12.5.2.12 is not applicable here because it is all about dummy arguments. Case (vi) is applicable and tells us that the result is false. No edits are needed. .................................................................... F08/0007 Snyder comment One's complement is not the only case in which signed zero could arise. Sign magnitude (e.g. IBM 7094) or decimal machines (IBM 7010 etc.), or XS3 machines (Univac 1005). But these are irrelevant now. .................................................................... F08/0008 Cohen NO vote The quoted text in 13.7.1 is just wrong and needs to be fixed. Corbett NO vote If the statement in the standard that "the flag IEEE_INVALID shall signal" is, as is stated in the interpretation, is incorrect, the text of the standard should be altered to reflect that. Snyder NO vote See answer to F03/0030. There are no edits here, but arguing that the requirement in 13.7.1p2 does not apply admits a contradiction. My answer would be yes if there were an edit causing the penultimate sentence of 13.7.1p2 to begin "If support is provided and an infinite result...." .................................................................... F08/0014 Cohen comment: Bill raises 3 possible "options" of the interpretation: (1) and (3) are equivalent (they both avoid doing the thing that is forbidden, who cares HOW the user avoids breaking the rule!) and (2) is contradicted by the existing text in the standard, so I see no quandary. Long No vote The proposed edit is to add this text: "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine". This is stated as a requirement on the user (program). It is unclear to me what this really means. Here are some options that come to mind: 1) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would be finalized, the type shall specify an elemental final subroutine. 2) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would otherwise be finalized, the section is not finalized if there is no elemental final subroutine. 3) For a type that specifies final subroutines, a vector-subscripted array section of that type shall not appear in a context where it would be finalized unless the type specifies an elemental final subroutine. .................................................................... F08/0015 Reid comment In the edit, delete "confusing". Edits go into the corrigendum, where we do not include any explanation. .................................................................... F08/0016 Long comment In the third line of the ANSWER, there is a typo: "copvers" -> ""covers". Reid comment There is a typo in the ANSWER, 'copvers'. .................................................................... F08/0017 Bader NO vote: As specified in the NOTE there, the edit is intended to be subsumed by edits in F08/0018. Long comment The discussion section paragraph is: "The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow." This is a bit of a shock, since almost all compilers would, in fact, not perform the addition at all in test_add. Certainly we are not intending to imply that this common optimization is now illegal. Subroutine test_add contains no references to the IEEE modules. I would prefer to either delete this paragraph from the ANSWER, or to delete the end of the sentence following "useful". Further, the calls to the IEEE routines in the caller are a distraction from the point of the question, and could be deleted as well. .................................................................... F08/0018 Snyder comment Edits in F08/0018 subsume those in F08/0017 --------------010107010401060202000500--