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
> 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?
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800
- twisti