I fail to see how modf() could possibly be inexact, it just has to cut the mantissa in two parts... Therefore, primitive 52 should lead to bit identical results across platforms. The only thing to change in order to be FloatMathPlugin compatible would be to fail the primitive for a nan receiver.
The fdlibm do define a replacement __ieee754_modf() because it has to (it is a replacement of libm and cannot use default libm). Maybe we don't have to use it, and can safely revert to modf().
Nicolas
2010/12/29 David T. Lewis lewis@mail.msen.com:
(cc to vm-dev list)
I have found an additional issue with the FloatMath updates. When running on a VM compiled for 64 bits, an updated trunk image hangs up with no input event processing and no display updates.
This is on a Linux VM compiled with no optimization (CFLAGS='-g -m64 -O0).
The problem is related to Float>>fractionPart. If this method is reverted to the prior version, or if the FloatMathPlugin is not present, the image no longer hangs.
The primitive in question is FloatMathPlugin>>primitiveFractionalPart which presumably has a bug related to pointer size. The bug is exposed by compiling with 64 bit pointers, and the updated trunk image will hang up if the primitive is being called by Float>>fractionPart.
The FloatMathPlugin>>primitiveFractionalPart method looks fine (variables all declared correctly). The error occurs within the __ieee754_modf(rcvr, &trunc) function call, which produces completely bogus results when compiled -m64. This function is implemented as modf() in fdlibm. A stand-alone C test program confirms that the bug is in the library function itself.
Presumably this bug would affect Mac VMs compiled for 64-bits, and I think there are a number of these in circulation (though I do not know if they include the FloatMathPlugin).
Dave