From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 26 08:27:29 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 14A043568D9; Fri, 26 Aug 2011 08:27:29 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by www.open-std.org (Postfix) with ESMTP id E3D303568C9 for ; Fri, 26 Aug 2011 08:27:22 +0200 (CEST) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7Q6RHHh013624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Aug 2011 06:27:19 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7Q6RGgk022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 06:27:17 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7Q6RASL007777; Fri, 26 Aug 2011 01:27:11 -0500 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Aug 2011 23:27:10 -0700 Message-ID: <4E573BF2.4060805@oracle.com> Date: Thu, 25 Aug 2011 23:23:46 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: fortran standards email list for J3 CC: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.4518) [ukfortran] interpretation F03/0030 References: <20110824091526.E590E3568C2@www.open-std.org> <20110826033226.196B83568C8@www.open-std.org> In-Reply-To: <20110826033226.196B83568C8@www.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090207.4E573CC7.0215,ss=1,re=3.899,fgs=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk On 08/25/11 20:16, Malcolm Cohen wrote: > BTW, please reply to WG5 (and preferably not to both J3 and WG5 as J3 > is a subset of WG5). > > Robert Corbett claimed: >> The answer and edits provided for F03/0030 are wrong. >> They are wrong in general and in specifics. > > The answer and edits provided for F03/0030 are correct. > > Your claims are wrong. > > They are wrong in general and specifics. > >> Thus, even if IEEE_SUPPORT_DATATYPE is true for a kind >> of real, the intrinsic operations division and >> conversion by the intrinsic function REAL are not >> required to conform to IEC 60559:1989. > > That is correct. > >> Furthermore, >> because the result of an operation that overflows in >> IEEE arithmetic is not a normal number, Fortran 2008 >> does not require IEEE_OVERFLOW to occur for addition, >> subtraction, and multiplication if >> IEEE_SUPPORT_DATATYPE is true (see the text at the >> end of the second item of the list above). > > Actually F2008 as published ***NEVER*** requires IEEE_OVERFLOW to be > raised. That is not an argument in favour of keeping the current > definition! > > With the edits provided, it now requires IEEE_OVERFLOW to be raised > when IEC 60559 so requires. > > I hope we are all agreed that Fortran 2008's definition of > IEEE_OVERFLOW is wrong in the first place! > > The removal of unnecessary processor dependencies by the new > definition is a good thing, not a bad one. > > ASIDE: I don't know how we managed to omit all of those from Annex A - > fortunately the edits insert correct notes here. > >> The intent of the proposed edits might be to extend >> the requirements presented in the first paragraph of >> Clause 14.9. > > The edits do not change the result value of the operation. And the > first paragraph of 14.9 has never been the only requirement on > arithmetic in Fortran! > >> If so, it is done in a manner that is >> certain to confuse readers. > > Apparently at least one. > >> Furthermore, the functions >> IEEE_SUPPORT_DIVIDE and IEEE_SUPPORT_INF will be made >> pointless by such extensions. > > Not so. The edits do not say anything about the result value, they > merely make the operation of IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO > follow the rules of (the now superceded) IEC 60559 for numbers with > IEEE_SUPPORT_DATATYPE true. The previous text required > IEEE_DIVIDE_BY_ZERO to be raised in situations where IEC 60559 forbade > it, and implied (though it did not actually require it with a > sufficiently nitpicky reading) that IEEE_OVERFLOW would be raised in > situations where IEC 60559 forbade it. > > IEEE_SUPPORT_INF did not previously affect the operation of > IEEE_OVERFLOW, and I think that it still does not directly affect the > operation of IEEE_OVERFLOW. > > The previous definition of IEEE_DIVIDE_BY_ZERO was certainly > COMPLETELY UNAFFECTED by IEEE_SUPPORT_DIVIDE. > > The new definition of IEEE_DIVIDE_BY ZERO correctly remains completely > unaffected by IEEE_SUPPORT_DIVIDE, it has merely been corrected not to > be raised in the situations where IEC 60559 forbids it to be raised. > (Actually the new definition greatly weakens the requirements on a > non-IEC 60559 processor, but that is a horse of a different colour.) Your response reads as if you have confused the inquiry function IEEE_SUPPORT_DATATYPE with the inquiry function IEEE_SUPPORT_STANDARD. The function IEEE_SUPPORT_DATATYPE is specified the way it is to allow a user to query if the processor supports the IEEE formats and a small set of operations. It corresponds nicely to the set of features provided by the numeric coprocessors manufactured in the late 1970's and early 1980's. It is possible to extend IEEE_SUPPORT_DATATYPE to mean all that IEEE_SUPPORT_STANDARD means, but I do not think it is desirable. Robert Corbett