Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

imcc 0.0.9 runs 100% perl6 tests + various results

4 views
Skip to first unread message

Leopold Toetsch

unread,
Sep 10, 2002, 8:12:25 AM9/10/02
to Sean O'Rourke, Melvin Smith, Angel Faus, P6I
"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.

$ perl6 --test # run through assembler / parrot
All tests successful, 2 subtests skipped.
Files=17, Tests=72, 1 wallclock secs ( 0.16 cusr + 0.04 csys = 0.20 CPU)

real 1m5.575s
user 1m2.100s
sys 0m3.300s

8_5 fails. Here is a trace diff to correct one running per imcc:

PC=462; OP=656 (save_p); ARGS=(P1)
PC=464; OP=672 (restoreall)
PC=465; OP=741 (ret)
-Wrong type on top of stack!
-Error: '/home/lt/src/parrot-leo/parrot -t t/compiler/8_5.pbc ' failed
with exit
+PC=4; OP=0 (end)

$ time perl6 --test -r # run tests per imcc
All tests successful, 2 subtests skipped.
Files=17, Tests=72, 0 wallclock secs ( 0.11 cusr + 0.07 csys = 0.18 CPU)

real 0m29.766s
user 0m28.640s
sys 0m0.850s

All is here really all. And in less then half of the time (albeit imcc
did - according to the trace diff - execute one op more then parrot ;-)


With GC turned on, some longer running tests fail:

Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/compiler/1.te 12 1 8,33% 11
t/compiler/8.te 6 1 16,67% 5
t/compiler/qsor 1 1 100,00% 1
t/rx/call.test 2 1 50,00% 2
2 subtests skipped.
Failed 4/17 test scripts, 76.47% okay. 4/72 subtests failed, 94.44%
okay.


$ time perl6 --test -r -Rj # run JIT
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/builtins/arra 3 1 33,33% 2
t/compiler/3.te 7 1 14,29% 7
t/compiler/8.te 6 1 16,67% 6
t/compiler/9.te 4 1 25,00% 2
t/compiler/b.te 2 1 50,00% 2
2 subtests skipped.
Failed 5/17 test scripts, 70.59% okay. 5/72 subtests failed, 93.06% okay.

real 0m29.045s

$ time perl6 --test -r -Rb # with bounds checking and slow_core
All tests successful, 2 subtests skipped.

real 0m30.221s

and finally, for people, who know, how predereferencing works:

$ perl6 --test -RP
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/builtins/arra 3 1 33,33% 2
t/builtins/stri 4 4 100,00% 1-4
t/compiler/1.te 12 12 100,00% 1-12
t/compiler/2.te 5 5 100,00% 1-5
t/compiler/3.te 7 7 100,00% 1-7
t/compiler/4.te 3 3 100,00% 1-3
t/compiler/5.te 5 5 100,00% 1-5
t/compiler/6.te 6 6 100,00% 1-6
t/compiler/7.te 1 1 100,00% 1
t/compiler/8.te 6 6 100,00% 1-6
t/compiler/9.te 4 4 100,00% 1-4
t/compiler/a.te 3 3 100,00% 1-3
t/compiler/b.te 2 2 100,00% 1-2
t/compiler/qsor 1 1 100,00% 1
t/rx/basic.test 6 6 100,00% 1-6
t/rx/call.test 2 2 100,00% 1-2
t/rx/special.te 2 2 100,00% 1-2
2 subtests skipped.
Failed 17/17 test scripts, 0.00% okay. 70/72 subtests failed, 2.78% okay.

All results on a 800Mhz Athlon i386-linux, verified on a second one.

leo

Melvin Smith

