From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Thu Sep  5 05:09:21 2013
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 34818357298; Thu,  5 Sep 2013 05:09:21 +0200 (CEST)
Delivered-To: sc22wg5@open-std.org
Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10])
	by www.open-std.org (Postfix) with ESMTP id EAA70357123
	for <sc22wg5@open-std.org>; Thu,  5 Sep 2013 05:09:04 +0200 (CEST)
Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105])
	(authenticated bits=0)
	by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r85390sl020440
	for <sc22wg5@open-std.org>; Thu, 5 Sep 2013 03:09:02 GMT
	(envelope-from malcolm@nag-j.co.jp)
Message-ID: <67D98F0CFD3644FABB5198BBF75D7C61@Maru6>
From: "Malcolm Cohen" <malcolm@nag-j.co.jp>
To: "WG5" <sc22wg5@open-std.org>
References: <20130905024923.1869835725C@www.open-std.org>
In-Reply-To: <20130905024923.1869835725C@www.open-std.org>
Subject: Re: [ukfortran] (SC22WG5.5085) WG5 ballot N1988
Date: Thu, 5 Sep 2013 12:08:56 +0900
Organization: =?UTF-8?B?5pel5pysTkFH?=
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

>The Fortran 2008 standard places no requirements on division in
>its description of IEEE_SUPPORT_DATATYPE (14.9p1, 14.11.24).
>The proposed edits require a processor to signal IEEE_OVERFLOW
>and IEEE_DIVIDE_BY_ZERO as specified by IEC 60559:1989, even
>though the processor is not required to produce the results
>specified by IEC 60559:1989 for normal operands returning normal
>operands unless IEEE_SUPPORT_DIVIDE is true.  That makes no sense.

This statement is what makes no sense.  IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO 
are not signalled for normal operands returning normal results.

>For example, consider the case of an Intel 386 CPU with a 387
>numeric coprocessor.  A Fortran processor for such a system might
>implement the statement
>
>       X = X/Y
>
>where X and Y are represented in the double-precision format of
>IEC 60559:1989 by extending the values of X and Y to extended
>precision performing the division and converting the result back
>to double-precision.  The resulting division would not always
>produce the result required by IEC 60559:1989.  It would also
>not signal exceptions as required by IEC 60559:1989.

It obviously does signal as required for IEEE_DIVIDE_BY_ZERO.  It also signals 
IEEE_OVERFLOW correctly on assignment to X.

The Fortran standard permits evaluating an expression in a higher precision 
under the rules of mathematical equivalence; that's how we avoided the Java trap 
(which was a performance trap, not an IEEE conformance trap).

I am boggled by the apparent claim that the very chip that the IEEE standard was 
written to describe, the Intel x87, does not conform to the IEEE standard.

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