From Keith.Bierman@Eng.Sun.COM Mon May 20 21:04:52 1996 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id VAA17520 for ; Mon, 20 May 1996 21:04:49 +0200 Received: by mercury.Sun.COM (Sun.COM) id MAA07814; Mon, 20 May 1996 12:00:06 -0700 Received: from chiba.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA02771; Mon, 20 May 1996 11:59:56 -0700 Received: from chiba (localhost) by chiba.eng.sun.com (5.x/SMI-SVR4) id AA20061; Mon, 20 May 1996 10:38:12 -0700 Message-Id: <9605201738.AA20061@chiba.eng.sun.com> To: jkr@letterbox.rl.ac.uk (John Reid) Cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1079) New draft exceptions TR In-Reply-To: Your message of "Fri, 10 May 1996 14:38:24 -0000." <199605101359.PAA12389@dkuug.dk> Date: Mon, 20 May 1996 10:38:12 -0700 From: Keith Bierman QED John, what follows is the formal liason report from last week's x3j3 meeting. I'm sure we'll have various private discussions ;> To: jkr,wg5 paper 107r2 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.