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.
----------------------------------------------------------------------