J3/13-246 To: J3 From: Malcolm Cohen Subject: Interp F03/0030 Date: 2013 February 14 1. Introduction Interp F03/0030 failed with 3 NO votes, from Corbett, Reid, and Snyder. The issue raised by Snyder has already been addressed by a separate interp. 2. 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." There is no redefinition or repurposing of IEEE_SUPPORT_DATATYPE, the intent is to define the correct handling of IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO. The definition of these is currently wrong. IEEE_SUPPORT_DATATYPE is merely used to establish whether the operation is relevant to IEEE. 3. 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". See above re IEEE_SUPPORT_DATATYPE. "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." I disagree strongly that the standard should permit a processor to raise IEEE_OVERFLOW on an IEEE arithmetic operation when an operand is infinite, or to raise IEEE_DIVIDE_BY_ZERO when IEC 60559 specifies otherwise. Unless your contention is that a processor should be allowed to never ever raise IEEE_OVERFLOW (viz that the "processor-dependent limit" should be allowed to be infinity), the only effect of these edits is to restrict the processor from raising IEEE_OVERFLOW erroneously (viz when prohibited by IEC 60559). Similarly for IEEE_DIVIDE_BY_ZERO. 4. The revised interp ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS to 10-007r1: [403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW), Replace with "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the operation or conversion, and as determined by the processor otherwise. It occurs in an intrinsic real exponentiation as determined by the processor. It occurs in a complex operation, or conversion by the intrinsic function CMPLX, if it is caused by the calculation of the real or imaginary part of the result." [403:10-11] Clause 14.3, first paragraph, second bullet (IEEE_DIVIDE_BY_ZERO), Replace with "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the division, and as determined by the processor otherwise. It is processor-dependent whether it occurs in a real exponentiation with a negative exponent. It occurs in a complex division if it is caused by the calculation of the real or imaginary part of the result." [462:24+] Clause A.2, after the fifth bullet from the end of the clause "the extent to which a processor supports IEEE arithmetic (14)", Insert new bullet points "- the conditions under which IEEE_OVERFLOW is raised in a calculation involving non-IEC 60559:1989 floating-point data; - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are raised in a floating-point exponentiation operation; - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a calculation involving non-IEC 60559:1989 floating-point data;" SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 F03/0030 submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 10-238r1 m193 Revised answer - Passed J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m196 Failed WG5 ballot 1 N1876 13-nnn m200 Revised. ----------------------------------------------------------------------