From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Aug 30 11:59:50 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 61BEE356973; Thu, 30 Aug 2012 11:59:50 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1899 seconds by postgrey-1.34 at www5.open-std.org; Thu, 30 Aug 2012 11:59:49 CEST Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by www.open-std.org (Postfix) with ESMTP id 3C1D9356854 for ; Thu, 30 Aug 2012 11:59:49 +0200 (CEST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7U9SBko032201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Aug 2012 09:28:11 GMT Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7U9S77N014555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Aug 2012 09:28:08 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7U9S7x7002036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 09:28:07 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7U9S65H020014 for ; Thu, 30 Aug 2012 04:28:07 -0500 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Aug 2012 02:28:06 -0700 Message-ID: <503F31DC.20408@oracle.com> Date: Thu, 30 Aug 2012 02:26:52 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:6.0) Gecko/20110814 Thunderbird/6.0 MIME-Version: 1.0 To: WG5 Subject: WG5 letter ballot 3 on Fortran 2008 interpretations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rcsinet15.oracle.com [148.87.113.117] Sender: owner-sc22wg5@open-std.org Precedence: bulk WG5 letter ballot 3 on Fortran 2008 interpretations 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 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 --- -N- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -C- --- F03/0065 Relational equivalence --- -N- F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine -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? -Y- --- F03/0120 When are parameterized sequence types the same type? --- -N- F03/0121 Precise FP semantics of the REAL intrinsic --- -N- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? -C- --- 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 -Y- --- F08/0042 SOURCE= questions -------------------- F03/0053 No I agree with John that allowing private components in derived types that have the BIND attribute seems absurd. -------------------- F03/0065 Yes While I would not object to adding a note about relational equivalence, I do not think relational equivalence should be allowed to change the results of relational operations. The Fortran standard claims to promote portability and reliability of Fortran programs. Allowing a processor to produce the value false for -2 .LT. 2147483647 does not seem likely to promote portability or reliability. The FORTRAN 66 standard allowed a processor to commute and re-associate the operands of operators when the corresponding mathematical operators were commutative or associative, but that was all it explicitly allowed. The concept of integrity of parentheses made sense in this context. The general notion of mathematical equivalence was introduced in FORTRAN 77. It has been a bane of Fortran programmers ever since. The concept of relational equivalence is specified in Section 6.6.6 of the FORTRAN 77 standard. -------------------- F03/0084 No I disagree with the interpretation given. I believe that the assignments should require conversions to be done and that the conversions should be done in accord with the rounding mode currently in effect. Therefore, the results should not be zero. -------------------- F03/0121 No I previously voted for the answer given. Since then, I have been convinced I was mistaken. I no longer think that REAL(X), where X has type REAL but has a different kind type parameter value from that of type default real, should be considered mathematically equivalent to X. I now agree with Mr. Braams that the intrinsic function REAL should do a real conversion. I agree with Van that nothing in the standard or in the existing interpretations requires VOLATILE to force a conversion. Interpretation F90/000001 is the only interpretation I have found that addresses the issue, and it, of course, could not require the use of VOLATILE. I agree with John that VOLATILE should not be required to force a conversion. -------------------- F08/0004 No I agree with the answer given, but I think the edit as written is likely to confuse readers. Given just the edit without the context of the interpretation, I would be hard put to figure out what it meant. I suggest the following alternative edit: If ASSOCIATED is invoked with two actual arguments and the argument corresponding to TARGET is a pointer, TARGET shall be considered to be a present pointer. -------------------- F08/0008 Yes I agree with the answer given, but I shall note that the conditions given could be tightened. Specifically, the sentence If an IEEE NaN is assigned or returned, the actual arguments were finite numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. could say If an IEEE NaN is assigned or returned, the actual arguments were (possibly infinite) numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. The edits as written are correct, just not as tight as they could be. -------------------- I want to thank John for splitting the ballot. Responding to the shortened ballot gave me enough headaches for this month. Robert Corbett representing Oracle America