(j3.2006) (SC22WG5.4518) [ukfortran] interpretation F03/0030

[Malcolm Cohen]

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

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.