This is the mail archive of the
mailing list for the GCC project.
Re: Floating point trouble with x86's extended precision
- From: dewar at gnat dot com (Robert Dewar)
- To: dewar at gnat dot com, lucier at math dot purdue dot edu,reichelt at igpm dot rwth-aachen dot de
- Cc: gcc at gcc dot gnu dot org, wilson at tuliptree dot org
- Date: Fri, 22 Aug 2003 21:47:50 -0400 (EDT)
- Subject: Re: Floating point trouble with x86's extended precision
Just to add to my previous message. I don't think anyone would argue
against having a code generation option that would guarantee repeatable
I am pretty sure it has to be an option, since the expense of doing things
this way by default is high (we have seen that in the Java context). Indeed
during the Ada standards development, we specifically recognized the issue
of random extra precision, and the Ada fpt model permits this behavior.
For example in Ada, if you say
A := B + C;
D := A + F;
it is not required to reduce the precision of A by storing it.
I certainly agree that it is useful to have an option to make the
behavior predictable, but in practice it may be too inefficient to
be used very much.
Pragmaticaly, the best approach is often to use 64-bit mode, and always
use 64-bit floating-point for all operations.