Alan Eliasen wrote:
Hi Alan,
I am sorry for taking so long to reply, I had some trouble finding time
to dig down, and reproduce the the problem. Thanks a lot for being
persistent about fixing the bug, and providing a very useful patch!
I think that I have a patch for this problem. (See below.) It
appears that all of the steps in Java_java_math_BigInteger_assignLong0
in the file can simply be replaced with a single call to mpz_set_si(res,
v) which sets a GMP integer from a signed long int.
That's correct. On architectures where sizeof(jlong) == sizeof(long),
that's much faster than doing three gmp calls, as the existing method does.
I think that this code should be simpler and faster than the original
code, if a jlong is an unsigned long, but I haven't checked it on all
architectures, only on x86_64 where the problem originally occurred.
For architectures where sizeof(jlong) > sizeof(long) (i.e. platforms
with a 64bit long long), we still need the old algorithm to break the
number in two 32 bit pieces, and shuffle the bits into the gmp number.
There was a bug in the way it was done, though, since the downcasting to
a jint seems to have produced bad results. The updated code now uses a
bitmask to do the masking before the shifting.
This works and passes my regression tests.
Indeed, same for me on x86-64. I've also fixed it on 32bit platforms as
well, and confirmed that your test returns the correct result on x86.
this is a patch to libraries/clib/math/BigInteger.c . Please let me
know if I can produce this patch in a better format, and what I can do
to get this fixed in Kaffe.
I personally find patches in unified diff format to be more readable
(diff -u), but for short patches, anything is fine for me.
You've mentioned further problems on amd64, if you are interested in
tracking them down, I'd be happy to merge further patches in.
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
