[Vm-dev] Re: [squeak-dev] Re: [4.2] tests status

[David T. Lewis]

On Sun, Dec 26, 2010 at 08:16:22AM +0100, Andreas Raab wrote:
> On 12/24/2010 9:35 PM, David T. Lewis wrote:
> >On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote:
> >>Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800
> >>>I think too, that it would be good to coordinate with Matthew F.
> >>>To be sure the Croquet stuff is operational in 4.2.
> >>
> >>Yes, this was actually mentioned in the last meeting report -
> >>
> >>http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december-
> >>21-2010/
> >>
> >>If I understood correctly, he will continue to track Trunk and doesn't
> >>feel that an incomplete merge in 4.2 will be a problem. He did mention
> >>the "FloatMath plugin issue" and that it would be good to have that
> >>solved in 4.2, but I have not been paying attention to this discussion.
> >
> >I think that the "FloatMath plugin issue" is Mantis 0007583: Float does
> >not use FloatMathPlugin for bit-consistent float math across platforms.
> >
> >   http://bugs.squeak.org/view.php?id=7583
> 
> I went ahead and pushed the changes. They do look reasonable to me but 
> please everyone give it a shot and run all the float tests to ensure it 
> works on your favorite platform as well. In short, if all the tests in 
> KernelTests-Numbers pass, we're good, if any fail, please report back 
> with details.
> 
> Cheers,
>   - Andreas

(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