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
