This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point trouble with x86's extended precision



On Thursday, August 21, 2003, at 06:42 PM, Jim Wilson wrote:


Bradley Lucier wrote:
I, and other people, think that the inability to get predictable behavior from GCC (even from an option that you might not like to use because of speed or other issues) is a bug.

While I agreee that the current behaviour is a problem, I don't see any good solution for it.

All one needs is a predictable model that matches the hardware. You said yourself, the x86 has only XFMODE registers and operations (rounded, perhaps directionally, to a precision that's set in the control register). If you want to have predictable results, you can't lie about what the hardware's doing. As I said in


http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00466.html

The following computational model will give predictable results and will allow
simulation of IEEE floating point without extended precision as implemented
on other processors (except for things like PowePC fused multiply-add
instruction):


0. The programmer can declare the precision of all operations.

1. All temporaries generated for a single expression are always maintained
in extended precision, even when spilled to the stack, and


2. Each assignment to a variable is stored to memory. (And, if the value of
that variable is used later by dereferencing its lvalue, the value is loaded
from memory and the temporary that was stored to memory is not re-used.)



Item 0 is already implemented in the Linux-Gnu/glibc/gcc/x86 combination.

In fact, 2 is too strong, you need only store to memory non-XFMODE variables. (I think that storing to memory is the only way to get a true conversion, both mantissa and exponent, to either SFMODE or DFMODE from a register in the x86 FP stack.)


That's it. Perhaps Zack's solution with SSE on pentium 4 will work, too, but I don't know enough about it to say.

Brad


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]