RE: i386 floating point expertise needed

> We need someone with i386 floating point knowledge (and I mean, deep down
> low, what every instruction is supposed to do, and how it is supposed to
> be used, including all the surrounding support flags words and whatever)
> to have a look at this, and work out what the problem is.
> I have not been following, but I do know the 386 from years ago.

I used to have such knowledge. Unfortunately, I don't know Unix-style 
386 assembly, having gained that knowledge in the x86 commercial
world; but I don't think that's needed.

The problem is that the 386 does computations with 80-bit numbers, not
64-bit.
The compiler has evidently optimized out a store that would have forced the 
truncation. 

If you don't save the intermediate computations to a double, the spare bits
hang around. 
I did not see the full code sequence posted, but it's clear that although
the two 
64-bit values may be bit identical, the 80-bit intermediate that was used to

compute one of them is not. (I can see that on the stack dump.)  The 16 LSBs
could not be non-zero unless that's a value that was computed and left on
the stack. With the 386, this is an important optimization for performance;
but it can cause exactly this kind of problem.

AMD64 doesn't use 80-bit intermediates, so this issue doesn't arise.

Best regards,
--Terry