Malcolm Cohen wrote:
> Toon Moene wrote:
> >Keith Bierman ADT/QED wrote:
> >> >(and the implementation can do anything it likes) or are IEEE exceptions
> >> There is an IEEE TR, which will be part of F2k.
> >
> [...]
> >
> >I think IEEE conformance as proposed in the TR (and as it is currently
> >in the F2K draft) is simply incompatible with the looseness Fortran
> >treated (floating point) computations earlier on.
>
> I disagree. The IEEE TR has no effect on existing procedures, it only affects
> procedures which call the IEEE routines. Note that there are no "signal
> handlers" so that it is not possible to count the number of exceptions
> (other than zero/more-than-zero) in normal code.
>
> Anyway, one of the major design goals of the TR was to avoid affecting
> existing code. If you have any example where this approach has failed I
> suggest you report it so that it can be fixed!
Well, I thought I had, but now my eye falls on the lines 21/22 of the
first page of Section 15 of the draft:
"If a scoping unit does not access IEEE_EXCEPTIONS or IEEE_ARITHMETIC,
the level of support is processor dependent ..."
So that means that anyone who does this:
FUNCTION FOO(X)
FOO = SQRT(-ABS(X))
END
PROGRAM BAR
USE IEEE_ARITHMETIC
PRINT*, FOO(1.0)
END
is on his own (i.e. he gets the "standard" Fortran answer: Undefined
behaviour).
IOW, even on IEEE comformant *CPUs* the processor doesn't have to
deliver IEEE conformant code 1) in absence of one of the USE's as
specified above. If that's indeed the case, then I retract my words.
1) E.g. it could use a MAC instruction when compiling X = A + B * Y even
if that would result in the "wrong" rounding.
--
Toon Moene ([log in to unmask])
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|