To: 		jkr,wg5
From: 		x3j3
Subject:	Exception handling TR liaison report.

X3J3 comments on recent proposals from the Development Body (straw votes are indicated as
parenthetical text):
1)  The module names in the TR have been changed to: IEEE_ARITHMETIC  and
STD_EXCEPTIONS. X3J3 prefers that the names be returned to their prior states (12-0-1).
2)  Compulsory support for halting for "usual".  X3J3 does not agree to this requirement (1-8-
4).
3)  The TR section on intrinsics (15.2)  has been changed so that it is now proposed that the
intrinsics must have some prescribed signal behavior.  The text now reads:

 "If an intrinsic procedure executes normally, the values of the flags
IEEE_OVERFLOW, IEEE_DIVIDE_BY_ZERO, etc. shall be as on entry to the
procedure, even if one or more signals during the calculation. If a result is too
large for the intrinsic to handle, IEEEE_OVERFLOW shall signal. If a
requirement of the standard is not met (for example log(-1.0)), IEEE_INVALID
may signal. These rules also apply to the evaluation of specification expression
on entry to a procedure to format processing, and to an intrinsic operation that
is implemented with software."

 X3J3 would like the TR to require that intrinsics only obey IEEE rules when there is
*some* procedure in the program which has enabled exceptions. So a processor may
well choose to have two intrinsic libraries, one which behaves in some traditional
fashion (e.g. halt on divide by zero, even in an intrinsic) and one which is IEEE
exception sensitive. The latter must be linked in to enable IEEE support. It is hoped
that this can be an automatic consequence of USE IEEE somewhere in the program,
however it is not our intent that this be a requirement. (12-0-2)

 In addition, X3J3 does not agree with the requirement that overflow be signaled. We
believe that it should be processor dependent. What we are requiring is that the
fundamental IEEE functions (+-,/*,sqrt) behave as defined. All Fortran defined
intrinsics are processor dependent. Of course, as a Quality of Implementation issue, an
implementer ought to pay some attention to the spirit of IEEE 754. (12-0-2)

Again from the TR's current text:

 "In a sequence of statements that contains no invocations of
IEEE_GET/SET/etc. if the execution of a process would cause an exception to
signal but after execution of the sequence no value of a variable depends on the
process, whether the exception is signaling is processor dependent. For example,
when Y has the value zero, whether the code x = 1.0/y; x=3.0 signals
ieee_divide_by_zero is processor dependent."

 X3J3 constructed the following example
 If (1.0/x == y) print*,'hello world' ! x=0 ; y=6 both determined at compile time

X3J3 wants the TR to require (in simple terms) "if a computation can be thrown away, it may
be thrown away. Whether it would otherwise signal is processor dependent". (12-0-2)


It should be noted that

I. It has been suggested that there is no need for multiple levels of conformance and that
individual feature tests are needless complexity. X3J3 feels a need for multiple levels of
conformance and individual feature tests. (unanimous)
II. There is at least one supercomputer system that, while otherwise being essentially IEEE
compliant, provides an optional mode of operation which performs division in a non-
IEEE mode (at greater speed).
III. X3J3 notes interpretation #0001. Consider the following example:
 do I = 1, 100
 call hugo(x)
 a=b+c
 end do
 It has been contended that that a=b+c can/will/may be moved before the call. When
IEEE arithmetic is enabled this optimization must be disabled. X3J3 believes that this
program transformation was forbidden by the very first f90 interpretation which has
otherwise been unchallenged. Processors have always been free to make
transformations when the results cannot be observed by the programmer. On an IEEE
processor, it is possible to determine that this sort of transformation has occurred in
more cases. This may surprise some users and implementers. An informative note
explaining this in the rationale would be appreciated. (11-1-1).

IV. The development body has expressed an interest in requiring IEEE base conversion as
part of this TR. X3J3 is against imposing this requirement. (1-12-0)

Typos and questions
Section 2.4 Mixing of IEEE_SUBSET and STD_EXCEPTIONS. (restore old names, so moot)
Section 2.4 employs the term "processor determined" is this different than "processor
dependent" if not, would it be practical to use the older term?
Edits are still missing.

Conclusions:
Recent activity in the Development body has slightly decreased the quality of the draft TR, and
has displaced preparation of the precise EDITS to the Standard. Nonetheless, there is still no
known reason why a complete TR couldn't be ready in time for the Dresden meeting. However,
X3J3 strongly recommends that the development body make the changes listed above and to
stop accepting new input. The Development Body should prepare edits as quickly as possible. It
will be necessary for the entire community to vet the edits carefully. X3J3 sincerely hopes that
a complete draft TR can be circulated no later than 1 June, to allow ample time to review the
document prior to the Dresden meeting.
X3J3 96-107r3
page 2 of 2