Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)
twisti at complang.tuwien.ac.at
Fri Feb 8 00:38:19 PST 2008
On Fri, 2008-02-08 at 00:26 +0100, Dalibor Topic wrote:
> 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
> 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?
That sounds actually very good, if it works on all configurations. I
can remember we had a lot of problems to get these functions right on an
Arm system with VFP. For more problems see also:
More information about the kaffe