Hi,
Thanks for you answer.
I had already patched my readClass.c according to kaffe-1.1.0 to get the
rid of the warning.
What I am wondering now is, what's the difference between those versions?
I mean, is there any chance that the 1.3 class format is /really/
incompatible with kaffe-1.0.7 and th
> Hi folks,
>
> what version of jikes are compatible with kaffe-1.0.7? I am currently
> using 1.18, which leads to (tons of) the aforementioned warning at kaffe
> startup. I also tried 'jikes -target 1.1', but that doesn't help.
> How was 1.0.7's Klasses.jar built in the first place?
Hi...
The wa
In <[EMAIL PROTECTED]> Greg Wooledge wrote:
> I think it depends on the platform; not all platforms have the jit
> or jit3 yet. You can see which one you're using by running
> "java -version" (or "kaffe -version").
it reports on my solaris box using kaffe-cvs:
Engine: Just-in-time Version: 1.0
Hi everyone,
I've started checking in small portions of the verifier for testing. The
first thing this has done is to cause kaffe to fail a regression test,
ArrayForName.java ;) In my defense, it's a bad test because an abstract
method in some class I has a code attribute, which is not OK. In f
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: rob 03/06/29 14:52:48
Modified files:
. : ChangeLog
kaffe/kaffevm : verify.c
Log message:
* kaffe/kaffevm/verify.c
Allow final methods named "" or "this" to be
overridden in subclasses. This mim
Hallo Helmer,
I think that freeing the trampoline in jit3 causes the crash below. I'm also
seeing a crash when I make dist on Linux, that wasn't there before. Could you
take a second look at the new code in kaffe/kaffevm/jit3/machine.c ? Just
deleting the line works again for me.
cheers,
dalibor
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: rob 03/06/29 14:07:02
Modified files:
. : ChangeLog
kaffe/kaffevm : debug.h debug.c verify.c
Log message:
This is the first of a series of small checkins that will
integrate a verifier into kaffe
Hi all,
> > on my box (K6 Linux 2.4.18 Debian/unstable jit3), the
> > following regression tests fail on the latest cvs version of kaffe:
> >
> > FAIL: DoublePrint.java
> > FAIL: ThreadState.java
> > FAIL: InnerTest.java
> > FAIL: finaltest.java
> > FAIL: S
Hi Tony,
--- Tony Wyatt <[EMAIL PROTECTED]> wrote:
> Hi Dalibor,
>
> On 29/06/03, you wrote:
>
>
> > so as long as we are only using the gcc, there's no need for steps 3-6 ;)
> >
> And it's not likely we'll be moving to another compiler real soon ;-)
When I have enough time to merge in the Wi
Hi Dalibor,
On 29/06/03, you wrote:
> so as long as we are only using the gcc, there's no need for steps 3-6 ;)
>
And it's not likely we'll be moving to another compiler real soon ;-)
tony
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/c
Hi Dalibor,
On 29/06/03, you wrote:
> Here's what I believe is the problem with the current test:
> return foo(LONG_MIN, -1l) == 0
>
> The boolean expression is true when LONG_MIN % -1l == 0, i.e. when
> LONG_MIN % -1L works like in the Java spec. It is false ( i.e. zero in C)
> otherwise.
>
>
--- Dalibor Topic <[EMAIL PROTECTED]> wrote:
> Sounds good to me. That's similar to the route I'd like to go for the
> interpreter as well.
>
> 1. make the current special case (#ifdef LONG_MODULO_BROKEN) the only case.
> That should fix powerpc, x86 and m68k.
> 2. remove the according configure
Hi Tony,
thanks for the quick reply!
--- Tony Wyatt <[EMAIL PROTECTED]> wrote:
> Hi Luca and Dalibor,
>
> On 28/06/03, you wrote:
>
> >> The Motorola M68k series and (it would seem) the PowerPC series
> >> processors do not generate an exception, but silently generate the wrong
> >> answer.
> >
13 matches
Mail list logo
