This is the mail archive of the
mailing list for the GCC project.
ia32 and IEEE-754 conformance.
- To: gcc at egcs dot cygnus dot com
- Subject: ia32 and IEEE-754 conformance.
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Mon, 19 Jul 1999 22:13:57 +0200
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
Sorry to reopen this thread. The significance of it will be shown
Andy Vaught pointed out to me in private e-mail that my assumption:
>For referential transparency this is sufficient. However, if gcc
>supports IEEE conformance for backends A, B, and C, and only A will
>generate higher precision intermediate results, that would mean that an
>IEEE conformant program could (potentially) generate different results
>on A from those on B and C.
>This is the same question as whether you can use an multiply-add
>instruction that doesn't correctly round down the intermediate result.
>This doesn't sound acceptable to me (from an IEEE-conformance
is incorrect. This becomes clear from Kahan's paper on Java's floating
point arithmetic, which says, loosely speaking that "generating the same
values on different machines should not be a goal of Java's definition
of floating point arithmetic, because it deprives programmers from using
extended precision on hardware that provides it where it can be
In fact, I should have known this, because I read Doug Priest's paper
(in our Readings section) in January, after the previous errr ...
discussion on floating point arithmetic. To quote:
Many programmers may not realize that even a program that uses only the
numeric formats and operations
prescribed by the IEEE standard can compute different results on
different systems. In fact, the authors of the
standard intended to allow different implementations to obtain different
results. Their intent is evident in the
definition of the term destination in the IEEE 754 standard: "A
destination may be either explicitly designated by the
user or implicitly supplied by the system (for example, intermediate
results in subexpressions or arguments for
procedures). Some languages place the results of intermediate
calculations in destinations beyond the user's control.
Nonetheless, this standard defines the result of an operation in terms
of that destination's format and the operands'
values." (IEEE 754-1985, p. 7) In other words, the IEEE standard
requires that each result be rounded correctly to the
precision of the destination into which it will be placed, but the
standard does not require that the precision of that
destination be determined by a user's program. Thus, different systems
may deliver their results to destinations with
different precisions, causing the same program to produce different
results (sometimes dramatically so), even though
those systems all conform to the standard.
Apparently I stored this in wrong term memory :-(
The reason I want to send this to the list is that - as in all
mathematics - changing the axioms means that the whole edifice of
reasoning built on it collapses.
Specifically, I used the argument against "differing results on
differing hardware" to show that 80 bit spills wouldn't be necessary on
the ia32 target. Guess what - that reasoning doesn't apply if it is
IEEE-754 conformant to generate different results on different hardware,
because - if the programmer may assume that use is made of extended
precision intermediate computations - it is desirable to make them
robust against small differences in the compiler that will lead to
different spill regimes in different versions. For this you need 80-bit
Of course, apart from enabling 80-bit spills, you *still* need to work
on the compiler to ensure referential transparency (two uses of the same
value should be the same - 80-bit spills won't give you this
automatically). Doug's paper has a nice example of the need to apply
that principle to common subexpressions (the log1p function) as well.
Hope this is clear - and sorry to have led you astray.
[ I simply do not have the right mindset to reason about IEEE-754
conformance, I'm afraid. ]
Toon Moene (firstname.lastname@example.org)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html