Hi,
- a.setRawData((const char*)((int)jb + off), len);
+ a.setRawData((const char*)((long)jb + off), len);
Avoid (long) if you want a chance to make it work on non LP64 64-bit
platforms (e.g. LLP64 from Win64) but I personnally don't care of the
latter.
e.g. uintptr_t or any
Hi,
Here is a quick fix for DoublePrint test failure on 64-bit platforms. The
fdlibm code is not 64-bit clean, so I temporarily switched all occurrences
of 'long' to 'int' to make them 32-bit, as expected. The better fix is to
find out why -_maxwds could be 0 and make mprec.c (lshift) going
Hi,
Dalibor told me you'd know more precisely the status of boehm-gc vs.
kaffe-gc. I am asking because on x86_64 (gcc 4.0-branch, glibc 2.3.5), I
sometimes get failures in the testsuite where all threads are waiting for
something. This is with the default kaffe-gc. What's more, this cannot
be
Hi Dalibor,
Michael Franz wrote:
What is the status of the x86_64 version of Kaffe? I am running SuSE
9.1 on an Athlon 64 and finding that it fails 134 of 144 tests.
I've apparently broken amd64 with this patch
http://www.kaffe.org/cgi-bin/cvsweb/kaffe/kaffe/kaffevm/
Hi,
Fixed make check failures on x86_64-linux
The most important part was to get PROM_f defined correctly, which this
patch doesn't address, hence the bug still remains. ;-)
I have a patch to get rid of PROM_f and use if (PROMOTE_jfloat2jdouble)
to select the right dest member, but that
Hi,
While tracking down my regressions on x86_64, I came accross the
following (unrelated) problem:
Turns out to be related, I realized that when I bothered looking at
Hashtable.java:264 as mentioned in the trace and noticed loadFactor was
a float. ;-)
2004-03-24 Dalibor Topic [EMAIL
On Wed, 7 Jul 2004, Dalibor Topic wrote:
Latest version that fully built and fully regtested was 1.1.4. Looking at
the changes...
Thanks a lot for taking your time to look at them.
Well, I had to reschedule it up to this morning as higher priority items
came in the dichotomy process. ;-)
On Thu, 8 Jul 2004, Gwenole Beauchesne wrote:
Hmm, you use attribute unused, which gcc really interprets it as unused
nowadays, this optimizing out the load, hence the test.
I will commit a 64-bit fix shortly, the guessPointer was truncated
On Thu, 8 Jul 2004, Dalibor Topic wrote:
Where should I look at?
I'd look at replacing the sigcontext stuff (SIGNAL_ARGS,
sigcontextinfo.h etc.) in config/x86_64 with ucontext, that was one
thing I was unsure of, and Guilhem had a different opinion ;)
That's what I did too, after having
On Thu, 8 Jul 2004, Gwenole Beauchesne wrote:
I have now the following problem when running make check, i.e.:
[EMAIL PROTECTED] kaffe.wip]$ $JAVA at.dms.kjc.Main
Note that I could fully rebuildLib @essential.files et al. And the
following failure is happening when invoking the java compiler
Hi,
While tracking down my regressions on x86_64, I came accross the
following (unrelated) problem:
2004-03-24 Dalibor Topic [EMAIL PROTECTED]
* kaffe/kaffevm/support.c,
libraries/clib/net/PlainSocketImpl.c:
Fixed remaining 'foo' is not defined warnings.
which, for this
On Thu, 8 Jul 2004, Dalibor Topic wrote:
Thanks for the fix! Could you take a look if the same patch applied to
unix-pthreads, as well?
Done. However, still with unix-jthreads, I have now the following problem
when running make check, i.e.:
[EMAIL PROTECTED] kaffe.wip]$ $JAVA
Hi,
since I don't have access to x86_64 atm, could you give it a spin?
It's hanging at:
Compiling classes from @essential.files using
/home/gb/cvs/kaffe.wip/kaffe/kaffe/kaffe-bin -ss 500k -mx 256M at.dms.kjc.Main
Latest version that fully built and fully regtested was 1.1.4. Looking at
ported to, and stay working on them.
Kaffe 1.1.4 still works on AMD64, at least with 3.3.2-6mdk. i.e. all
regression tests still pass but our current DateFormatTest problem, which
is not AMD64 related.
Kaffe has been ported to AMD64 by Gwenole Beauchesne from MandrakeSoft,
another Kaffe developer
On Tue, 2 Mar 2004, Dalibor Topic wrote:
Yep, I;m getting that one too. I thought I made some mistake in the
verifier code merge, and went back for quite a while, but the error kept
reoccuring. I think the 'March did it!' assertion is true. Phew, so it
wasn't me after all :)
It occurs
On Wed, 3 Mar 2004, Ito Kazumitsu wrote:
I think this problem has something to do with the time zone that
has daylight saving time which starts from March.
Yes, having user.timezone=CET is enough to trigger the bug. I have checked
gij, and it's affected too. The fact that it worked by default
Hi,
Now that we switched month to March, the DateFormatTest now fails:
[EMAIL PROTECTED] regression]$ $JAVA DateFormatTest
Same time zone
Dates don't match? Tue Mar 02 17:12:12 GMT+01:00 2004 != Tue Mar 02
18:12:12 GMT+01:00 2004
Different time zone
Interestingly, the following independent
On Fri, 20 Feb 2004, Luca Saiu wrote:
The first failed test is TestSerialVersions.
Likewise on Linux/amd64, even on the same build environment where a
successful build of 1.1.2 passed all tests before, and on Linux/ia32.
___
kaffe mailing list
On Sat, 27 Sep 2003, Dalibor Topic wrote:
b) fixing most of the broken platforms to build again with latest gcc
(gcc 3.3.1) ( 1.1.2 was somewhat borked there ;)
What's the problem with 3.3.1? I have been building both x86 and amd64
versions without problem and all tests pass. The only problem
On Sun, 5 Oct 2003, Dalibor Topic wrote:
b) fixing most of the broken platforms to build again with latest gcc
(gcc 3.3.1) ( 1.1.2 was somewhat borked there ;)
I hope to have fixed all of the remaining multi-line string issues
yesterday. Other issues pointed out by the debian buildd logs
On Wed, 17 Sep 2003, nmag only wrote:
I'm very interested in getting kaffe plugin and working on it. Is there
somebody working already on it?
Incidentally, I had a look at it one day last week. Also looked at merging
the mechanics from gcjwebplugin. But I stopped, no time, sorry. There is a
On Thu, 18 Sep 2003, Gwenole Beauchesne wrote:
Incidentally, I had a look at it one day last week. Also looked at merging
the mechanics from gcjwebplugin. But I stopped, no time, sorry. There is a
typo to fix in jni_cpp.h though.
/me is too lagged behind.
2003-08-25 Mark Wielaard [EMAIL
On Thu, 6 Feb 2003, Gwenole Beauchesne wrote:
Oh, thanks for noticing that. However, two things that just hit my head:
1) ia64intrin.h is always available with gcc. I haven't checked icc yet.
2) I probably messed up the non-ia64intrin.h part.
Concerning (1), nope ia64intrin.h and compareswap
On Tue, 4 Jun 2002, Patrick Tullmann wrote:
- * XXX variable declarations in macros are nasty.
+ * Each BEGIN_EXCEPTION_HANDLING macro must be matched by an
+ * END_EXCEPTION_HANDLING macro call in the same scope. Each should
+ * be used only once in a given JNI entrypoint.
+ *
+ * Yes,
Hi,
I've checked out the cvs today, it compiles well with gcc 2.9.x but I can't
compile it with gcc 3.1, this is my error output:
Remove -I/usr/local/include from configure.in. You should not explicitly
add system include dirs to the include search path (-I/usr/include or
On 3 Jun 2002, Carlos Valiente wrote:
Yep, intrp - the only one available for linux-ppc at the moment.
Hadn't EGP wrote a JIT back-end?
http://egp.free.fr/port-kaffe/port-kaffe-0.2.html
Unfortunately, we know what happened, so. :-/
___
kaffe
On Mon, 3 Jun 2002, FAbel wrote:
It works but I had to change configure directly because if I change
configure.in I can't rebuild configure with autoconf, it exits with this
error: configure.in:1237: error: AC_REQUIRE: cannot be used outside of an
m4_defun'd macro
/bin/sh
Hi,
Though they don't fix my problem, that should not hurt.
Index: kaffe/kaffeh/support.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffeh/support.c,v
retrieving revision 1.25
diff -u -r1.25 support.c
--- kaffe/kaffeh/support.c 29
Hi,
With CVS as of today, I get:
gcc-3.0.4 -DHAVE_CONFIG_H -I. -I. -I../../config -I../../include
-I../kaffevm -I./../kaffevm -DKAFFEH -DKVER=1.1.x-cvs
-I/home/gb/cvs/kaffe/./kaffe/kaffevm
-I/home/gb/cvs/kaffe/./kaffe/kaffevm/systems/unix-pthreads
-I../../config -I../../include
Hi,
1) Note that the jthreads implementation won't work on ia64 if compiled
with any gcc 3.0 (tested 3.0.2 and 3.0.4 nowadays).
2) make all; make Klasses work for both implementations (unix-jthreads,
unix-pthreads). However, make test both fail at the same locations.
error compiling:
30 matches
Mail list logo
