Tom Tromey wrote: > >>>>> "Chris" == Chris Gray <[EMAIL PROTECTED]> 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.
No. It just means that Float.floatToRawIntBits(Float.NaN) returns 0xffc00000 when you might naively have expected 0x7fc00000. > > 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 > > _______________________________________________ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath