Floating point trouble with x86's extended precision

[Bradley Lucier]

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