From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Aug 4 06:04:43 2012 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 AD69D3568F2; Sat, 4 Aug 2012 06:04:43 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 874 seconds by postgrey-1.34 at www5.open-std.org; Sat, 04 Aug 2012 06:04:42 CEST Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 244433568B2 for ; Sat, 4 Aug 2012 06:04:41 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q743o3OL008540 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Fri, 3 Aug 2012 20:50:04 -0700 Subject: WG5 letter ballot 3 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Fri, 03 Aug 2012 20:50:03 -0700 Message-ID: <1344052203.9207.663.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-24.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk ISO/IEC JTC1/SC22/WG5 N1933 WG5 letter ballot 3 on Fortran 2008 interpretations John Reid, 3 August 2012 This is the third WG5 vote on a set of draft interpretations for Fortran 2008. They have all been approved in a J3 letter ballot. The rules we operate on say: --- --- 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. The following Fortran 2003 interpretations are being balloted: Yes No Number Title -Y- --- F03/0017 Dummy procedure pointers and PRESENT -Y- --- F03/0018 Multiple identical specific procedures in type-bound generic interfaces -Y- --- F03/0019 Multiple identical specific procedures in generic interface blocks -Y- --- F03/0021 What kind of token is a stop code? -Y- --- F03/0046 Unlimited polymorphic pointers in common blocks -Y- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0065 Relational equivalence --- -N- F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine The answer makes rounding mode changes pointless. The work-around usually advanced to cause rounding mode changes to have effect (but not advanced in the answer to the interpretation) is to store intermediate results that are computed with different rounding modes in VOLATILE variables if they are ultimately to be combined in a single expression. Subclause 5.3.19 states, in part, however, that "The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program." Setting the rounding mode is done by means that ARE specified by the program, so the advice is not germane. One who reads subclauses 5.3.19, 14.4, 14.11.6, and 14.11.21, and the answer to this interpretation, might not realize that the use of VOLATILE variables is required, under the present interpretation, for subclauses 14.4, 14.11.6, and 14.11.21 to be meaningful. A better answer would have been to amend 7.1.5.2.4 to require that all entities within the expression are evaluated with the same rounding mode, or to specify that quantities evaluated with different rounding modes cannot be considered to be mathematically equivalent, even if evaluated by textually identical expressions. This might require processors either to abandon certain optimizations, or to perform more detailed dataflow analysis that propagates rounding mode to determine when those optimizations are permitted. If the position implied by the answer to this interpretation is to be maintained, the absence of edits is entirely inadequate. The definition of VOLATILE must be changed to encompass actions that ARE specified by the program, and to encompass advice concerning rounding mode changes. Advice to store intermediate results that are computed with different rounding modes into VOLATILE variables, if they are to be combined in a single expression, must be included in subclauses 14.4 and 14.11.21. During the requirements phase for the 2008 standard, there was a request (in 04-219) for a "strict mode" similar to that described in section G.2 of the Ada standard, in which rounding mode settings would actually have an effect without needing to resort to VOLATILE variables. If a "strict mode" had been provided, it might have made sense to allow a processor to ignore rounding mode changes outside strict regions. A request for a "strict mode" will be presented during the requirements-gathering phase for the next revision of the standard, for this as well as other reasons. -Y- --- F03/0096 Can a read statement change the unit value? -Y- --- F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type -Y- --- F03/0116 indistinguishable specifics for a generic interface with use association -Y- --- F03/0118 Are lower bounds of assumed-shape arrays assumed? -C- --- F03/0120 When are parameterized sequence types the same type? There are typos in the discussion following question (5). In the fourth line of the second paragraph delete "are" before "can". In the sixth line of the second paragraph after the example after question (5), replace "It" before "2" with "Is". In the third line of the third paragraph delete "of" before "different". --- -N- F03/0121 Precise FP semantics of the REAL intrinsic The answer refers to subclause 7.1.5.2.4 without identifying that subclause: "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated," and uses that as justification for the answer. Subclause 7.1.5.2.4 is entirely irrelevant to the question. Subclause 4.1.2 specifies that "For each type there is a set of valid values." Subclause 4.2 specifies that "the set of values... depend[s] on the values of the parameters." Subclause 13.7.2, as amended by the answer to interp F08/0008, says, in part, "A program shall not invoke an intrinsic procedure under circumstances where a value ... returned as a function result is not representable by objects of the specified type and type parameters." Allowing the REAL intrinsic function to return a result that is claimed to have a specified kind, and a value that is not a member of the set of valid values for that kind, violates the requirements of subclauses 4.1.2, 4.2, and 13.7.1 as amended by interpretation F08/0008. An interpretation should not introduce an inconsistency that will later need to be resolved by yet another interpretation. Even if F08/0008 were to fail, the result of the answer to this interpretation would be to introduce a conflict to 13.7.1 status quo ante, which reads, in part, "A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters," and continues with caveats not germane to the present interpretation. The only reason ever to invoke the REAL intrinsic function with a real argument and a KIND argument is to produce a result with the specified kind, and a value that is a member of the set of valid values for that kind. This is exceedingly rare, except perhaps as an actual argument (where the processor must necessarily produce a value that is a member of the set of valid values, and additionally is represented by the specified type and kind), and therefore requiring processors to produce a value for the result of REAL that is a member of the set of valid values for the kind of the result would have no measurable effect on performance in any program other than an arcane SPEC benchmark. The answer should be "Although a processor is allowed to replace an expression with a mathematically equivalent expression, subclauses 4.1.2, 4.2, and 13.7.1 (or 13.7.1 as amended by interpretation F08/0008) require the value of the result of every intrinsic function to be a member of the set of valid values for the type and kind of the function result." No normative edits would be required, although it would be helpful to add a recommendation in a note (or a requirement) to 13.7.138p5 Case (i) that the result have a value that is not different from the argument by more than one unit in its least significant place (unless the argument is NaN), and that it be rounded according to IEC 60559:1989 and the rounding mode currently in effect if the IEEE_ARITHMETIC module is accessible (unless the argument is NaN). Advice in the presently proposed answer is offered to use the VOLATILE attribute. Subclause 5.3.19 states, in part, however, that "The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program." Invoking the REAL intrinsic function is a means that IS specified by the program, so the advice is not germane. One who reads subclauses 4.1.2, 4.2, 5.3.19, 7.1.5.2.4 and 13.7.1 would have no clue that the way to make REAL operate as essentially all users expect it to operate is to store its result into a variable that has the VOLATILE attribute! If one must have the presently proposed answer, having no edits is entirely inadequate. Subclause 5.3.19 must be amended to include effects that ARE specified by the program. Subclauses 5.3.19 and 13.7.138 must be amended to include advice to use the VOLATILE attribute to make REAL function as essentially all users expect it to. Further, there must be an explicit exemption for REAL in subclause 13.7.1, and maybe in 4.1.2 and 4.2 as well. A perverse reading of 13.7.1, adroitly sidestepping subclauses 4.1.2 and 4.2, might be that a function is allowed to return a value that is not a member of the set of valid values for the type and kind of the result, but that a program is not allowed to invoke the function in such a way as to produce that result. This would make it illegal instead of pointless to invoke the REAL intrinsic function with the hope to produce a value that is a member of the set of valid values for the kind of the result. That is, for example, that REAL is permitted to act consistently with the present answer to this interpretation, but a program is not permitted to invoke REAL(3.14159265358979323846264338d0,kind(1.0e0)) if the processor uses 32-bit IEEE arithmetic for default real, because the result would not be a member of the set of valid values. If so, in order to detect programs that are not standard conforming, a helpful processor should announce an error in this circumstance, which requires producing a value that is a member of the set of valid values, and comparing it to the proposed result value instead of using it as the result value. One might argue that 13.7.1 was aimed, for example, at SQRT(-1.0), for which the mathematical function approximated by the intrinsic function has no values that are representable by the type and kind of the result. But it doesn't say so, and that argument does not reasonably apply to REAL. Since 13.7.138p5 Case (i) explicitly says that REAL produces an approximation to its argument, it is more reasonable for REAL(3.14159265358979323846264338d0,kind(1.0e0)) to produce an approximation that is a member of the set of valid values for the kind of the result, than for its invocation to be prohibited, or for it to produce a result that is not a member of the set of valid values for the kind of the result. If a processor absolutely must reduce REAL with a real argument to the identity operation under certain circumstances, a command-line argument to cause this behavior could be provided, with a caveat that using that setting admits behavior that is not consistent with the standard. -Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? -Y- --- F08/0008 IEEE exceptions for intrinsic functions -Y- --- F08/0031 PURE INTENT(OUT) finalization -Y- --- F08/0032 PURE FUNCTION result finalization -Y- --- F08/0038 Are pointless restrictions on DIM arguments intended? --- --- F08/0040 MOVE_ALLOC for coarrays No vote here because F08/0040 is not included in N1932. This can be included in the next ballot if a revision of N1932 that includes F08/0040 accompanies that ballot. -Y- --- F08/0042 SOURCE= questions The text of these interpretations is in N1932. Each interpretation starts there 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 to sc22wg5@open-std.org by 0900 UK time on Friday, 31 August 2012, in order to be counted. Thanks, John.