Re: IEEE arithmetic handling

eggert@twinsun.com (Paul Eggert) writes:


      The IEEE floating point standard recommends that the user be able to
      request a trap whenever operations like .LT. are applied to NaNs, so
      for operations like .LT., Breuel's ``alternative approach'' should
      simply be a matter of enabling a trap handler. However, .EQ. and .NE.
      never trap, so (contra Breuel) Cownie's example still works even if
      traps are enabled. See IEEE Std 754-1985, page 13, table 4.


I didn't say that they did trap. I said that I think it's a bad idea for a
language standard to make any guarantees about how the built-in operators
work with IEEE NaN's. I believe that built-in operators should have no
defined behavior for any IEEE-specific features, not after "enabling a
trap handler" nor in any other case. If you define such behavior, programs
written with IEEE semantics in mind will not be forced to clearly document
where they rely on IEEE-specific properties, and they will be very
difficult to port to non-IEEE machines.


The situation is analogous to the many unportable assumptions about
pointers and representations made in C programs: those assumptions are
true on many machines ("32bit workstations") but not all. They make
porting C programs to "unusual" architectures a major headache, since
there is no simple way to identify all the places in which such
assumptions are being made.


Fortunately, whether or not to adopt specific aspects of the IEEE floating
point standard is up to the individual language standards and can't be
mandated by the IEEE floating point standard. So, a C implementation that
chooses to optimize away "x != x" for "double x;" is still within the
current C standard, although it may not be truly "IEEE conforming" (I
believe the same is true for FORTRAN).


I would regret if my compiler gave up opportunities for optimization to
cater to some IEEE specific properties of operators like "!=", but I
suspect the overhead isn't all that large for workstation-class machines.
Ultimate, it is you yourself who pays the price when you use unportable
tricks like "x != x" instead of using self-documenting, clear interfaces
to implementation dependent floating point properties.


Thomas.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.