classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Partial Double/Float merge with libgcj


From: Tom Tromey
Subject: Re: Partial Double/Float merge with libgcj
Date: 15 Oct 2001 15:19:21 -0600

>>>>> "Chris" == Chris Gray <address@hidden> writes:

Chris> An interesting twist on this: jikes seems to have its own idea
Chris> of the correct bit-pattern for NaN (0xffc00000 instead of
Chris> 0x7fc0000).  This shouldn't matter if all NaN's are
Chris> canonicalized to the same value.

My understanding is that floatToIntBits is required to return
0x7fc00000 for any NaN, and that Float.NaN must be the same as
Float.intBitsToFloat(0x7fc00000).

This doesn't necessarily imply that there is a Jikes bug though.
It depends on exactly when Jikes uses that particular value.
Float.floatToRawIntBits can return other NaN values, and presumably
the VM could use them as well.  For instace libgcj uses whatever
the underlying hardware decides, and only does the canonicalization
when the real bit pattern might be seen by Java.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]