[kaffe] Re: Classpath's doubleToLongBits
twisti at complang.tuwien.ac.at
Mon Feb 18 01:45:40 PST 2008
On Mon, 2008-02-18 at 04:03 +0100, Dalibor Topic wrote:
> This one turned out to be a lot more fun to track down.
> It's pretty easy to rewrite the test whether to swap words in a jdouble:
> put -0.0 into a jvalue's
> jdouble element, and if the correspoding jlong bitstream is > 0, you
> have to swap the words.
> It's a way of dynamically doing what the fdlibm #defines do, but it
> works out the same way:
> swap on arm-debian-oabi.
> But that didn't fix the breakage.
> So I played around some more, and eventually, it turned out that kaffe's
> classfile constant parser
> was working fine, and I was reading in doubles the way arm's FPU
> expected them laid out, it
> turned out the interpreter was working ok, too, and so on.
> But the breakage was still there.
> Turning the way, for example, the double constants were parsed around,
> and doing it the 'wrong' way,
> fixed some regression tests, but broke others. Similarly, reassembling
> doubles in the interpreter
> from words the 'wrong' way had the same effect with other tests.
> So I had to examine things a bit more closely with jcf-dump. It turned
> out that, since I was using a
> glibj.zip compiled on an x86-linux host, the constant in the class
> java.lang.Double were laid out
> correctly. But in the tests classes compiled on the arm-oabi-linux
> platform using ecj on gcj-4.3,
> double constants were laid out incorrectly, with their words swapped, as
> a comparison with the
> tests compiled on x86-linux with ecj on gcj showed.
> So, current Kaffe CVS head interpreter works on arm-oabi-linux without
> regressions. The regressions
> Kiyo-san has seen are caused by buggy compilers (jikes / ecj on gcj).
> And I'll move on to comitting the
> jit patches for arm-linux next.
That sounds like it was a lot of work. Did you change anything new in
GNU Classpath or should I test the current CVS version?
More information about the kaffe