[perl #132328] [SEGV][REGRESSION] DBIish tests are failing spectacularly (JIT compilation of native calls)

Honestly, I have no idea how to test this… maybe someone should attempt to golf it, but given that the commit description is “JIT compile native calls”, I guess it'd be a bit complicated. … I'm fine with just delegating it to the DBIish test suite… On 2017-10-20 08:12:41, alex.jakime

[perl #132328] [SEGV][REGRESSION] DBIish tests are failing spectacularly (JIT compilation of native calls)

Offending commit reverted in https://github.com/MoarVM/MoarVM/commit/1a9be0ad487bc6e2d21df54c6a12892e3f9c8259 I tested it with moar HEAD and indeed the issue is no longer there. So it should work fine after moar and nqp bumps. ｢testneeded｣ ? On 2017-10-20 07:53:23, alex.jakime...@gmail.com

[perl #132328] [SEGV][REGRESSION] DBIish tests are failing spectacularly (JIT compilation of native calls)

Moar bisected to https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1 On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote: > DBIish tests started to fail (with segv) after this rakudo commit: >

[perl #132328] [SEGV][REGRESSION] DBIish tests are failing spectacularly (JIT compilation of native calls)

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132328] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132328 > DBIish tests started to fail (with segv) after this rakudo commit:

[perl #132269] [REGRESSION][BUG] JIT removing loop construct and confusing last()

Alright, so this was fixed, or at least Committable is sure that it was: https://gist.github.com/Whateverable/569f4cd48eb7e12e50922035d0d4d94e According to brrt the fix is in this moarvm commit: https://github.com/MoarVM/MoarVM/commit/bedc8511387af00ea3b71d07770e9e7eb2c0e279 I guess we need

[perl #132269] [BUG] JIT removing loop construct and confusing last()

# New Ticket Created by ugexe # Please include the string: [perl #132269] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132269 > Discovered by failing tests in Net::HTTP xt/* on rakudo/nqp/moar master, the following output

Re: [perl #131815] `zef search` fails after installing `rakudo-star-2017.07-x86_64 (JIT).msi` on Windows 10 Home x64

I can't reproduce on Windows 10 Professional. Was there a previous Rakudo Star install present? You could try cd %USERPROFILE% rd /s .zef rs /s .perl6 and rerunning. S On 29 July 2017 at 18:08, Richard Loveland wrote: > # New Ticket Created by Richard

Re: [perl #131815] `zef search` fails after installing `rakudo-star-2017.07-x86_64 (JIT).msi` on Windows 10 Home x64

I can't reproduce on Windows 10 Professional. Was there a previous Rakudo Star install present? You could try cd %USERPROFILE% rd /s .zef rs /s .perl6 and rerunning. S On 29 July 2017 at 18:08, Richard Loveland wrote: > # New Ticket Created by Richard

[perl #131815] `zef search` fails after installing `rakudo-star-2017.07-x86_64 (JIT).msi` on Windows 10 Home x64

# New Ticket Created by Richard Loveland # Please include the string: [perl #131815] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131815 > $ zef search doc No such method 'subst' for invocant of type 'Any' in method ver

Re: JIT?

On 01/13/2017 05:18 AM, Steve Mynott wrote: The most important difference is that the JIT version is 64 bit and the "no JIT" is 32 bit. So if you are running a modern Windows you almost certainly want the 64 bit (JIT) version Also the JIT version is a more recent version. S

Re: JIT?

The most important difference is that the JIT version is 64 bit and the "no JIT" is 32 bit. So if you are running a modern Windows you almost certainly want the 64 bit (JIT) version Also the JIT version is a more recent version. S

Re: JIT?

On 01/11/2017 06:43 PM, yary wrote: You don't need JIT! It's an implementation detail that doesn't affect functionality. In theory it improves speed at which Perl6 code runs. In practice, it won't make a bit of difference with FTP

Re: JIT?

You don't need JIT! It's an implementation detail that doesn't affect functionality. In theory it improves speed at which Perl6 code runs. In practice, it won't make a bit of difference with FTP client/server programs.

JIT?

Hi All, I was looking for downloading Perl 6 for windows from http://rakudo.org/downloads/star/ rakudo-star-2016.11-x86_64 (JIT).msi rakudo-star-2016.01-x86 (no JIT).msi Supposedly JIT is "Runtime optimization of hot code paths during execution" Don't have a clue what that is.

[perl #128144] [OSX] JIT disabled/broken

This has been fixed in MoarVM (commits b4d1dc653e and 987923343c). MoarMV and NQP versions were bumped and Rakudo builds again on platforms using clang. I'm closing this ticket as 'resolved'.

[perl #128144] JIT broken on OS X

# New Ticket Created by Will Coleda # Please include the string: [perl #128144] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128144 > Recent changes in MoarVM have forced us to disable JIT on OS X. This needs to be

[perl6/specs] 20a1fd: resolve link for JIT compiler

paths: M S99-glossary.pod Log Message: --- resolve link for JIT compiler

[perl6/specs] 1a7b77: elaborate JIT

paths: M S99-glossary.pod Log Message: --- elaborate JIT

Re: [perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t

James Keenan via RT schrieb: On Sat Aug 02 05:06:31 2008, rurban wrote: On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote: Can anyone on FreeBSD give us an update on this issue? freebsd7, recent parrot svn (r29922) passes the t/op/trans.t tests Thanks for looking into this, Reini. Now,

[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t

On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote: Can anyone on FreeBSD give us an update on this issue? freebsd7, recent parrot svn (r29922) passes the t/op/trans.t tests Determining JIT capability.yes It even works with freebsd's make, not only

[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t

On Sat Aug 02 05:06:31 2008, rurban wrote: On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote: Can anyone on FreeBSD give us an update on this issue? freebsd7, recent parrot svn (r29922) passes the t/op/trans.t tests Thanks for looking into this, Reini. Now, would these failures

[perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared

On Fri Jul 11 14:00:12 2008, cotto wrote: On Fri Jul 11 05:29:20 2008, coke wrote: Belatedly add Moritz's response to the ticket. A fix for this bug was committed in r29289 which looks like it will resolve this issue. If that's the case, this ticket can be closed. Since there haven't

[perl #44811] Abort in t/op/string.t 91 with JIT on x86

This problem is fixed by other similar problem whose ticket was not linked to this. r29358 unskip the test. Closing ticket.

src/jit/i386/core.jit:1031: error: ‘DO’ undeclared

/exec_cpu.c src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec': src/jit/i386/core.jit:1031: error: 'DO' undeclared (first use in this function) src/jit/i386/core.jit:1031: error: (Each undeclared identifier is reported only once src/jit/i386/core.jit:1031: error: for each function it appears in.) src

Re: src/jit/i386/core.jit:1031: error: 'DO' undeclared

-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DHAS_GETTEXT -g -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c xx.c src/exec_cpu.c src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec': src/jit

[perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared

[EMAIL PROTECTED] Date: July 11, 2008 5:33:03 EDT To: [EMAIL PROTECTED] Subject: src/jit/i386/core.jit:1031: error: ?DO? undeclared Hi, I am using Fedora 8 Linux 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux gcc version 4.1.2 20070925 (Red Hat 4.1.2-33

Re: [perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared

src/exec_cpu.c src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec': src/jit/i386/core.jit:1031: error: 'DO' undeclared (first use in this function) Looks like it was just a DO/do typo, but the file has been changed before I can try to do some test. -- Salu2

Re: [perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared

Looks like it was just a DO/do typo, but the file has been changed before I can try to do some test. No, it was a bad diagnostic from svn, my change has been commited. -- Salu2

[perl #56832] # src/jit/i386/core.jit:1031: error: 'DO' undeclared

Belatedly add Moritz's response to the ticket. -- Will Coke Coleda -- Forwarded message -- From: Moritz Lenz [EMAIL PROTECTED] Date: Fri, Jul 11, 2008 at 6:00 AM Subject: Re: src/jit/i386/core.jit:1031: error: 'DO' undeclared To: tuxdna [EMAIL PROTECTED], Perl 6 Internals [EMAIL

[perl #56824] [PATCH] Configure - fix SEGV in JIT has_exec_protect test on Cygwin

# New Ticket Created by Donald Hunter # Please include the string: [perl #56824] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56824 Fixes a segv in the has_exec_protect test on Cygwin. config/auto/jit

[perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared

On Fri Jul 11 05:29:20 2008, coke wrote: Belatedly add Moritz's response to the ticket. A fix for this bug was committed in r29289 which looks like it will resolve this issue. If that's the case, this ticket can be closed.

[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t

Can anyone on FreeBSD give us an update on this issue? Thank you very much. kid51

Re: [perl #43245] t/op/bitwise.t #27 Fails with JIT

On Thursday 05 June 2008 20:38:58 Will Coleda via RT wrote: t/op/bitwise.t1 256271 27 Failed 1/1 test scripts. 1/27 subtests failed. Files=1, Tests=27, 1 wallclock secs ( 0.28 cusr + 0.20 csys = 0.48 CPU) Failed 1/1 test programs. 1/27 subtests failed. chromatic, is

[perl #43245] t/op/bitwise.t #27 Fails with JIT

On Mon Jun 18 15:13:15 2007, [EMAIL PROTECTED] wrote: r19067 needs a bit more work (pardon the pun) to work with parrot -j. Bob, do you have an idea on what the fix might be? If it's not a quick one, we can mark this test as TODO for JIT before the release tomorrow. $ TEST_PROG_ARGS=-j

[perl #40200] t/pmc/threads.t test 16 fails under JIT (parrot -j)

On Sat Aug 19 08:02:06 2006, leo wrote: Am Samstag, 19. August 2006 06:11 schrieb Chip Salzenberg: After the STM merge, all of t/pmc/threads.t succeeds (woggle++). But one of the tests fails under JIT.  I'm hoping that somebody will recognize the reason quickly, else I'll have to dive

[perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

I believe I've fixed the problem in r27999.

[perl #55134] [CAGE] [PATCH] Clean warning in i386 jit

# New Ticket Created by NotFound # Please include the string: [perl #55134] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55134 The attached patch cleans warnings in i386 jit related parts, both compiling with gcc

Re: [perl #55134] [CAGE] [PATCH] Clean warning in i386 jit

On Saturday 31 May 2008 10:55:15 NotFound wrote: The attached patch cleans warnings in i386 jit related parts, both compiling with gcc or with g++. Excellent! Applied as r27990. -- c

Re: [perl #45503] one test in 't/op/string.t' is failling for jit runcore

. But the perldoc item was, and still is: A string is true if it is equal to anything other than C0, C or C0. Implying that 0, that is, NULL, is acceptable. Regarding 27069, the problem here is not the same, the JIT compiler can not verify the signature, and thus can't give any warning. -- Salu2

Re: [perl #45503] [BUG] one test in 't/op/string.t' is failling for jit runcore

My text editor mangled a unicode mark at the start of the CREDITS file. Here is a corrected version of the patch. -- Salu2 Index: src/ops/core.ops === --- src/ops/core.ops (revisión: 27474) +++ src/ops/core.ops (copia de trabajo)

Re: [perl #45503] one test in 't/op/string.t' is failling for jit runcore

On Tue, Sep 18, 2007 at 6:59 PM, via RT Nuno Carvalho [EMAIL PROTECTED] wrote: While running 'make fulltest', for today's release, we noticed there is a test failling for 't/op/string.t' when using jit runcore. This test is currently being skipped. The test that's failling is test

[perl #45503] [BUG] one test in 't/op/string.t' is failling for jit runcore

I forgot to Cc: the list. Also, I've taken this ticket and will apply NotFound's patch in a day or so if we don't hear objections. Pm On Mon May 12 10:08:19 2008, pmichaud wrote: On Mon May 12 09:23:49 2008, [EMAIL PROTECTED] wrote: The easier solution is to redefine string_bool to allow a

Re: [perl #45503] one test in 't/op/string.t' is failling for jit runcore

On Monday 12 May 2008 09:23:18 NotFound wrote: The problem is that the opcode checks for nullness before calling string_bool: op if (invar STR, labelconst INT) { if ($1 string_bool(interp, $1)) goto OFFSET($2); } And the jitted code apparently calls string_bool

Re: [perl #45503] [BUG] one test in 't/op/string.t' is failling for jit runcore

Here is the patch. It changes the string_bool function an his declaration, and deletes the check for null before calling it in several places. -- Salu2 Index: src/ops/core.ops === --- src/ops/core.ops (revisión: 27462) +++

Re: [perl #53472] [PATCH] jit/(ppc|arm)/exec_dep.*

On Monday 28 April 2008 14:51:29 [EMAIL PROTECTED] wrote: The attached patch fixes a breakage in the build on linux-ppc with jit. Without it, make aborts while trying to link libparrot.so with cc -o miniparrot src/main.o \ -Wl,-rpath=/home/victor/src/perl6/parrot/blib/lib -L/home

[perl #53472] [PATCH] jit/(ppc|arm)/exec_dep.*

with jit. Without it, make aborts while trying to link libparrot.so with cc -o miniparrot src/main.o \ -Wl,-rpath=/home/victor/src/perl6/parrot/blib/lib -L/home/victor/src/perl6/parrot/blib/lib -lparrot -ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto -L/usr/local/lib -Wl

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

On 01/04/2008, Mark Glines via RT [EMAIL PROTECTED] wrote: On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote: I ran a fulltest with this patch applied, and everything's fine on x86 (where it matters). Hi, The root.in portion of this patch breaks non-i386, JIT capable platforms

[perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote: I ran a fulltest with this patch applied, and everything's fine on x86 (where it matters). Hi, The root.in portion of this patch breaks non-i386, JIT capable platforms. Problem is, the patch created an exec_dep.c for i386, but added

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

On Friday 09 November 2007 00:24:43 Paul Cochrane wrote: I'll have a go at testing against the exec runcore and see what turns up. This is likely something we should be testing more often right? Definitely. I ran a fulltest with this patch applied, and everything's fine on x86 (where it

[perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

Failures have not reoccurred; resolving ticket.

Re: [perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

On Thursday 20 March 2008 18:41:06 James Keenan via RT wrote: On Thu Mar 20 16:25:54 2008, [EMAIL PROTECTED] wrote: Edit src/jit_cpu.c My build apparently didn't get that far: $ ls src/jit*.c | cat src/jit.c src/jit_debug.c src/jit_debug_xcoff.c My apologies; the file is actually src

[perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

On Wed Mar 19 22:20:59 2008, [EMAIL PROTECTED] wrote: On Wednesday 19 March 2008 17:40:03 James Keenan wrote: Revisions made in r26491 today to src/jit/ppc/jit_emit.h have broken 'make' for me on Darwin PPC. Actually, it's a lack of changes made to that file. Does this patch fix

Re: [perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

diff of my build logs. How about this patch instead? You'll have to revert the old one. (If this doesn't work, can you show me the lines with errors on them?) -- c === src/jit/ppc/core.jit == --- src/jit/ppc/core.jit (revision 26509

[perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

src/packfile/pf_items.c src/packfile/pf_items.c: In function `PackFile_assign_transforms': src/packfile/pf_items.c:867: warning: assignment from incompatible pointer type src/ops/core_ops_cg.c src/ops/core_ops_cgp.c /usr/local/bin/perl -MExtUtils::Command -e cp src/jit/ppc/exec_dep.h src/exec_dep.h

Re: [perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

On Thursday 20 March 2008 16:19:33 James Keenan via RT wrote: src/jit/ppc/core.jit: In function `Parrot_pic_callr___pc_exec': src/jit/ppc/core.jit:1261: warning: initialization from incompatible pointer type src/jit/ppc/core.jit:1270: error: request for member `cache' in something

[perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

On Thu Mar 20 16:25:54 2008, [EMAIL PROTECTED] wrote: [snip] Edit src/jit_cpu.c My build apparently didn't get that far: $ ls src/jit*.c | cat src/jit.c src/jit_debug.c src/jit_debug_xcoff.c

[perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

# New Ticket Created by James Keenan # Please include the string: [perl #51912] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51912 Revisions made in r26491 today to src/jit/ppc/jit_emit.h have broken 'make

Re: [perl #51912] [BUG]: Changes to src/jit/ppc/jit_emit.h break 'make' on Darwin PPC

On Wednesday 19 March 2008 17:40:03 James Keenan wrote: Revisions made in r26491 today to src/jit/ppc/jit_emit.h have broken 'make' for me on Darwin PPC. Actually, it's a lack of changes made to that file. Does this patch fix things for you? -- c === src/jit/ppc/core.jit

[perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

Joshua, Paul: Can you give us an update on the status of patch still? Thank you very much. kid51

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

On 16/03/2008, James Keenan via RT [EMAIL PROTECTED] wrote: Joshua, Paul: Can you give us an update on the status of patch still? As far as I remember, it still needs to be tested on the various runcores. Paul

Re: [perl #49762] [configure] JIT configuration problems on OS X

I found someone in my office with Leopard on their laptop. I'll try to take a stab at this over the weekend. -J -- On Tue, Jan 15, 2008 at 02:02:32PM +0900, Simon Cozens wrote: Joshua Hoblitt via RT wrote: What is the OSX toolchain solution for inline asm with fat binaries?

[perl #49762] [configure] JIT configuration problems on OS X

to cc -I./include -arch i386 -arch ppc ... And 'ret' is not a valid mnemonic for PPC assembler. Good luck writing assembly code which compiles under both i386 and PPC architectures. If you want the JIT core, you can't have a fat binary Parrot; if --jitcapable is set, the CFLAGS need to be adjusted

[perl #49762] [configure] JIT configuration problems on OS X

Assuming we knew *how* to fix this, my hunch is that the appropriate *place* to fix it would be config/init/hints/darwin.pm.

Re: [perl #49762] [configure] JIT configuration problems on OS X

writing assembly code which compiles under both i386 and PPC architectures. If you want the JIT core, you can't have a fat binary Parrot; if --jitcapable is set, the CFLAGS need to be adjusted to only contain one architecture. --- Summary of my parrot 0.5.1 (r24853) configuration: configdate

[perl #49718] JIT Core Needs to Handle Scheduler Tasks

# New Ticket Created by chromatic # Please include the string: [perl #49718] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49718 At least four tests fail with the new scheduler under the JIT: t/pmc/timer.t

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

On 09/11/2007, Joshua Isom [EMAIL PROTECTED] wrote: Did you test the exec runcore? I don't think any of that code is used outside of the exec runcore so you aren't actually testing that code. I'll have a go at testing against the exec runcore and see what turns up. This is likely something we

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

), but there isn't even a smoke target for it. If you look at the smoke report page, how many smokes do you see using the jit runcore on any platform? Further still, how many language smokes using jit?

[perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

# New Ticket Created by Paul Cochrane # Please include the string: [perl #47289] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47289 Hi, the attached patch moves the executable code out of src/jit/i386/exec_dep.h

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

) wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #47289] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47289 Hi, the attached patch moves the executable code out of src/jit/i386

[perl #46855] [TODO] [Pir] Fix test in t/pmc/fixedpmcarray.t to work with prederef of JIT

of JIT This issue needs fixing. Either in the test, the code which the test tests, or both.

[perl #45055] [TODO] JIT segs are currently not built

# New Ticket Created by Paul Cochrane # Please include the string: [perl #45055] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45055 Within src/jit.c there is the todo item: /* XXX * JIT segs are currently

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

Paolo Molaro wrote: On 08/16/07 Ron Blaschke wrote: This optimization reaches likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

On 08/16/07 Joshua Isom wrote: The optimization done by the parrot jit is invalid for the x86 C calling convention: the area of memory containing the passed arguments can be used as scratch space by the called function. [...] Let's go with a Microsoft blog about it, http://blogs.msdn.com

[perl #44811] Abort in t/op/string.t 91 with JIT on x86

*cur_opcode, PARROT_INTERP) { #line 317 src/ops/core.ops if (SREG(1) string_bool(interp, SREG(1))) { return (opcode_t *)cur_opcode + cur_opcode[2]; } return (opcode_t *)cur_opcode + 3; } The null test is important there. The relevant op in the JIT (at least for x86) appears

Re: [perl #44811] Abort in t/op/string.t 91 with JIT on x86

there. The relevant op in the JIT (at least for x86) appears not to make the null test, so the call continues as normal. I'm not a good enough x86 assembly programmer to fix things (I think the right code is to load the string pointer into a register, compare it to zero, and jump past the current opcode

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

On 08/16/07 Ron Blaschke wrote: This optimization reaches likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when I first

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

On Aug 16, 2007, at 5:25 AM, Paolo Molaro wrote: On 08/16/07 Ron Blaschke wrote: The optimization done by the parrot jit is invalid for the x86 C calling convention: the area of memory containing the passed arguments can be used as scratch space by the called function. If you can make sure

Need JIT help please - JIT broken with optimized build on Windows (VC)

Hi, JIT is currently broken on x86 Windows using optimized Visual C++ builds. Here's the reason why. Hopefully someone more familiar with the JIT can pick this up. ... 04e45c9a 68f06fe604 push4E66FF0h 04e45c9f e8370a1c0b call_Parrot_set_returns_pc 04e45ca4 83c404 add

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when I first realized, why the interpreter is the second argument in opcode functions

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke: Visual C++ seems to optimize quite heavily, and it looks like it reuses the memory on the stack where arguments are passed for local variables. mov     dword ptr [ebp+0Ch],edx All I know about intel calling convs would summarize this as

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

On 8/15/07, Leopold Toetsch [EMAIL PROTECTED] wrote: This optimization reaches likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when I first realized, why the interpreter is the second argument in opcode functions ;) I think it's a really cool idea, too. I'd

[perl #31166] [TODO] JIT - Make it work on more architectures

This ticket is too vague. If there's a particular architecture we need to target, open a ticket for it. On Sun Aug 15 18:14:19 2004, coke wrote: Make it work on more architectures (from the TODO file)

[perl #43245] t/op/bitwise.t #27 Fails with JIT

have an idea on what the fix might be? If it's not a quick one, we can mark this test as TODO for JIT before the release tomorrow. $ TEST_PROG_ARGS=-j prove t/op/bitwise.t t/op/bitwise # Failed test (t/op/bitwise.t at line 505) # got: 'oops; not ok: 101 32 gives I 101 vs. P

[perl #43245] t/op/bitwise.t #27 Fails with JIT

/Display.html?id=43245 r19067 needs a bit more work (pardon the pun) to work with parrot -j. Oops; guess so. :-/ Bob, do you have an idea on what the fix might be? If it's not a quick one, we can mark this test as TODO for JIT before the release tomorrow. I'm sorry, but I'm clueless when

Re: [svn:parrot] r18369 - in trunk: config/gen/platform/cygwin config/gen/platform/generic config/gen/platform/netbsd config/gen/platform/openbsd config/gen/platform/solaris src src/jit/ppc src/jit/su

On 01/05/07, Nicholas Clark [EMAIL PROTECTED] wrote: Given that that file starts: /* This is a version (aka dlmalloc) of malloc/free/realloc written by Doug Lea and released to the public domain. Use, modify, and redistribute this code without permission or acknowledgment in any way

Re: Parrot src/jit/.../jit_emit.h

of jit_emit.h. What is this good for? (This is important for me now as I'm moving the function implementations to a new jit_emit.c, and so I want to remove this.) This define hides/reveals various parts of JIT/Exec code inside either src/jit.c or the generated src/{jit,exec}_cpu.c files from src

Parrot src/jit/.../jit_emit.h

I'm working on ticket #38929 ( http://rt.perl.org/rt3//Public/Bug/Display.html?id=38929 ) As far as I can tell, there's a JIT_EMIT #define that the .c files set before they #include jit_emit.h, and what it does is switch out parts of jit_emit.h. What is this good for? (This is important for me

Re: [svn:parrot] r18369 - in trunk: config/gen/platform/cygwin config/gen/platform/generic config/gen/platform/netbsd config/gen/platform/openbsd config/gen/platform/solaris src src/jit/ppc src/jit/su

Date: Tue May 1 06:29:35 2007 New Revision: 18369 Modified: trunk/src/malloc.c Modified: trunk/src/malloc.c == [3168 lines of diff] Given that that file starts: /* This is a version (aka dlmalloc) of

Re: [svn:parrot] r18369 - in trunk: config/gen/platform/cygwin config/gen/platform/generic config/gen/platform/netbsd config/gen/platform/openbsd config/gen/platform/solaris src src/jit/ppc src/jit/su

On Tue, May 01, 2007 at 10:52:19PM +0100, Nicholas Clark wrote: Date: Tue May 1 06:29:35 2007 New Revision: 18369 Modified: trunk/src/malloc.c Modified: trunk/src/malloc.c == [3168 lines of diff]

[svn:parrot-pdd] r18216 - in trunk: docs docs/pdds/draft lib/Parrot src src/jit/i386 src/jit/sun4 t/tools

Author: chromatic Date: Sat Apr 14 20:31:19 2007 New Revision: 18216 Modified: trunk/docs/pdds/draft/pddXX_pmc.pod Changes in other areas also in this revision: Modified: trunk/docs/vtables.pod trunk/lib/Parrot/Pmc2c.pm trunk/lib/Parrot/Vtable.pm trunk/src/hll.c trunk/src/jit

[perl #40802] Investigate Supposed JIT Bug with if/unless Optimization

Hi, After chatting with leo on IRC, and observing that this bug can't be recreated with Parrot today, it appears that the apparent fix really does fix it. Comment from core.jit removed. Thanks, Jonathan

[perl #40802] Investigate Supposed JIT Bug with if/unless Optimization

On Fri Nov 10 17:36:05 2006, mdiep wrote: This was taken from t/pmc/iterator.t: # XXX # swapping the next two lines breaks JIT/i386 # the reason is the if/unless optimization: When the # previous opcode sets flags, these are used - but # there is no check

[perl #40802] Investigate Supposed JIT Bug with if/unless Optimization

lines breaks JIT/i386 # the reason is the if/unless optimization: When the # previous opcode sets flags, these are used - but # there is no check, that the same register is used in the if. inc I0 dec I1 if I1, fill I've taken this comment out of the test file because

[perl #40804] -j fails: Stack alignment of x86 JIT on Mac

# New Ticket Created by Chip Salzenberg # Please include the string: [perl #40804] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40804 I just helped Matt diagnose JIT failures on Intel Mac which seem

Re: [perl #40200] t/pmc/threads.t test 16 fails under JIT (parrot -j)

Am Samstag, 19. August 2006 06:11 schrieb Chip Salzenberg: After the STM merge, all of t/pmc/threads.t succeeds (woggle++). But one of the tests fails under JIT.  I'm hoping that somebody will recognize the reason quickly, else I'll have to dive in... It is not JIT related. The test is failing

[perl #40200] t/pmc/threads.t test 16 fails under JIT (parrot -j)

of the tests fails under JIT. I'm hoping that somebody will recognize the reason quickly, else I'll have to dive in... -- Chip Salzenberg [EMAIL PROTECTED]

[perl #38593] [TODO] JIT compiler improvements

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #38593] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38593 The JIT compiler tools/build/jit2h.pl creates src/{jit,exec}_cpu.c from src

Re: [perl #38593] [TODO] JIT compiler improvements

On Sun, Feb 19, 2006 at 03:28:32PM -0800, Leopold Toetsch wrote: *) jit2h.pl doesn't create a .h file - a better util name couldn't harm I've renamed it to jit2c.pl and added a JIT_BUILD_TOOL var in the root makefile so the path of this utility is no longer repeated encoded. -J --

PIC/JIT update

* Compiling sub on-the-fly is now implemented on PPC too [1] * there are now commandline switches, which enable this optimization: -Sj... switch core, JIT if possible -Cj... CGP core,JIT if possible E.g. on the powerbook (with speed setting dynamic - numbers might be arbitrary

  1   2   3   4   5   6   >