unread,
Sep 11, 2002, 7:31:29 PM9/11/02
to Leopold Toetsch, Sean O'Rourke, Angel Faus, P6I
At 02:12 PM 9/10/2002 +0200, Leopold Toetsch wrote:
>"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
>(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.

Does this include the patch you sent me? I was unable to apply it
so it sort of sat in my queue.

-Melvin

Dan Sugalski

unread,
Sep 13, 2002, 6:59:03 AM9/13/02
to Leopold Toetsch, Sean O'Rourke, Melvin Smith, Angel Faus, P6I
At 2:12 PM +0200 9/10/02, Leopold Toetsch wrote:
>"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
>(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.

Do we have any idea why GC's getting in the way here? I presume we
have GC bug, so we ought to track it down if we can.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Leopold Toetsch

unread,
Sep 13, 2002, 8:52:41 AM9/13/02
to Dan Sugalski, Sean O'Rourke, P6I
Dan Sugalski wrote:

First I want to thank you, for all the checkins.
(Please don't forget #17143, which makes predereferencing working)


> Do we have any idea why GC's getting in the way here? I presume we have
> GC bug, so we ought to track it down if we can.


I can only bring some hints:

- test failures are not the same, when run through parrot or imcc

- imcc uses a global interpreter variable, whereas parrot's is on stack.

- parrot fails currently only one test: t/compiler/8_5

turnning gc off and tracing both brings this diff:

PC=462; OP=656 (save_p); ARGS=(P1)
PC=464; OP=672 (restoreall)
PC=465; OP=741 (ret)
-Wrong type on top of stack!

e.g. the last instruction of main fails, failure looks like stack
corruption.

- imcc with GC turned off passes all tests
- imcc with GC on fails these:

Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/compiler/1.te 12 1 8,33% 11
t/compiler/8.te 6 1 16,67% 5
t/compiler/qsor 1 1 100,00% 1

t/rx/call.test 2 2 100,00% 1-2
2 subtests skipped.

1_11:
=====
-1003.100000PC=859; OP=26 (print_sc); ARGS=("\n")
-
-PC=861; OP=636 (popp)
+1003.100000PC=859; OP=26 (print_sc); ARGS=("^C")
+^CPC=861; OP=636 (popp)

i.e. (1 byte) corruption in the constant table
-d shows 22 collect runs, 3 DOD

8_5:
====
same as parrot (stack) (# of DOD unavailable, it dies)

qsort_1
=======
prints garbage numbers, 3 DOD runs, 0 collect
probably stack corruption, qsort is recursive.

t/rc/call_1
===========
constant table corruption:
PC=334; OP=93 (set_p_s); ARGS=(P0, S1="sdf")
-PC=337; OP=138 (set_p_kc_p); ARGS=(P2, ["thing"], P0)
+PC=337; OP=138 (set_p_kc_p); ARGS=(P2, ["`=^\0"], P0)
(2 DOD, 2 collect)

t/rc/call_2
===========
constant table corruption:
PC=260; OP=93 (set_p_s); ARGS=(P0, S1="22")
-PC=263; OP=138 (set_p_kc_p); ARGS=(P5, ["two_of"], P0)
+PC=263; OP=138 (set_p_kc_p); ARGS=(P5, ["ì>^\0\0"], P0)
(10 DOD, 4 collect)

Some more:

==========

perl6 examples/life.p6 10
- 10 gens of life, ok with parrot

perl6 -r -Rd examples/life.p6 10
- 10 gens of life, with imcc, runs very (~13 sec) long:
*** Parrot VM: Dumping GC info ***
Total memory allocated: 352256
Total DOD runs: 1118
Total collector runs: 19
Active PMCs: 17
Active buffers: 29
Total PMCs: 256
Total buffers: 88064
Since last collection:
Header allocations: 0
Memory allocations: 0
and prints garbage.
Actually the amount of DOD runs is way to high

perl6 -r -RG examples/life.p6 10
GC off, with imcc, runs 3 seconds, result ok

$ time perl6 -vw examples/mandel.p6
P6C 'examples/mandel.p6'
Parse error [line 28]: Invalid statement near "my @b = (" ", ...
(currently br0ken ;-)

So far, what I have.
What could I do, to help track GC bugs? down?

leo

Peter Gibbs

unread,
Sep 13, 2002, 10:27:11 AM9/13/02
to Leopold Toetsch, Sean O'Rourke, Melvin Smith, Angel Faus, P6I, Dan Sugalski
Dan Sugalski wrote:
> At 2:12 PM +0200 9/10/02, Leopold Toetsch wrote:
> >"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
> >(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.
>
> Do we have any idea why GC's getting in the way here? I presume we
> have GC bug, so we ought to track it down if we can.

At least one of the problems is a bug in continuation.pmc - see patch
below. I would assume at least coroutine may have the same problem,
I haven't checked yet.

--
Peter Gibbs
EmKel Systems

Index: classes/continuation.pmc
===================================================================
RCS file: /cvs/public/parrot/classes/continuation.pmc,v
retrieving revision 1.1
diff -u -r1.1 continuation.pmc
--- classes/continuation.pmc 4 Aug 2002 22:55:03 -0000 1.1
+++ classes/continuation.pmc 13 Sep 2002 14:21:53 -0000
@@ -33,10 +33,15 @@
}

PMC* mark (PMC* end_of_used_list) {
- return mark_stack(
+ end_of_used_list = mark_stack(
((struct Parrot_Continuation *)SELF->data)->ctx.user_stack,
end_of_used_list
);
+ end_of_used_list = mark_stack(
+ ((struct Parrot_Continuation *)SELF->data)->ctx.control_stack,
+ end_of_used_list
+ );
+ return end_of_used_list;
}

INTVAL type () {


Andy Dougherty

unread,
Sep 13, 2002, 11:36:35 AM9/13/02
to P6I
On Fri, 13 Sep 2002, Leopold Toetsch wrote:

> > Do we have any idea why GC's getting in the way here? I presume we have
> > GC bug, so we ought to track it down if we can.

Any chance of including the pre-generated bison and lex output? (I posted
a patch to do this a couple of weeks ago.) It'd make it easier to test
more widely.

--
Andy Dougherty doug...@lafayette.edu

Leopold Toetsch

unread,
Sep 13, 2002, 11:18:33 AM9/13/02
to Peter Gibbs, Sean O'Rourke, Melvin Smith, Angel Faus, P6I, Dan Sugalski
Peter Gibbs wrote:


> At least one of the problems is a bug in continuation.pmc - see patch
> below. I would assume at least coroutine may have the same problem,
> I haven't checked yet.


Thanks, applied, tested, not too bad:

one error 8_5.p6 (using try/CATCH aka continuation) does now work with
parrot:


$ perl6 t/compiler/8_5.p6 # parrot
about to die
caught eek
eek: still alive
eek, eh?

$ perl6 -r t/compiler/8_5.p6 # imcc error in last line
about to die
caught eek
eek: still alive
, eh?

$ perl6 -r -RG t/compiler/8_5.p6 # imcc GC off
about to die
caught eek
eek: still alive
eek, eh?

Thanks,
leo

Leopold Toetsch

unread,
Sep 13, 2002, 12:01:15 PM9/13/02
to Andy Dougherty, P6I
Andy Dougherty wrote:


> Any chance of including the pre-generated bison and lex output? (I posted
> a patch to do this a couple of weeks ago.) It'd make it easier to test
> more widely.

When my patch gets in, I'll include both. I'm currently waiting for some
basic functionality in parrot to catch up with my tree. When this is in,
I'll look how to get my ~250 KB imcc patch into CVS.

leo

Leopold Toetsch

unread,
Sep 14, 2002, 8:10:43 AM9/14/02
to Peter Gibbs, Sean O'Rourke, Melvin Smith, Angel Faus, P6I, Dan Sugalski
Peter Gibbs wrote:

> Dan Sugalski wrote:

>>Do we have any idea why GC's getting in the way here? I presume we
>>have GC bug, so we ought to track it down if we can.
>>

> At least one of the problems is a bug in continuation.pmc - see patch
> below. I would assume at least coroutine may have the same problem,
> I haven't checked yet.

I did find the GC big in imcc. It was my fault, I didn't set
BUFFER_constant_FLAG on strings, I put into the const_table.

Attached is a patch for debug.c (where I took this erroneous piece of
code from).

So with the patch for continuation.pmc both parrot and imcc run 100%
perl6 tests now.

Please apply Peter's patch.

Thanks for your patience,
leo

debug.patch

Dan Sugalski

unread,
Sep 14, 2002, 9:09:46 AM9/14/02
to Peter Gibbs, Leopold Toetsch, Sean O'Rourke, Melvin Smith, Angel Faus, P6I
At 4:27 PM +0200 9/13/02, Peter Gibbs wrote:
>Dan Sugalski wrote:
>> At 2:12 PM +0200 9/10/02, Leopold Toetsch wrote:
>> >"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
>> >(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.
>>
>> Do we have any idea why GC's getting in the way here? I presume we
>> have GC bug, so we ought to track it down if we can.
>
>At least one of the problems is a bug in continuation.pmc - see patch
>below. I would assume at least coroutine may have the same problem,
>I haven't checked yet.

applied, thanks.

Dan Sugalski

unread,
Sep 14, 2002, 9:11:24 AM9/14/02
to Leopold Toetsch, Peter Gibbs, Sean O'Rourke, Melvin Smith, Angel Faus, P6I

Peter's patch is in, as is this. Thanks.

0 new messages