Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)

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

 



Dalibor Topic wrote:
Dalibor Topic wrote:

My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe.

Any volunteers for the arm-* interpreter failures?
3 failures on OABI, 5 on EABI, btw.

I've looked a bit closer at the 3 ARM OABI errors, in particular at the
errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fefffffffffffff we get 0xffffffff7fefffff.

The current GNU Classpath implementation of Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, whenever __ARMEL__ is defined. That makes the DoubleConst test fail for Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of time trying to get it right on his ARM systems, I didn't want to mess with the corresponding file in fdlibm.

So I wrote another implementation of the function, using ieee754.h (part of glibc). Basically, it boils down to shifting the bits from the bitfields to the right places inside the jlong. Easy.

Unfortunately, that didn't work on arm OABI debian sid either. It turned out that glibc has a bug in the iee754.h header file, that comes to bite one on arm OABI. Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch attached.

Meanwhile, that still means that those 3 tests fail until glibc is fixed. So ... I'll send in a couple of patches to the classpath patches list to first rewrite the doubleToLongBits in Java (and the same for Float), removing it from the VM interface, and then, I'll send in a patch to add the ieee754.h way of dealing with fetching the bits to the current way.

Does that sound useful?

cheers,
dalibor topic


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux