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 at 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
>
>
>