subject:"JIT\?"

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

2018-02-04 Thread Aleks-Daniel Jakimenko-Aleksejev via RT

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...@gmail.com wrote:
> 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 wrote:
> > 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:
> > >
> >
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3db2eae7d
> > >
> > > The bump itself brought these MoarVM changes:
> > > https://github.com/MoarVM/MoarVM/compare/2017.09.1-602-
> > > g676723d...2017.09.1-608-ge051ee3
> > >
> > >
> > > Committable output before and after:
> > > command: commit: ff063e7b53^,ff063e7b53
> > >
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > > output: https://gist.github.com/e25c6a14d6078e99f6bb46de494565b1
> > >
> > > Not surprisingly there's no crash with MVM_JIT_DISABLE:
> > > command: commit: MVM_JIT_DISABLE=1 ff063e7b53^,ff063e7b53
> > >
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > > output: https://gist.github.com/24319e448313c13c16d8b67d7961accb

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

2017-10-20 Thread Aleks-Daniel Jakimenko-Aleksejev via RT

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 wrote:
> 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:
> >
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3db2eae7d
> >
> > The bump itself brought these MoarVM changes:
> > https://github.com/MoarVM/MoarVM/compare/2017.09.1-602-
> > g676723d...2017.09.1-608-ge051ee3
> >
> >
> > Committable output before and after:
> > command: commit: ff063e7b53^,ff063e7b53
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > output: https://gist.github.com/e25c6a14d6078e99f6bb46de494565b1
> >
> > Not surprisingly there's no crash with MVM_JIT_DISABLE:
> > command: commit: MVM_JIT_DISABLE=1 ff063e7b53^,ff063e7b53
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > output: https://gist.github.com/24319e448313c13c16d8b67d7961accb

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

2017-10-20 Thread Aleks-Daniel Jakimenko-Aleksejev via RT

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:
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3db2eae7d
>
> The bump itself brought these MoarVM changes:
> https://github.com/MoarVM/MoarVM/compare/2017.09.1-602-
> g676723d...2017.09.1-608-ge051ee3
>
>
> Committable output before and after:
> command: commit: ff063e7b53^,ff063e7b53
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> output: https://gist.github.com/e25c6a14d6078e99f6bb46de494565b1
>
> Not surprisingly there's no crash with MVM_JIT_DISABLE:
> command: commit: MVM_JIT_DISABLE=1 ff063e7b53^,ff063e7b53
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> output: https://gist.github.com/24319e448313c13c16d8b67d7961accb

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

2017-10-20 Thread via RT

# 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:
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3db2eae7d

The bump itself brought these MoarVM changes:
https://github.com/MoarVM/MoarVM/compare/2017.09.1-602-g676723d...2017.09.1-608-ge051ee3


Committable output before and after:
command: commit: ff063e7b53^,ff063e7b53 
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
output: https://gist.github.com/e25c6a14d6078e99f6bb46de494565b1

Not surprisingly there's no crash with MVM_JIT_DISABLE:
command: commit: MVM_JIT_DISABLE=1 ff063e7b53^,ff063e7b53 
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
output: https://gist.github.com/24319e448313c13c16d8b67d7961accb

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

2017-10-19 Thread Aleks-Daniel Jakimenko-Aleksejev via RT

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 tests for this, but it's probably non-trivial.

Anyway, ｢testneeded｣.

On 2017-10-11 09:11:01, nlo...@gmail.com wrote:
> Discovered by failing tests in Net::HTTP xt/* on rakudo/nqp/moar
> master, the following output shows a compile time error that did not
> occur in the previous rakudo release (2017.09):
>
> $ perl6 -I. xt/500-transport.t
> 1..4
> ===SORRY!===
> last without loop construct
>
> Besiect output:
> https://gist.github.com/Whateverable/5e61264647a48c145c8bf0d93178087d
> 
>
> Changes brought in by:
> https://github.com/MoarVM/MoarVM/compare/2017.09.1-62-
> g89ca8eb...2017.09.1-553-ga4fef0b
>  g89ca8eb...2017.09.1-553-ga4fef0b>
>
> IRC discussion:
> https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15286229
> 
>
>
> Note that I worked around this bug in a recent version bump (0.0.7),
> so to reproduce you would need to use version 0.0.6 (I was unable to
> golf this).
>
> Net::HTTP:ver("0.0.6")
> https://github.com/ugexe/Perl6-Net--
> HTTP/archive/140b02d56adbb9026fda611e8b03466f49b27205.tar.gz
>  HTTP/archive/140b02d56adbb9026fda611e8b03466f49b27205.tar.gz>
>
> Net::HTTP workaround:
> https://github.com/ugexe/Perl6-Net--
> HTTP/commit/df628c2e636149c81a648b95f33aff4a523f8e3d#diff-
> 50314871012a1cd9a7b0d9310f517607L17

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

2017-10-11 Thread via RT

# 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 shows a compile time error that did not occur in the previous 
rakudo release (2017.09):

$ perl6 -I. xt/500-transport.t
1..4
===SORRY!===
last without loop construct

Besiect output:
https://gist.github.com/Whateverable/5e61264647a48c145c8bf0d93178087d 


Changes brought in by:
https://github.com/MoarVM/MoarVM/compare/2017.09.1-62-g89ca8eb...2017.09.1-553-ga4fef0b
 


IRC discussion:
https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15286229 



Note that I worked around this bug in a recent version bump (0.0.7), so to 
reproduce you would need to use version 0.0.6 (I was unable to golf this).

Net::HTTP:ver("0.0.6")
https://github.com/ugexe/Perl6-Net--HTTP/archive/140b02d56adbb9026fda611e8b03466f49b27205.tar.gz
 


Net::HTTP workaround:
https://github.com/ugexe/Perl6-Net--HTTP/commit/df628c2e636149c81a648b95f33aff4a523f8e3d#diff-50314871012a1cd9a7b0d9310f517607L17

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

2017-07-29 Thread Steve Mynott

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 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 at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 127
>in method hash at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 21
>in method hash at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 114
>in code  at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 93
>in method provides-spec-matcher at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 104
>in method contains-spec at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 109
>in block  at
> C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708
> (Zef::Repository::Ecosystems) line 65
>in code  at
> C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708
> (Zef::Repository::Ecosystems) line 64
>in code  at
> C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9
> (Zef::Repository) line 46
>in method search at
> C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9
> (Zef::Repository) line 45
>in method search at
> C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA
> (Zef::Client) line 398
>in sub MAIN at
> C:\rakudo\share\perl6\site\sources\ED3033E8712BCF9F6DE53678B14A54705DF211A6
> (Zef::CLI) line 189
>in block  at
> C:\rakudo\share\perl6\site\resources\DC5F87DA28311BE6F3A731229527E5C4A2F12716
> line 1
>in sub MAIN at c:\rakudo\share\perl6\site\bin\zef line 2
>in block  at c:\rakudo\share\perl6\site\bin\zef line 2
>
>
> --
> C-x C-c



-- 
4096R/EA75174B Steve Mynott

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

2017-07-29 Thread Steve Mynott via RT

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 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 at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 127
>in method hash at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 21
>in method hash at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 114
>in code  at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 93
>in method provides-spec-matcher at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 104
>in method contains-spec at
> C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839
> (Zef::Distribution) line 109
>in block  at
> C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708
> (Zef::Repository::Ecosystems) line 65
>in code  at
> C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708
> (Zef::Repository::Ecosystems) line 64
>in code  at
> C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9
> (Zef::Repository) line 46
>in method search at
> C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9
> (Zef::Repository) line 45
>in method search at
> C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA
> (Zef::Client) line 398
>in sub MAIN at
> C:\rakudo\share\perl6\site\sources\ED3033E8712BCF9F6DE53678B14A54705DF211A6
> (Zef::CLI) line 189
>in block  at
> C:\rakudo\share\perl6\site\resources\DC5F87DA28311BE6F3A731229527E5C4A2F12716
> line 1
>in sub MAIN at c:\rakudo\share\perl6\site\bin\zef line 2
>in block  at c:\rakudo\share\perl6\site\bin\zef line 2
>
>
> --
> C-x C-c



-- 
4096R/EA75174B Steve Mynott

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

2017-07-29 Thread via RT

# 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 at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 127
   in method hash at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 21
   in method hash at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 114
   in code  at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 93
   in method provides-spec-matcher at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 104
   in method contains-spec at  
C:\rakudo\share\perl6\site\sources\8C459CF2854824E080AE9C6535800798F2F63839  
(Zef::Distribution) line 109
   in block  at  
C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708  
(Zef::Repository::Ecosystems) line 65
   in code  at  
C:\rakudo\share\perl6\site\sources\1C8E65E6D82673962813E2440B1D654800A1B708  
(Zef::Repository::Ecosystems) line 64
   in code  at  
C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9  
(Zef::Repository) line 46
   in method search at  
C:\rakudo\share\perl6\site\sources\66F156D9D6AB4154EDE8BB12B35EBB2315A749F9  
(Zef::Repository) line 45
   in method search at  
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA  
(Zef::Client) line 398
   in sub MAIN at  
C:\rakudo\share\perl6\site\sources\ED3033E8712BCF9F6DE53678B14A54705DF211A6  
(Zef::CLI) line 189
   in block  at  
C:\rakudo\share\perl6\site\resources\DC5F87DA28311BE6F3A731229527E5C4A2F12716  
line 1
   in sub MAIN at c:\rakudo\share\perl6\site\bin\zef line 2
   in block  at c:\rakudo\share\perl6\site\bin\zef line 2


-- 
C-x C-c

Re: JIT?

2017-01-13 Thread ToddAndMargo


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


I missed that (32 vs 64).  Thank you!

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: JIT?

2017-01-13 Thread Steve Mynott

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?

2017-01-11 Thread ToddAndMargo


  
  
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
  client/server programs.
  


Thank you!


-- 
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: JIT?

2017-01-11 Thread yary

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?

2017-01-11 Thread ToddAndMargo


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.   The code I was going
to write was to manipulate data on an FTP server.
Do I need JIT?

Many thanks,
-T

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

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

2016-05-14 Thread Christian Bartolomaeus via RT

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

2016-05-13 Thread via RT

# 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 re-enabled before the next release.

-- 
Will "Coke" Coleda

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

2014-09-09 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 20a1fd6b01315abaae3a3f49e6cccaa2fbb5b7e4
  
https://github.com/perl6/specs/commit/20a1fd6b01315abaae3a3f49e6cccaa2fbb5b7e4
  Author: L. Grondin grond...@yahoo.fr
  Date:   2014-09-09 (Tue, 09 Sep 2014)

  Changed paths:
M S99-glossary.pod

  Log Message:
  ---
  resolve link for JIT compiler

[perl6/specs] 1a7b77: elaborate JIT

2014-09-08 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 1a7b77e199b3ea11b3dd94216d81f7335e0fd739
  
https://github.com/perl6/specs/commit/1a7b77e199b3ea11b3dd94216d81f7335e0fd739
  Author: L. Grondin grond...@yahoo.fr
  Date:   2014-09-09 (Tue, 09 Sep 2014)

  Changed paths:
M S99-glossary.pod

  Log Message:
  ---
  elaborate JIT

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

2008-08-03 Thread Reini Urban


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, would these failures have
cleared up because you're working on FreeBSD 7 as distinct from the
FreeBSD 6 on which the problems were reported?


I have no idea of the difference of freebsd6 to 7.
I assume there's nothing important, and that recent parrot fixes fixed that.

perl is still 5.8.8, gcc is now higher: 4.2.1

--
Reini Urban
http://phpwiki.org/  http://murbreak.at/

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

2008-08-02 Thread Reini Urban via RT

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 gmake.

Summary of my parrot 0.6.4 (r0) configuration:
  configdate='Sat Aug  2 13:08:54 2008 GMT'
  Platform:
osname=freebsd, archname=i386-freebsd-64int
jitcapable=1, jitarchname=i386-freebsd,
jitosname=FREEBSD, jitcpuarch=i386
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN
-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H  -pipe
-Wdeclaration-after-statement -I/usr/local/include -DHASATTRIBUTE_CONST
 -DHASATTRIBUTE_DEPRECATED  -DHASATTRIBUTE_MALLOC 
-DHASATTRIBUTE_NONNULL  -DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE 
-DHASATTRIBUTE_UNUSED  -DHASATTRIBUTE_WARN_UNUSED_RESULT 
-falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W
-Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts
-Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat
-Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
-Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces
-Wmissing-field-initializers -Wno-missing-format-attribute
-Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare
-Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default
-Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros
-Wwrite-strings -Wbad-function-cast -Wc++-compat
-Wdeclaration-after-statement -Wimplicit-function-declaration
-Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wnonnull -DHAS_GETTEXT',
  Linker and Libraries:
ld='cc', ldflags=' -Wl,-E -L/usr/lib -L/usr/local/lib',
cc_ldflags='',
libs='-lm -lcrypt -lutil -pthread -lgmp -lreadline -lpcre -lcrypto
-lintl'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/lib -L/usr/local/lib',
load_ext='.so', ld_load_flags='-shared -L/usr/lib -L/usr/local/lib'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
-- 
Reini Urban

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

2008-08-02 Thread James Keenan via RT

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 have
cleared up because you're working on FreeBSD 7 as distinct from the
FreeBSD 6 on which the problems were reported?

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

2008-07-14 Thread Christoph Otto via RT

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 been any responses to this and since based on
http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk it looks like this is
fixed, I'm marking this ticket as resolved.

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

2008-07-13 Thread NotFound via RT

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

2008-07-11 Thread tuxdna

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)



$ make

Compiling with:
xx.c
gcc -I./include -D_REENTRANT -D_GNU_SOURCE -pipe
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
-fvisibility=hidden -maccumulate-outgoing-args -W -Wall
-Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts
-Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat
-Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
-Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch
-Wmissing-braces -Wmissing-field-initializers
-Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked
-Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point
-Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2
-Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas
-Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast
-Wc++-compat -Wdeclaration-after-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/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/jit/i386/core.jit:1031: error: expected ';' before '{' token
src/jit/i386/core.jit:1031: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_eq_nc_n_ic_exec':
src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_ne_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: expected ';' before '{' token
src/jit/i386/core.jit:1031: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_ne_nc_n_ic_exec':
src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_lt_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: expected ';' before '{' token
src/jit/i386/core.jit:1031: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_lt_nc_n_ic_exec':
src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_le_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: expected ';' before '{' token
src/jit/i386/core.jit:1031: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_le_nc_n_ic_exec':
src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit:989: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_isle_i_n_n_exec':
src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:1519: error: expected ';' before '{' token
src/jit/i386/core.jit:1519: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_isle_i_nc_n_exec':
src/jit/i386/core.jit:1626: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:1626: error: expected ';' before '{' token
src/jit/i386/core.jit:1626: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_islt_i_n_n_exec':
src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:1519: error: expected ';' before '{' token
src/jit/i386/core.jit:1519: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_islt_i_nc_n_exec':
src/jit/i386/core.jit:1626: error: 'DO' undeclared (first use in this function)
src/jit/i386/core.jit:1626: error: expected ';' before '{' token
src/jit/i386/core.jit:1626: error: expected ';' before '{' token
src/jit/i386/core.jit: In function 'Parrot_iseq_i_n_n_exec':
src/jit/i386/core.jit:1519: error: 'DO

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

2008-07-11 Thread Moritz Lenz

tuxdna wrote:
 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)

It seems that was introduced in r29284 while trying to fix another issue.

Maybe someone more familiar with the guts should revert that commit (if
it was the offending one indeed

 
 
 $ make
 
 Compiling with:
 xx.c
 gcc -I./include -D_REENTRANT -D_GNU_SOURCE -pipe
 -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
 -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DHASATTRIBUTE_CONST
 -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
 -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
 -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall
 -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts
 -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat
 -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
 -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch
 -Wmissing-braces -Wmissing-field-initializers
 -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked
 -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point
 -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2
 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas
 -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast
 -Wc++-compat -Wdeclaration-after-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/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/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_eq_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_n_n_exec':
 src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in this 
 function)
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_nc_n_exec':
 src/jit/i386/core.jit:1626: error: 'DO' undeclared (first use in this 
 function)
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_islt_i_n_n_exec':
 src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in this 
 function)
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_islt_i_nc_n_exec':
 src/jit/i386/core.jit

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

2008-07-11 Thread via RT

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #56832]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56832 


Open a ticket...

--
Will Coke Coleda

Begin forwarded message:

 From: tuxdna [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)



 $ make

 Compiling with:
 xx.c
 gcc -I./include -D_REENTRANT -D_GNU_SOURCE -pipe
 -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
 -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DHASATTRIBUTE_CONST
 -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
 -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
 -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall
 -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts
 -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat
 -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
 -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch
 -Wmissing-braces -Wmissing-field-initializers
 -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked
 -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point
 -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2
 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas
 -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast
 -Wc++-compat -Wdeclaration-after-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/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/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_eq_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this  
 function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this  
 function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this  
 function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this  
 function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_n_n_exec':
 src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in  
 this function)
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_nc_n_exec':
 src/jit/i386/core.jit:1626: error: 'DO' undeclared (first use in  
 this function)
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_islt_i_n_n_exec':
 src/jit/i386/core.jit:1519: error: 'DO' undeclared

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

2008-07-11 Thread NotFound

 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

2008-07-11 Thread NotFound

 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

2008-07-11 Thread Will Coleda

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 PROTECTED]


tuxdna wrote:
 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)

It seems that was introduced in r29284 while trying to fix another issue.

Maybe someone more familiar with the guts should revert that commit (if
it was the offending one indeed



 $ make

 Compiling with:
 xx.c
 gcc -I./include -D_REENTRANT -D_GNU_SOURCE -pipe
 -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
 -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DHASATTRIBUTE_CONST
 -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
 -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
 -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall
 -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts
 -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat
 -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
 -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch
 -Wmissing-braces -Wmissing-field-initializers
 -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked
 -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point
 -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2
 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas
 -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast
 -Wc++-compat -Wdeclaration-after-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/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/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_eq_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_ne_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_lt_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_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: expected ';' before '{' token
 src/jit/i386/core.jit:1031: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_le_nc_n_ic_exec':
 src/jit/i386/core.jit:989: error: 'DO' undeclared (first use in this function)
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit:989: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_n_n_exec':
 src/jit/i386/core.jit:1519: error: 'DO' undeclared (first use in this 
 function)
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit:1519: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function 'Parrot_isle_i_nc_n_exec':
 src/jit/i386/core.jit:1626: error: 'DO' undeclared (first use in this 
 function)
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit:1626: error: expected ';' before '{' token
 src/jit/i386/core.jit: In function

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

2008-07-11 Thread via RT

# 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/test_exec_cygwin.in

Added #include string.h to fix implicit memcpy warning
Changed to memalign(PAGE_SIZE, PAGE_SIZE) because the start and size 
need to be aligned. posix_memalign(...) doesn't exist on cygwin, so 
alignment of size needs to be done manually. Fixes segv in test.

Regards,
Donald Hunter.
Index: config/auto/jit/test_exec_cygwin.in
===
--- config/auto/jit/test_exec_cygwin.in (revision 29223)
+++ config/auto/jit/test_exec_cygwin.in (working copy)
@@ -5,6 +5,7 @@
 #include errno.h
 #include malloc.h
 #include unistd.h
+#include string.h
 #ifndef PAGE_SIZE
 #  define PAGE_SIZE getpagesize()
 #endif
@@ -40,7 +41,7 @@
 if (atoi(argv[1]))
 prot |= PROT_EXEC;
 
-p = memalign(PAGE_SIZE, sizeof(code));
+p = memalign(PAGE_SIZE, PAGE_SIZE);
 memcpy(p, code, sizeof(code));
 
 t  = (pf) p;

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

2008-07-11 Thread Christoph Otto via RT

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

2008-06-14 Thread James Keenan via RT

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

2008-06-07 Thread chromatic

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 this still an issue for you?

Yes; it's still a TODO test and it's still failing.

-- c

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

2008-06-05 Thread Will Coleda via RT

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 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 0.
 # -2147483648
 # oops; not ok: 101  33 gives I 202 vs. P 0.
 # -2147483648
 # oops; not ok: 101  34 gives I 404 vs. P 0.
 # -2147483648
 # oops; not ok: 101  35 gives I 808 vs. P 0.
 # -2147483648
 # oops; not ok: 101  36 gives I 1616 vs. P 0.
 # -2147483648
 # oops; not ok: 101  37 gives I 3232 vs. P 0.
 # -2147483648
 # oops; not ok: 101  38 gives I 6464 vs. P 0.
 # -2147483648
 # oops; not ok: 101  39 gives I 128000128 vs. P 0.
 # -2147483648
 # oops; not ok: 101  40 gives I 256000256 vs. P 0.
 # -2147483648
 # oops; not ok: 101  41 gives I 512000512 vs. P 0.
 # -2147483648
 # oops; not ok: 101  42 gives I 1024001024 vs. P 0.
 # -2147483648
 # oops; not ok: 101  43 gives I 2048002048 vs. P 0.
 # -2147483648
 # oops; not ok: 101  44 gives I -198963200 vs. P 0.
 # -198963200
 # oops; not ok: 101  45 gives I -397926400 vs. P 0.
 # -397926400
 # oops; not ok: 101  46 gives I -795852800 vs. P 0.
 # -795852800
 # oops; not ok: 101  47 gives I -1591705600 vs. P 0.
 # -1591705600
 # oops; not ok: 101  48 gives I 556096 vs. P 0.
 # -1591705600
 # oops; not ok: 101  49 gives I -2071855104 vs. P 0.
 # -2071855104
 # oops; not ok: 101  50 gives I 151257088 vs. P 0.
 # -2071855104
 # oops; not ok: 101  51 gives I 302514176 vs. P 0.
 # -2071855104
 # oops; not ok: 101  52 gives I 605028352 vs. P 0.
 # -2071855104
 # oops; not ok: 101  53 gives I 1210056704 vs. P 0.
 # -2071855104
 # oops; not ok: 101  54 gives I -1874853888 vs. P 0.
 # -1874853888
 # oops; not ok: 101  55 gives I 545259520 vs. P 0.
 # -1874853888
 # oops; not ok: 101  56 gives I 1090519040 vs. P 0.
 # -1874853888
 # oops; not ok: 101  57 gives I -2113929216 vs. P 0.
 # -2113929216
 # oops; not ok: 101  58 gives I 67108864 vs. P 0.
 # -2113929216
 # oops; not ok: 101  59 gives I 134217728 vs. P 0.
 # -2113929216
 # oops; not ok: 101  60 gives I 268435456 vs. P 0.
 # -2113929216
 # oops; not ok: 101  61 gives I 536870912 vs. P 0.
 # -2113929216
 # oops; not ok: 101  62 gives I 1073741824 vs. P 0.
 # -2113929216
 # oops; not ok: 101  64 gives I 101 vs. P 0.
 # -2147483648
 # oops; not ok: 101  65 gives I 202 vs. P 0.
 # -2147483648
 # oops; not ok: 101  66 gives I 404 vs. P 0.
 # -2147483648
 # oops; not ok: 101  67 gives I 808 vs. P 0.
 # -2147483648
 # oops; not ok: 101  68 gives I 1616 vs. P 0.
 # -2147483648
 # oops; not ok: 101  69 gives I 3232 vs. P 0.
 # -2147483648
 # oops; not ok: 101  70 gives I 6464 vs. P 0.
 # -2147483648
 # oops; not ok: 101  71 gives I 128000128 vs. P 0.
 # -2147483648
 # oops; not ok: 101  72 gives I 256000256 vs. P 0.
 # -2147483648
 # oops; not ok: 101  73 gives I 512000512 vs. P 0.
 # -2147483648
 # oops; not ok: 101  74 gives I 1024001024 vs. P 0.
 # -2147483648
 # oops; not ok: 101  75 gives I 2048002048 vs. P 0.
 # -2147483648
 # oops; not ok: 101  76 gives I -198963200 vs. P 0.
 # -198963200
 # oops; not ok: 101  77 gives I -397926400 vs. P 0.
 # -397926400
 # oops; not ok: 101  78 gives I -795852800 vs. P 0.
 # -795852800
 # oops; not ok: 101  79 gives I -1591705600 vs. P 0.
 # -1591705600
 # oops; not ok: 101  80 gives I 556096 vs. P 0.
 # -1591705600
 # oops; not ok: 101  81 gives I -2071855104 vs. P 0.
 # -2071855104
 # oops; not ok: 101  82 gives I 151257088 vs. P 0.
 # -2071855104
 # oops; not ok: 101  83 gives I 302514176 vs. P 0.
 # -2071855104
 # oops; not ok: 101  84 gives I 605028352 vs. P 0.
 # -2071855104
 # oops; not ok: 101  85 gives I 1210056704 vs. P 0.
 # -2071855104
 # oops; not ok: 101  86 gives I -1874853888 vs. P 0.
 # -1874853888
 # oops; not ok: 101  87 gives I 545259520 vs. P 0.
 # -1874853888
 # oops; not ok: 101  88 gives I 1090519040 vs. P 0.
 # -1874853888
 # oops; not ok: 101  89 gives I -2113929216 vs. P 0.
 # -2113929216
 # oops; not ok: 101  90 gives I 67108864 vs. P 0.
 # -2113929216
 # oops; not ok: 101  91 gives I 134217728 vs. P 0.
 # -2113929216
 # oops; not ok: 101  92 gives I 268435456 vs. P 0.
 # -2113929216
 # oops; not ok: 101  93 gives I 536870912 vs. P 0.
 # -2113929216
 # oops; not ok: 101  94 gives I 1073741824 vs. P 0.
 # -2113929216
 # oops; not ok: 101  96 gives I 101 vs. P 0.
 # -2147483648
 # oops; not ok: 101  97 gives I 202 vs. P 0.
 # -2147483648
 # oops; not ok: 101  98 gives I 404 vs. P 0

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

2008-06-05 Thread Will Coleda via RT

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 in...
 
 It is not JIT related. The test is failing with -S or -C as well. But given 
 that 2 threads are changing the same (unprotected?) global, it is not 
 surprising that it fails.
 
 leo
 

Cleaning up old tickets.

This test file passes with -j, -S, and -C. as of Revision: 28125.

Closing ticket.

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

2008-06-01 Thread chromatic via RT

I believe I've fixed the problem in r27999.

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

2008-05-31 Thread via RT

# 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 or with g++.

-- 
Salu2
Index: src/jit/i386/jit_emit.h
===
--- src/jit/i386/jit_emit.h	(revisiÃ³n: 27973)
+++ src/jit/i386/jit_emit.h	(copia de trabajo)
@@ -25,7 +25,10 @@
 #  define JIT_CGP
 #endif
 
-static void call_func(Parrot_jit_info_t *jit_info, void *addr);
+static void call_func(Parrot_jit_info_t *jit_info, void (*addr) (void));
+
+static void jit_emit_real_exception(Parrot_jit_info_t *jit_info);
+
 /*
  * get the register frame pointer
  */
@@ -1728,7 +1731,7 @@
 Parrot_jit_emit_get_INTERP(interp, pc, emit_ECX);
 emitm_pushl_r(pc, emit_ECX);
 jit_info-native_ptr = pc;
-call_func(jit_info, (void *) real_exception);
+jit_emit_real_exception(jit_info);
 pc = jit_info-native_ptr;
 /* L1: */
 L1[1] = (char)(pc - L1 - 2);
@@ -1767,7 +1770,7 @@
 Parrot_jit_emit_get_INTERP(interp, pc, emit_ECX);
 emitm_pushl_r(pc, emit_ECX);
 jit_info-native_ptr = pc;
-call_func(jit_info, (void *) real_exception);
+jit_emit_real_exception(jit_info);
 pc = jit_info-native_ptr;
 /* L1: */
 L1[1] = (char)(pc - L1 - 2);
@@ -1961,7 +1964,7 @@
 Parrot_jit_emit_get_INTERP(interp, pc, emit_ECX);
 emitm_pushl_r(pc, emit_ECX);
 jit_info-native_ptr = pc;
-call_func(jit_info, (void *) real_exception);
+jit_emit_real_exception(jit_info);
 pc = jit_info-native_ptr;
 /* L3: */
 L3[1] = (char)(pc - L3 - 2);
@@ -2237,7 +2240,7 @@
 
 
 
-static void call_func(Parrot_jit_info_t *jit_info, void *addr)
+static void call_func(Parrot_jit_info_t *jit_info, void (*addr) (void))
 {
 Parrot_jit_newfixup(jit_info);
 jit_info-arena.fixups-type = JIT_X86CALL;
@@ -2245,6 +2248,10 @@
 emitm_calll(jit_info-native_ptr, 0xdeafc0de);
 }
 
+static void jit_emit_real_exception(Parrot_jit_info_t *jit_info)
+{
+call_func(jit_info, (void (*) (void))  real_exception);
+}
 
 #if JIT_VTABLE_OPS
 
@@ -2782,7 +2789,7 @@
 else
 #  endif
 {
-call_func(jit_info, (void*)pmc_new_noinit);
+call_func(jit_info, (void (*) (void))pmc_new_noinit);
 }
 /* result = eax push pmc */
 emitm_pushl_r(jit_info-native_ptr, emit_EAX);
@@ -3609,7 +3616,7 @@
 emitm_pushl_i(jit_info-native_ptr, CORE_OPS_check_events);
 
 call_func(jit_info,
-(void *)(interp-op_func_table[CORE_OPS_check_events]));
+(void (*) (void)) (interp-op_func_table[CORE_OPS_check_events]));
 #ifdef PARROT_JIT_STACK_REUSE_INTERP
 emitm_addb_i_r(jit_info-native_ptr, 4, emit_ESP);
 #else
@@ -3631,7 +3638,7 @@
 emitm_pushl_i(jit_info-native_ptr, jit_info-cur_op);
 
 call_func(jit_info,
-(void *)(interp-op_func_table[cur_op]));
+(void (*) (void))(interp-op_func_table[cur_op]));
 #ifdef PARROT_JIT_STACK_REUSE_INTERP
 emitm_addb_i_r(jit_info-native_ptr, 4, emit_ESP);
 #else
Index: src/jit/i386/core.jit
===
--- src/jit/i386/core.jit	(revisiÃ³n: 27973)
+++ src/jit/i386/core.jit	(copia de trabajo)
@@ -7,7 +7,7 @@
 # TODO complete this
 #define P_ARITH ((PREV_OP == dec_i) || (PREV_OP == inc_i) || (PREV_OP == sub_i_i_i) || (PREV_OP == sub_i_i))
 
-#define CALL_FUNCTION(j, f) call_func(j, f)
+#define CALL_FUNCTION(j, f) call_func(j, (void (*)(void))  f)
 
 Parrot_end {
 jit_emit_end(NATIVECODE);
@@ -1114,7 +1114,7 @@
 Parrot_jit_emit_get_INTERP(interp, jit_info-native_ptr, emit_ECX);
 emitm_pushl_i(NATIVECODE, CONST(2)-u.string);
 emitm_pushl_r(NATIVECODE, emit_ECX);
-CALL_FUNCTION(jit_info, (void*) string_copy);
+CALL_FUNCTION(jit_info, string_copy);
 emitm_addb_i_r(NATIVECODE, 8, emit_ESP);
 jit_emit_mov_MR_i(interp, NATIVECODE, ROFFS_STR(1), emit_EAX );
 }
@@ -1129,7 +1129,7 @@
 push_typ1(1);
 Parrot_jit_emit_get_INTERP(interp, jit_info-native_ptr, emit_ECX);
 emitm_pushl_r(NATIVECODE, emit_ECX);
-CALL_FUNCTION(jit_info, (void*)string_compare);
+CALL_FUNCTION(jit_info, string_compare);
 emitm_addb_i_r(NATIVECODE, 12, emit_ESP);
 jit_emit_test_r_i(NATIVECODE, emit_EAX);
 jit_emit_jcc(jit_info, op, *INT_CONST[3]);
@@ -1146,7 +1146,7 @@
 push_typ1(1);
 Parrot_jit_emit_get_INTERP(interp, jit_info-native_ptr, emit_ECX);
 emitm_pushl_r(NATIVECODE, emit_ECX);
-CALL_FUNCTION(jit_info, (void*)string_equal);
+CALL_FUNCTION(jit_info, string_equal);
 emitm_addb_i_r(NATIVECODE, 12, emit_ESP);
 jit_emit_test_r_i(NATIVECODE, emit_EAX);
 jit_emit_jcc(jit_info, op, *INT_CONST[3]);
@@ -1212,7 +1212,7 @@
 push_typ(1);
 Parrot_jit_emit_get_INTERP(interp, jit_info-native_ptr, emit_ECX

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

2008-05-31 Thread chromatic

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

2008-05-13 Thread NotFound

On Mon, May 12, 2008 at 7:40 PM, chromatic [EMAIL PROTECTED] wrote:

  I fixed a few similar problems with the optimized build.  Is r27069 any
  guidance?  r23771 looks like it might affect this function as well.

string_bool signature was modified in 23771, but was marked as not null anyway.

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

2008-05-13 Thread NotFound

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)
@@ -315,7 +315,7 @@
 }
 
 op if (invar STR, labelconst INT) {
-if ($1  string_bool(interp, $1))
+if (string_bool(interp, $1))
 goto OFFSET($2);
 }
 
@@ -349,7 +349,7 @@
 }
 
 op unless(invar STR, labelconst INT) {
-if (!$1 || !string_bool(interp, $1))
+if (!string_bool(interp, $1))
 goto OFFSET($2);
 }
 
Index: src/string.c
===
--- src/string.c	(revisiÃ³n: 27474)
+++ src/string.c	(copia de trabajo)
@@ -1806,9 +1806,9 @@
 PARROT_API
 PARROT_WARN_UNUSED_RESULT
 INTVAL
-string_bool(PARROT_INTERP, ARGIN(const STRING *s))
+string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
 {
-const INTVAL len = string_length(interp, s);
+const INTVAL len = s ? string_length(interp, s) : 0;
 
 if (len == 0)
 return 0;
Index: src/pmc/string.pmc
===
--- src/pmc/string.pmc	(revisiÃ³n: 27474)
+++ src/pmc/string.pmc	(copia de trabajo)
@@ -167,7 +167,7 @@
 
 VTABLE INTVAL get_bool() {
 STRING * const s = VTABLE_get_string(INTERP, SELF);
-return s ? string_bool(INTERP, s) : 0;
+return string_bool(INTERP, s);
 }
 
 /*
Index: CREDITS
===
--- CREDITS	(revisiÃ³n: 27474)
+++ CREDITS	(copia de trabajo)
@@ -1,4 +1,4 @@
-ï»¿# $Id$
+# $Id$
 
 Following in the steps of other open source projects that
 eventually take over the world, here is the partial list
@@ -498,6 +498,10 @@
 N: Nigelsandever
 D: Win32 patches
 
+N: NotFound
+D: Bug fixing and cage cleaning.
+E: [EMAIL PROTECTED]
+
 N: Nuno 'smash' Carvalho
 D: PGE/perl6/abc debugging and testing
 E: [EMAIL PROTECTED]
Index: include/parrot/string_funcs.h
===
--- include/parrot/string_funcs.h	(revisiÃ³n: 27474)
+++ include/parrot/string_funcs.h	(copia de trabajo)
@@ -150,9 +150,8 @@
 
 PARROT_API
 PARROT_WARN_UNUSED_RESULT
-INTVAL string_bool(PARROT_INTERP, ARGIN(const STRING *s))
-__attribute__nonnull__(1)
-__attribute__nonnull__(2);
+INTVAL string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
+__attribute__nonnull__(1);
 
 PARROT_API
 PARROT_WARN_UNUSED_RESULT

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

2008-05-12 Thread NotFound

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 number #91 if_s_ic, the last part 'ok 
 10':

 clears
 if  S1, BAD10
 branch  OK10

  the if op for S1, which is null, is giving an assertion error. I tried
  to poke around the jit core source code for a bit, but wasn't able to
  fix it. My parrot's jit knowledge is not that good, I admit. Can
  anyone more confortable on this area shed some light on the subject.

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 unconditionally.

The easier solution is to redefine string_bool to allow a NULL
argument and return false in that case. Many places in the code does
that check before the call, so this change will simplify it.

I expect to hear some comments before preparing a patch, given that
this will change the signature of a widely used function.

-- 
Salu2

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

2008-05-12 Thread Patrick R. Michaud via RT

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 NULL
  argument and return false in that case. Many places in the code does
  that check before the call, so this change will simplify it.
 
 +1 from me.  I'd even give this +2 if I could.
 
 Notably, many of the functions in src/string.c check for NULL values
 prior to performing a function (e.g., string_equal, string_concat, etc.)
 so it makes very good sense to me for string_bool to do the same.
 
 Pm

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

2008-05-12 Thread chromatic

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 unconditionally.

 The easier solution is to redefine string_bool to allow a NULL
 argument and return false in that case. Many places in the code does
 that check before the call, so this change will simplify it.

 I expect to hear some comments before preparing a patch, given that
 this will change the signature of a widely used function.

I fixed a few similar problems with the optimized build.  Is r27069 any 
guidance?  r23771 looks like it might affect this function as well.

-- c

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

2008-05-12 Thread NotFound

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)
+++ src/ops/core.ops	(copia de trabajo)
@@ -315,7 +315,7 @@
 }
 
 op if (invar STR, labelconst INT) {
-if ($1  string_bool(interp, $1))
+if (string_bool(interp, $1))
 goto OFFSET($2);
 }
 
@@ -349,7 +349,7 @@
 }
 
 op unless(invar STR, labelconst INT) {
-if (!$1 || !string_bool(interp, $1))
+if (!string_bool(interp, $1))
 goto OFFSET($2);
 }
 
Index: src/string.c
===
--- src/string.c	(revisiÃ³n: 27462)
+++ src/string.c	(copia de trabajo)
@@ -1806,9 +1806,9 @@
 PARROT_API
 PARROT_WARN_UNUSED_RESULT
 INTVAL
-string_bool(PARROT_INTERP, ARGIN(const STRING *s))
+string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
 {
-const INTVAL len = string_length(interp, s);
+const INTVAL len = s ? string_length(interp, s) : 0;
 
 if (len == 0)
 return 0;
Index: src/pmc/string.pmc
===
--- src/pmc/string.pmc	(revisiÃ³n: 27462)
+++ src/pmc/string.pmc	(copia de trabajo)
@@ -167,7 +167,7 @@
 
 VTABLE INTVAL get_bool() {
 STRING * const s = VTABLE_get_string(INTERP, SELF);
-return s ? string_bool(INTERP, s) : 0;
+return string_bool(INTERP, s);
 }
 
 /*
Index: CREDITS
===
--- CREDITS	(revisiÃ³n: 27462)
+++ CREDITS	(copia de trabajo)
@@ -1,4 +1,4 @@
-ï»¿# $Id$
+Ã¿# $Id$
 
 Following in the steps of other open source projects that
 eventually take over the world, here is the partial list
@@ -498,6 +498,10 @@
 N: Nigelsandever
 D: Win32 patches
 
+N: NotFound
+D: Bug fixing and cage cleaning.
+E: [EMAIL PROTECTED]
+
 N: Nuno 'smash' Carvalho
 D: PGE/perl6/abc debugging and testing
 E: [EMAIL PROTECTED]
Index: include/parrot/string_funcs.h
===
--- include/parrot/string_funcs.h	(revisiÃ³n: 27462)
+++ include/parrot/string_funcs.h	(copia de trabajo)
@@ -150,9 +150,8 @@
 
 PARROT_API
 PARROT_WARN_UNUSED_RESULT
-INTVAL string_bool(PARROT_INTERP, ARGIN(const STRING *s))
-__attribute__nonnull__(1)
-__attribute__nonnull__(2);
+INTVAL string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
+__attribute__nonnull__(1);
 
 PARROT_API
 PARROT_WARN_UNUSED_RESULT

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

2008-04-30 Thread chromatic

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/victor/src/perl6/parrot/blib/lib -lparrot  -ldl -lm -lpthread
 -lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto
 -L/usr/local/lib -Wl,-E   src/null_config.o
 /home/victor/src/perl6/parrot/blib/lib/libparrot.so: undefined reference
 to `offset_fixup'

  A change in the declaration of offset_fixup from void to static void
 appears to have caused this.  It's been a long time since I've done any
 C programming (decades in fact) so go easy.  I can include the myconfig
 if requested.  This fixes the build for me, but ymmv.  I've included a
 mysimilar change for ARM on the theory that the declarations are the
 same there and may well be similarly broken.  I'm not subscribed to the
 list, so replies should go to my email rather than the list.

This looks correct to me (and I think I'm the one who broke it).

Thanks, applied as r27248.

-- c

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

2008-04-29 Thread via RT

# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #53472]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53472 


Hi All,

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/victor/src/perl6/parrot/blib/lib -lparrot  -ldl -lm -lpthread
-lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto
-L/usr/local/lib -Wl,-E   src/null_config.o
/home/victor/src/perl6/parrot/blib/lib/libparrot.so: undefined reference
to `offset_fixup'

 A change in the declaration of offset_fixup from void to static void
appears to have caused this.  It's been a long time since I've done any
C programming (decades in fact) so go easy.  I can include the myconfig
if requested.  This fixes the build for me, but ymmv.  I've included a
mysimilar change for ARM on the theory that the declarations are the
same there and may well be similarly broken.  I'm not subscribed to the
list, so replies should go to my email rather than the list.

Cheers

Victor
-- 
Victor Brunsden
Associate Professor of Mathematics,
Penn State Altoona,
119 Hawthorn Bldg,
3000 Ivyside Drive
Altoona, PA 16601
(814) 949-5695 (work)
(814) 949-5547 (fax)
http://math.aa.psu.edu/~victor

Index: src/jit/arm/exec_dep.h
===
--- src/jit/arm/exec_dep.h	(revision 27217)
+++ src/jit/arm/exec_dep.h	(working copy)
@@ -29,7 +29,7 @@
 Parrot_exec_restart_op(Parrot_jit_info_t *jit_info, PARROT_INTERP);
 
 /* Assign the offset of the program_code */
-static void
+void
 offset_fixup(Parrot_exec_objfile_t *obj);
 
 #endif /* PARROT_ARM_EXEC_DEP_H_GUARD */
Index: src/jit/arm/exec_dep.c
===
--- src/jit/arm/exec_dep.c	(revision 27217)
+++ src/jit/arm/exec_dep.c	(working copy)
@@ -78,7 +78,7 @@
 }
 
 /* Assign the offset of the progra_code */
-static void
+void
 offset_fixup(Parrot_exec_objfile_t *obj)
 {
 int i, j;
Index: src/jit/ppc/exec_dep.h
===
--- src/jit/ppc/exec_dep.h	(revision 27217)
+++ src/jit/ppc/exec_dep.h	(working copy)
@@ -28,7 +28,7 @@
 void
 Parrot_exec_restart_op(Parrot_jit_info_t *jit_info, PARROT_INTERP);
 
-static void
+void
 offset_fixup(Parrot_exec_objfile_t *obj);
 
 #endif /* PARROT_PPC_EXEC_DEP_H_GUARD */
Index: src/jit/ppc/exec_dep.c
===
--- src/jit/ppc/exec_dep.c	(revision 27217)
+++ src/jit/ppc/exec_dep.c	(working copy)
@@ -60,7 +60,7 @@
 }
 
 /* Assign the offset of the program_code */
-static void
+void
 offset_fixup(Parrot_exec_objfile_t *obj)
 {
 int i, j;

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

2008-04-06 Thread Paul Cochrane

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.  Problem is, the patch created an exec_dep.c for i386, but
 added a Makefile dependency for $(SRC_DIR)/exec_dep.c on *ALL*
 platforms, and that file doesn't exist anywhere except for x86.

 So, tetragon is now reporting on IRC that builds fail on ppc.  Sounds
 like reverting r26636 will result in a successful build... testing that now.

IIRC there's a special flag one can set inside Makefile.pm (I think...
:-/ ) which will allow this dependency to only be added for x86
platforms.  My guess is that this would be the appropriate way to get
this patch working on all platforms.

Paul

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

2008-04-01 Thread Mark Glines via RT

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 a Makefile dependency for $(SRC_DIR)/exec_dep.c on *ALL*
platforms, and that file doesn't exist anywhere except for x86.

So, tetragon is now reporting on IRC that builds fail on ppc.  Sounds
like reverting r26636 will result in a successful build... testing that now.

Mark

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

2008-03-29 Thread chromatic

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 matters).

Thanks, applied as r26636.

-- c

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

2008-03-27 Thread James Keenan via RT

Failures have not reoccurred; resolving ticket.

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

2008-03-21 Thread chromatic

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/exec_cpu.c.

I managed to log in to a Darwin PPC machine though; did r26507 fix this for 
you?

-- c

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

2008-03-20 Thread James Keenan via RT

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 
 things for you?
 
 -- c
 

Unfortunately, no.  'make' failed at almost exactly the same point.  See
attached diff of my build logs.



447,448d446
 src/jit/ppc/core.jit: In function `Parrot_get_results_pc_exec':
 src/jit/ppc/core.jit:1306: error: invalid type argument of `-'
450,451c448,452
 src/jit/ppc/core.jit:1265: error: invalid type argument of `-'
 src/jit/ppc/core.jit:1272: error: invalid type argument of `-'
---
 src/jit/ppc/core.jit:1261: warning: initialization from incompatible pointer 
 type
 src/jit/ppc/core.jit:1264: error: `op_i' undeclared (first use in this 
 function)
 src/jit/ppc/core.jit:1264: error: (Each undeclared identifier is reported 
 only once
 src/jit/ppc/core.jit:1264: error: for each function it appears in.)
 src/jit/ppc/core.jit:1270: error: request for member `cache' in something not 
 a structure or union

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

2008-03-20 Thread chromatic

On Thursday 20 March 2008 04:35:11 James Keenan via RT wrote:

 On Wed Mar 19 22:20:59 2008, [EMAIL PROTECTED] wrote:

  Actually, it's a lack of changes made to that file.  Does this patch fix
  things for you?

 Unfortunately, no.  'make' failed at almost exactly the same point.  See
 attached 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)
+++ src/jit/ppc/core.jit	(local)
@@ -1258,31 +1258,29 @@
 }
 
 Parrot_pic_callr___pc {
-int offset, here, op_i;
-PackFile_Constant ** constants;
-PMC *sig_params, *sig_result;
-opcode_t *params;
-int skip;
+PackFile_Constant **constants  = CONTEXT(interp)-constants;
+PMC   **sig_result = constants[CUR_OPCODE[1]]-u.key;
+opcode_t   *params = jit_info-optimizer-sections-begin;
+PMC*sig_params = constants[params[1]]-u.key;
+int op_i   = SIG_ELEMS(sig_params) + 2;
+int offset = jit_info-arena.op_map[op_i].offset;
+int here   = NATIVECODE - jit_info-arena.start;
+int skip;
 
-constants = CONTEXT(interp-ctx)-constants;
-params = jit_info-optimizer-sections-begin;
-sig_params = constants[params[1]]-u.key;
-op_i = 2 + SIG_ELEMS(sig_params);
-
-offset = jit_info-arena.op_map[op_i].offset;
 /* TODO preserve necessary regs */
 assert(*CUR_OPCODE == PARROT_OP_get_results_pc);
-constants = CONTEXT(interp-ctx)-constants;
-sig_result = constants[CUR_OPCODE[1]]-u.key;
+
 if (!SIG_ELEMS(sig_result))
-skip = -1;
+skip = -1;
+/* skip result - save rest */
 else
-skip = MAP(2);  /* skip result - save rest */
+skip = MAP(2);
 
-here = NATIVECODE - jit_info-arena.start;
 offset -= here;
-_emit_bx(NATIVECODE, 1, offset); /* bl */
 
+/* bl */
+_emit_bx(NATIVECODE, 1, offset);
+
 jit_restore_regs_call(jit_info, interp, skip);
 }
 
@@ -1302,13 +1300,12 @@
 offsetof(parrot_context_t, current_results), ISR2);
 }
 else {
-PackFile_Constant ** constants;
-PMC *sig_result;
+PackFile_Constant **constants  = CONTEXT(interp)-constants;
+PMC*sig_result = constants[CUR_OPCODE[1]]-u.key;
 
-constants = CONTEXT(interp-ctx)-constants;
-sig_result = constants[CUR_OPCODE[1]]-u.key;
 if (!SIG_ELEMS(sig_result))
 return;
+
 /* result is r3 TODO Nums */
 jit_emit_mov_rr(NATIVECODE, MAP(2), r3);
 }

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

2008-03-20 Thread James Keenan via RT

/gc/gc_gms.c
src/gc/gc_ims.c
src/gc/memory.c
src/gc/register.c
src/gc/smallobject.c
src/global.c
src/global_setup.c
src/hash.c
src/headers.c
src/hll.c
src/inter_call.c
src/inter_cb.c
src/inter_create.c
src/inter_misc.c
src/interpreter.c
src/inter_run.c
src/intlist.c
src/key.c
src/library.c
src/list.c
src/longopt.c
src/misc.c
src/mmd.c
/usr/local/bin/perl tools/build/nativecall.pl src/call_list.txt
src/nci.c
src/oo.c
src/packfile.c
src/packout.c
src/pic_jit.c
src/pic.c
src/platform.c
config/gen/platform/darwin/dl.c:27:2: warning: #import is obsolete, use an 
#ifndef wrapper in the header file
config/gen/platform/darwin/dl.c: In function `Parrot_dlclose':
config/gen/platform/darwin/dl.c:273: warning: cast does not match function type
src/pmc_freeze.c
src/pmc.c
/usr/local/bin/perl -Ilib tools/build/revision_c.pl  src/revision.c
src/revision.c
src/runops_cores.c
src/scheduler.c
src/spf_render.c
src/spf_vtable.c
src/stack_common.c
src/stacks.c
src/stm/backend.c
src/stm/waitlist.c
src/string_primitives.c
src/sub.c
src/thread.c
src/trace.c
src/tsq.c
src/utils.c
src/vtables.c
src/warnings.c
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
/usr/local/bin/perl -MExtUtils::Command -e cp src/jit/ppc/jit_emit.h 
src/jit_emit.h
src/exec.c
In file included from src/exec.c:26:
src/jit_emit.h:23:7: warning: PARROT_EXEC_OS_AIX is not defined
src/jit_emit.h:683:5: warning: PARROT_EXEC_OS_AIX is not defined
In file included from src/exec.c:26:
src/jit_emit.h: In function `div_rrr':
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h: In function `fdiv_rrr':
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h: In function `jit_get_params_pc':
src/jit_emit.h:896: warning: switch missing default case
/usr/local/bin/perl tools/build/jit2c.pl ppc src/exec_cpu.c
jit2c: JITed 144 (+ 140 vtable) of 1273 ops
src/exec_cpu.c
In file included from src/exec_cpu.c:51:
src/jit_emit.h:23:7: warning: PARROT_EXEC_OS_AIX is not defined
src/jit_emit.h:683:5: warning: PARROT_EXEC_OS_AIX is not defined
In file included from src/exec_cpu.c:51:
src/jit_emit.h: In function `div_rrr':
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:722: warning: cast discards qualifiers from pointer target type
src/jit_emit.h: In function `fdiv_rrr':
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h:755: warning: cast discards qualifiers from pointer target type
src/jit_emit.h: In function `jit_get_params_pc':
src/jit_emit.h:896: warning: switch missing default case
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 not a 
structure or union
make: *** [src/exec_cpu.o] Error 1

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

2008-03-20 Thread chromatic

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 not a structure or union

Edit src/jit_cpu.c (I know it's read-only; trust me on this) and delete every 
line that starts with #line (in Vim, that's the command :%s/#line.*//).  
Rebuild.  Then I only need the warnings and errors from src/jit_cpu.c in the 
make log, as well as the contents of that file.

-- c

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

2008-03-20 Thread James Keenan via RT

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

2008-03-19 Thread via RT

# 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' for me on Darwin PPC.

Attachments:


r26491 | chromatic | 2008-03-19 03:13:39 -0400 (Wed, 19 Mar 2008) | 3 lines

[src] Changed CONTEXT(interp-ctx) to CONTEXT(interp), which seems clearer and
fulfills RT #41881.  If we need to rearrange how we store contexts in the
interpreter, we can rearrange it in only the macro now.



[li11-226:parrot] 537 $ svn diff -r {2008-03-18} ./src/jit/ppc/jit_emit.h
Index: src/jit/ppc/jit_emit.h
===
--- src/jit/ppc/jit_emit.h  (revision 26458)
+++ src/jit/ppc/jit_emit.h  (working copy)
@@ -877,7 +877,7 @@
 static void
 jit_get_params_pc(Parrot_jit_info_t *jit_info, PARROT_INTERP)
 {
-PMC*sig_pmc  = CONTEXT(interp-ctx)-constants[CUR_OPCODE[1]]-u.key;
+PMC*sig_pmc  = CONTEXT(interp)-constants[CUR_OPCODE[1]]-u.key;
 INTVAL *sig_bits = PMC_data_typed(sig_pmc, INTVAL *);
 INTVAL  n= PMC_int_val(sig_pmc);
 INTVAL  i;
@@ -905,7 +905,7 @@
 PMC *sig_pmc;
 INTVAL *sig_bits, sig;
 
-sig_pmc = CONTEXT(interp-ctx)-constants[CUR_OPCODE[1]]-u.key;
+sig_pmc = CONTEXT(interp)-constants[CUR_OPCODE[1]]-u.key;
 if (!SIG_ELEMS(sig_pmc))
 return;
 sig_bits = SIG_ARRAY(sig_pmc);
@@ -976,7 +976,7 @@
 internal_exception(1, set_args_jit - can't do that yet );
 }
 
-constants = CONTEXT(interp-ctx)-constants;
+constants = CONTEXT(interp)-constants;
 sig_args = constants[CUR_OPCODE[1]]-u.key;
 if (!SIG_ELEMS(sig_args))
 return;
@@ -1034,7 +1034,7 @@
 jit_emit_mflr(jit_info-native_ptr, r0);/* store link reg */
 jit_emit_stw(jit_info-native_ptr, r0, 8, r1); /* stw r0,8(r1) */
 jit_emit_stwu(jit_info-native_ptr, r1, -64, r1);
-used_i = CONTEXT(interp-ctx)-n_regs_used[REGNO_INT];
+used_i = CONTEXT(interp)-n_regs_used[REGNO_INT];
 reg_info = jit_info-arch_info-regs[jit_info-code_type];
 for (i = 0; i  used_i; ++i) {
 if (reg_info-map_I[i] == skip)
@@ -1054,7 +1054,7 @@
 int i, used_i, save_i;
 const jit_arch_regs *reg_info;
 
-used_i = CONTEXT(interp-ctx)-n_regs_used[REGNO_INT];
+used_i = CONTEXT(interp)-n_regs_used[REGNO_INT];
 reg_info = jit_info-arch_info-regs[jit_info-code_type];
 /* note - reversed order of jit_save_regs  */
 for (i = used_i - 1; i = 0; --i) {

src_jit_ppc__jit_emit.h.changes.txt:  What was changed and why.

Compiling with:
xx.c
/usr/bin/gcc-3.3 -I./include -fno-common -no-cpp-precomp -pipe 
-I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST 
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC 
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE 
-DHASATTRIBUTE_UNUSED -falign-functions=16 -W -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment 
-Wdisabled-optimization -Wendif-labels -Wformat -Wformat-extra-args 
-Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit 
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline -Winvalid-pch 
-Wmain -Wmissing-braces -Wmissing-declarations -Wno-missing-format-attribute 
-Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses 
-Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare 
-Wstrict-aliasing -Wswitch -Wswitch-default -Wtrigraphs -Wundef 
-Wunknown-pragmas -Wno-unused -Wwrite-strings -I/sw/include -DHAS_GETTEXT -g 
-Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
/usr/local/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops 
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops 
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops 
src/ops/set.ops src/ops/stack.ops src/ops/stm.ops src/ops/string.ops 
src/ops/sys.ops src/ops/var.ops 
gcd_i_n_n 1226   experimental, not in ops.num
gcd_i_nc_n1227   experimental, not in ops.num
gcd_i_n_nc1228   experimental, not in ops.num
gcd_i_nc_nc   1229   experimental, not in ops.num
gcd_i_i_i_i_i 1230   experimental, not in ops.num
gcd_i_i_i_ic_i1231   experimental, not in ops.num
gcd_i_i_i_i_ic1232   experimental, not in ops.num
gcd_i_i_i_ic_ic   1233   experimental, not in ops.num
splice_p_p_i_i1234   experimental, not in ops.num
splice_p_p_ic_i   1235   experimental, not in ops.num
splice_p_p_i_ic   1236   experimental, not in ops.num
splice_p_p_ic_ic  1237   experimental, not in ops.num

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

2008-03-19 Thread chromatic

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
==
--- src/jit/ppc/core.jit	(revision 26508)
+++ src/jit/ppc/core.jit	(local)
@@ -1258,31 +1258,29 @@
 }
 
 Parrot_pic_callr___pc {
-int offset, here, op_i;
-PackFile_Constant ** constants;
-PMC *sig_params, *sig_result;
-opcode_t *params;
+PackFile_Constant **constants  = CONTEXT(interp)-constants;
+PMC   **sig_result = constants[CUR_OPCODE[1]]-u.key;
+opcode_t   *params = jit_info-optimizer-sections-begin;
+PMC*sig_params = constants[params[1]]-u.key;
+int offset = jit_info-arena.op_map[op_i].offset;
+int here   = NATIVECODE - jit_info-arena.start;
+int op_i   = SIG_ELEMS(sig_params) + 2;
 int skip;
 
-constants = CONTEXT(interp-ctx)-constants;
-params = jit_info-optimizer-sections-begin;
-sig_params = constants[params[1]]-u.key;
-op_i = 2 + SIG_ELEMS(sig_params);
-
-offset = jit_info-arena.op_map[op_i].offset;
 /* TODO preserve necessary regs */
 assert(*CUR_OPCODE == PARROT_OP_get_results_pc);
-constants = CONTEXT(interp-ctx)-constants;
-sig_result = constants[CUR_OPCODE[1]]-u.key;
+
 if (!SIG_ELEMS(sig_result))
-skip = -1;
+skip = -1;
+/* skip result - save rest */
 else
-skip = MAP(2);  /* skip result - save rest */
+skip = MAP(2);
 
-here = NATIVECODE - jit_info-arena.start;
 offset -= here;
-_emit_bx(NATIVECODE, 1, offset); /* bl */
 
+/* bl */
+_emit_bx(NATIVECODE, 1, offset);
+
 jit_restore_regs_call(jit_info, interp, skip);
 }
 
@@ -1302,13 +1300,12 @@
 offsetof(parrot_context_t, current_results), ISR2);
 }
 else {
-PackFile_Constant ** constants;
-PMC *sig_result;
+PackFile_Constant **constants  = CONTEXT(interp)-constants;
+PMC*sig_result = constants[CUR_OPCODE[1]]-u.key;
 
-constants = CONTEXT(interp-ctx)-constants;
-sig_result = constants[CUR_OPCODE[1]]-u.key;
 if (!SIG_ELEMS(sig_result))
 return;
+
 /* result is r3 TODO Nums */
 jit_emit_mov_rr(NATIVECODE, MAP(2), r3);
 }

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

2008-03-16 Thread James Keenan via RT

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

2008-03-16 Thread Paul Cochrane

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

2008-01-15 Thread Joshua Hoblitt

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?
 
 Architecture-specific ifdefs. gcc -arch ppc -arch i386 will run the compile 
 twice, and then bundle the two results together, so ifdefs will do the 
 right thing.
 
 At some point we have to assume that people who are setting CFLAGS know
 what they are doing. 
 
 I am not setting CFLAGS. Configure is. 'perl Configure.pl' on OS X Leopard 
 will try to build fat binaries by default. This is not me doing anything 
 clever; it's just a plain old-fashioned configure bug.


pgpsgiZ4amtjF.pgp
Description: PGP signature

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

2008-01-14 Thread via RT

# New Ticket Created by  Simon Cozens 
# Please include the string:  [perl #49762]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49762 


osname= darwin
osvers= 9.0
arch=   darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
Configuring with --jitcapable will fail on OS X with the following
error:

{standard input}:94:Invalid mnemonic 'ret'

I am on an Intel Mac, and 'ret' is a valid mnemonic for Intel assembler.
The problem is that my CFLAGS are set by default 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 to only contain one
architecture.

---
Summary of my parrot 0.5.1 (r24853) configuration:
  configdate='Mon Jan 14 14:37:05 2008 GMT'
  Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=i386-darwin,
jitosname=DARWIN, jitcpuarch=i386
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-arch i386 -arch ppc -g -pipe -fno-common -no-cpp-precomp 
 -Wdeclaration-after-statement -I/usr/local/include -pipe -fno-common 
-Wno-long-double  -DHASATTRIBUTE_CONST  -DHASATTRIBUTE_DEPRECATED  
-DHASATTRIBUTE_FORMAT  -DHASATTRIBUTE_MALLOC  -DHASATTRIBUTE_NONNULL  
-DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE  -DHASATTRIBUTE_UNUSED  
-DHASATTRIBUTE_WARN_UNUSED_RESULT  -falign-functions=16 -W -Wall 
-Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual 
-Wchar-subscripts -Wcomment -Wdeclaration-after-statement 
-Wdisabled-optimization -Wextra -Wformat-nonliteral -Wformat-security 
-Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport 
-Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces 
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs 
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow -Wno-unused 
-Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point 
-Ws
 ign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default 
-Wtrigraphs -Wundef -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings',
  Linker and Libraries:
ld='c++', ldflags='-arch i386 -arch ppc -L/usr/local/lib 
-L/Users/simon/svn/parrot/blib/lib -flat_namespace  -L/sw/lib -L/sw/lib',
cc_ldflags='',
libs='-lm -lutil'
  Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress',
load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8

---
Environment:
DYLD_LIBRARY_PATH  (unset)
HOME =/Users/simon
LANG =C
LANGUAGE  (unset)
LD_LIBRARY_PATH  (unset)
LOGDIR  (unset)
PATH 
=/sw/bin:/sw/sbin/:/Users/simon/bin:/sw/bin:/sw/sbin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/local/teTeX/bin/i386-apple-darwin-current:/usr/X11/bin:/usr/local/teTeX/bin/i386-apple-darwin-current
SHELL =/bin/zsh

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

2008-01-14 Thread James Keenan via RT

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

2008-01-14 Thread Joshua Hoblitt

What is the OSX toolchain solution for inline asm with fat binaries?

At some point we have to assume that people who are setting CFLAGS know
what they are doing.  We can't look for or protect against every silly
thing they might do.  Perhaps if --jitcapable is set and we're on darwin
the thing to do is print a warning about fat binaries and --jitcapable
being mutually exclusive things.

-J

--
On Mon, Jan 14, 2008 at 08:18:02AM -0800, Simon Cozens wrote:
 # New Ticket Created by  Simon Cozens 
 # Please include the string:  [perl #49762]
 # in the subject line of all future correspondence about this issue. 
 # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49762 
 
 
 osname= darwin
 osvers= 9.0
 arch=   darwin-thread-multi-2level
 cc= cc
 ---
 Flags:
 category=core
 severity=medium
 ack=no
 ---
 Configuring with --jitcapable will fail on OS X with the following
 error:
 
 {standard input}:94:Invalid mnemonic 'ret'
 
 I am on an Intel Mac, and 'ret' is a valid mnemonic for Intel assembler.
 The problem is that my CFLAGS are set by default 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 to only contain one
 architecture.
 
 ---
 Summary of my parrot 0.5.1 (r24853) configuration:
   configdate='Mon Jan 14 14:37:05 2008 GMT'
   Platform:
 osname=darwin, archname=darwin-thread-multi-2level
 jitcapable=1, jitarchname=i386-darwin,
 jitosname=DARWIN, jitcpuarch=i386
 execcapable=1
 perl=perl
   Compiler:
 cc='cc', ccflags='-arch i386 -arch ppc -g -pipe -fno-common 
 -no-cpp-precomp  -Wdeclaration-after-statement -I/usr/local/include -pipe 
 -fno-common -Wno-long-double  -DHASATTRIBUTE_CONST  -DHASATTRIBUTE_DEPRECATED 
  -DHASATTRIBUTE_FORMAT  -DHASATTRIBUTE_MALLOC  -DHASATTRIBUTE_NONNULL  
 -DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE  -DHASATTRIBUTE_UNUSED  
 -DHASATTRIBUTE_WARN_UNUSED_RESULT  -falign-functions=16 -W -Wall 
 -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual 
 -Wchar-subscripts -Wcomment -Wdeclaration-after-statement 
 -Wdisabled-optimization -Wextra -Wformat-nonliteral -Wformat-security 
 -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int 
 -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces 
 -Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs 
 -Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow 
 -Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type 
 -Wsequence-point -Ws
  ign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default 
 -Wtrigraphs -Wundef -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings',
   Linker and Libraries:
 ld='c++', ldflags='-arch i386 -arch ppc -L/usr/local/lib 
 -L/Users/simon/svn/parrot/blib/lib -flat_namespace  -L/sw/lib -L/sw/lib',
 cc_ldflags='',
 libs='-lm -lutil'
   Dynamic Linking:
 share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress',
 load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
   Types:
 iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
 ptrsize=4, ptr_alignment=1 byteorder=1234, 
 nv=double, numvalsize=8, doublesize=8
 
 ---
 Environment:
 DYLD_LIBRARY_PATH  (unset)
 HOME =/Users/simon
 LANG =C
 LANGUAGE  (unset)
 LD_LIBRARY_PATH  (unset)
 LOGDIR  (unset)
 PATH 
 =/sw/bin:/sw/sbin/:/Users/simon/bin:/sw/bin:/sw/sbin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/local/teTeX/bin/i386-apple-darwin-current:/usr/X11/bin:/usr/local/teTeX/bin/i386-apple-darwin-current
 SHELL =/bin/zsh

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

2008-01-12 Thread via RT

# 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(Wstat: 256 Tests: 6 Failed: 1)
  Failed test number(s):  5
  Non-zero exit status: 1
t/dynoplibs/myops.t  (Wstat: 768 Tests: 10 Failed: 3)
  Failed test number(s):  5-7
  Non-zero exit status: 3

I believe that this is because the JIT core doesn't emit instructions to call 
Parrot_cx_handle_tasks() often enough.  These tests probably won't pass until 
this happens.

-- c

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

2007-11-09 Thread Paul Cochrane

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 should be testing more often right?

Paul

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

2007-11-09 Thread Joshua Isom



On Nov 9, 2007, at 2:24 AM, Paul Cochrane wrote:


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 should be testing more often right?

Paul



Most of the runcores are greatly undertested.  The switched runcore for 
instance is small in executable size, and faster than the standard 
runcore(great for embedded systems on both parts), 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

2007-11-08 Thread via RT

# 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 into /src/jit/i386/exec_dep.c and updates the
relevant config files appropriately.  This makes and tests without
error (after realclean) on linux x86 (Gentoo).  If noone has problems
with this patch, then I'll commit it in about 3 days.

Paul

Files affected:

src/jit/i386/exec_dep.h
src/jit/i386/exec_dep.c
config/auto/jit.pm
config/gen/makefiles/root.in


i386_exec_dep.patch
Description: Binary data

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

2007-11-08 Thread Joshua Isom

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.


Also, I'm not sure the exec runcore even works.  I haven't heard of it 
working in quite some time.


On Nov 8, 2007, at 3:21 PM, Paul Cochrane (via RT) 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/exec_dep.h into /src/jit/i386/exec_dep.c and updates the
relevant config files appropriately.  This makes and tests without
error (after realclean) on linux x86 (Gentoo).  If noone has problems
with this patch, then I'll commit it in about 3 days.

Paul

Files affected:

src/jit/i386/exec_dep.h
src/jit/i386/exec_dep.c
config/auto/jit.pm
config/gen/makefiles/root.in
i386_exec_dep.patch

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

2007-10-24 Thread via RT

# New Ticket Created by  Paul Cochrane 
# Please include the string:  [perl #46855]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46855 


In t/pmc/fixedpmcarray.t there is the todo item:

 # XXX doesnt work wit prederef 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

2007-08-30 Thread via RT

# 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 not built
 * the find_segments also segfaults on PPC eval_2
 * maybe something not initialized correctly
 * - disabled --leo
 */

To not build the JIT segs means that we get some dead code in parrot
(as mentioned in Coverity CID 71).  In this case dead code isn't such
a bad thing, however it means that a feature of parrot which could
(should?) be there, isn't.  So, it'd be nice if this could be added
back in and any problems found corrected.

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

2007-08-22 Thread Ron Blaschke

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, 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 like to have a way to disable
 it, though, to measure its effect, and maybe to work around compilers
 like VC (at least until a better solution comes around).
 
 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 it's not harmful that way you could still use it
 when calling parrot's own jitted functions which could use a different
 calling convention, but it is wrong when interoperating with other code
 (gcc can generate the same issues, so it's not just VC).

Many thanks for your help.  I couldn't find detailed descriptions of the
x86 C calling convention, which also talk about this.  But as nobody
explicitly says you can reuse it, I guess it's undefined and should be
avoided.

Thanks,
Ron

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

2007-08-20 Thread Paolo Molaro

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/oldnewthing/archive/2004/01/08/48616.aspx.  With 
 __stdcall, the callee cleans the stack.  With __cdecl(used everywhere else, 
 and in part of windows), the caller cleans the stack.  If the ops are 
 converted to __cdecl, it should help fix it(since the function shouldn't 
 logically assume anything about how much stack space is available for 
 clobbering).  I'm having trouble finding anything about who owns the stack 
 space.  My personal view is that the caller owns that stack space, since it 
 can also be used to store local variables, i.e. don't move around data 
 that's in order for calling a function.

It doesn't matter if the call conv is cdecl or stdcall, you always end
up with arguments on the stack:

arg2
arg1
arg0
return ip
[possibly old ebp value]

The location where arg0, arg1 and arg2 are stored on the stack can and
will be overwritten by the called function, it doesn't matter if esp is
restored by the caller or by the callee. So, if someone wants to do the
following calls:
foo (1, 2, 3);
foo (1, 2, 3);

it can't emit (with cdecl):

push 3
push 2
push 1
call foo
call foo
add esp, 12

because the stack words where 1, 2 and 3 where stored may have been
overwritten by the first call to foo, resulting in garbage being passed
to the second call.
The called function knows that it can clobber the stack space where
arguments were passed to it (it is of course a compiler bug if it
changes data above the passed-in arguments).

lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better

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

2007-08-20 Thread via RT

# New Ticket Created by  chromatic 
# Please include the string:  [perl #44811]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44811 


Test 91 fails at this PASM with the -j flat on x86 Linux:

# An empty register should be false...
clears
if  S1, BAD10
branch  OK10
BAD10:. print.  not 
OK10:.  print.  ok 10\n

.   end

The problem *appears* to be an assertion in string_bool() failing, because the 
string is null.  The appropriate if opcode is:

opcode_t *
Parrot_if_s_ic (opcode_t *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 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, but as for how to do that, I'm not sure), but 
it looks like an easy fix.

-- c

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

2007-08-20 Thread Joshua Isom



On Aug 20, 2007, at 7:10 PM, chromatic (via RT) wrote:


# New Ticket Created by  chromatic
# Please include the string:  [perl #44811]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44811 


Test 91 fails at this PASM with the -j flat on x86 Linux:

# An empty register should be false...
clears
if  S1, BAD10
branch  OK10
BAD10:. print.  not 
OK10:.  print.  ok 10\n

.   end

The problem *appears* to be an assertion in string_bool() failing, 
because the

string is null.  The appropriate if opcode is:

opcode_t *
Parrot_if_s_ic (opcode_t *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 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, but as for how to do that, I'm not 
sure), but

it looks like an easy fix.

-- c



Just out of curiosity, why not make string_bool accept a null pointer?  
It at least seems to make sense to me.  Plus it would be easier than 
fixing the jit.

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

2007-08-16 Thread Paolo Molaro

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 realized, why the interpreter is the second argument 
  in 
  opcode functions ;)
 
 I think it's a really cool idea, too.  I'd like to have a way to disable
 it, though, to measure its effect, and maybe to work around compilers
 like VC (at least until a better solution comes around).

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 it's not harmful that way you could still use it
when calling parrot's own jitted functions which could use a different
calling convention, but it is wrong when interoperating with other code
(gcc can generate the same issues, so it's not just VC).

lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better

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

2007-08-16 Thread Joshua Isom



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 it's not harmful that way you could still use it
when calling parrot's own jitted functions which could use a different
calling convention, but it is wrong when interoperating with other code
(gcc can generate the same issues, so it's not just VC).

lupus

--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better



Let's go with a Microsoft blog about it, 
http://blogs.msdn.com/oldnewthing/archive/2004/01/08/48616.aspx.  
With __stdcall, the callee cleans the stack.  With __cdecl(used 
everywhere else, and in part of windows), the caller cleans the stack.  
If the ops are converted to __cdecl, it should help fix it(since the 
function shouldn't logically assume anything about how much stack space 
is available for clobbering).  I'm having trouble finding anything 
about who owns the stack space.  My personal view is that the caller 
owns that stack space, since it can also be used to store local 
variables, i.e. don't move around data that's in order for calling a 
function.

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

2007-08-15 Thread Ron Blaschke

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 esp,4
04e45ca7 68f86fe604  push4E66FF8h
04e45cac e8e6481c0b  call_Parrot_returncc
04e45cb1 83c404  add esp,4
...

Both functions(CParrot_set_returns_pc and CParrot_returncc) take
Copcode_t *cur_opcode, Parrot_Interp interp as arguments.

The stack top contains a pointer to the interpreter, C4E66FF0h and
C4E66FF8h are pointers to the opcodes.

As you can see, the code is heavily optimized.  The pointer to the
interpreter is kept on the stack as it should stay the same, only the
opcode is exchanged.  *should* is the key word here.

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.

libparrot!Parrot_set_returns_pc:
pushebp
mov ebp,esp

At this point, the stack looks like so.

* stack frame pointer save (ebp+0h)
* return address (ebp+4h)
* cur_opcode (ebp+8h)
* interp (ebp+Ch)

mov eax,dword ptr [ebp+0Ch]
mov ecx,dword ptr [eax]

ecx now contains interp.

pushesi
mov esi,dword ptr [ebp+8]
mov edx,dword ptr [esi+4]
pushedi
mov edi,dword ptr [ecx+58h]
mov edx,dword ptr [edi+edx*4]
mov edx,dword ptr [edx+8]
mov dword ptr [eax+0E8h],esi
mov edi,dword ptr [ecx+3Ch]
mov dword ptr [ebp+0Ch],edx

I won't decode above in detail here, but it's the following code.

opcode_t * const _this = CUR_OPCODE;
parrot_context_t *ctx;
PMC *ccont;
PMC *signature = $1;
INTVAL argc;
opcode_t *src_indexes, *dest_indexes;

interp-current_returns = _this;
ctx = CONTEXT(interp-ctx);
ccont = ctx-current_cont;

Notice the last mov.  This means ccont reuses the memory previously used
by interp.  That's why returncc does not receive the correct interp.

Ron

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

2007-08-15 Thread Leopold Toetsch

Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke:
 As you can see, the code is heavily optimized.  The pointer to the
 interpreter is kept on the stack as it should stay the same, only the
 opcode is exchanged.  *should* is the key word here.

Well, another note.

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 realized, why the interpreter is the second argument in 
opcode functions ;)

leo 

[1] well at least for ancient architectures like x86, which don't have 
register calling convs for parts of the arguments

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

2007-08-15 Thread Leopold Toetsch

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 a nasty compiler 
bug, not an optimization. This statement is clearly overwrting a stack frame 
location, which doesn't belong to the called subroutine.

Maybe an explicit auto var of the interp would prevent this bug, something 
like:

inline op returncc() {
Interp *i = interp;   /* f*ck Visual C++ version ... */
PMC * const p = CONTEXT(i-ctx)-current_cont;
opcode_t * const dest = (opcode_t *)p-vtable-invoke(i,
p, expr NEXT());
goto ADDRESS(dest);
}

or some dummy statements #if def that compiler version or variations of above 
idea.

Great analysis of the problem BTW,
thanks,
leo

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

2007-08-15 Thread jerry gay

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 I first realized, why the interpreter is the second argument in
 opcode functions ;)

aha! now i know why interp is the second arg for opcode functions.
that always bothered me, and i couldn't figure out why it was against
the norm. leo++ for bringing it up. now, to make sure it's documented
somewhere

~jerry

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

2007-08-15 Thread Ron Blaschke

Leopold Toetsch wrote:
 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 a nasty compiler 
 bug, not an optimization. This statement is clearly overwrting a stack frame 
 location, which doesn't belong to the called subroutine.

I took this for granted too until today.  Now that I think about it I'm
wondering...  The caller copies the values in and is responsible for
free(3)ing, but does it also own the data?
What about code that assumes it owns the local variable that represents
the argument.

void f(int x)
{
/* x is mine, and mine alone */
x = ...;
}

 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 realized, why the interpreter is the second argument in 
 opcode functions ;)

I think it's a really cool idea, too.  I'd like to have a way to disable
it, though, to measure its effect, and maybe to work around compilers
like VC (at least until a better solution comes around).

For the given example, VC uses the memory available for the local
variable Cccont, and the remaining data fits into the reserved stack
and the registers too, avoiding to allocate memory on the stack for the
local variables.  This would probably involve a Csub esp and add
esp, which is likely more lightweight than pushing the Cinterp on the
stack, making the latter probably the better optimization in this case
still.

 [1] well at least for ancient architectures like x86, which don't have 
 register calling convs for parts of the arguments

For Windows there's __fastcall, which would use ECX and EDX for the
first two int or smaller values, but I think it's rarely used

 Great analysis of the problem BTW,
 thanks,
 leo

Many thanks,
Ron

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

2007-07-12 Thread Will Coleda via RT

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

2007-06-18 Thread via RT

# New Ticket Created by  chromatic 
# Please include the string:  [perl #43245]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43245 


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 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 0.
# -2147483648
# oops; not ok: 101  33 gives I 202 vs. P 0.
# -2147483648
# oops; not ok: 101  34 gives I 404 vs. P 0.
# -2147483648
# oops; not ok: 101  35 gives I 808 vs. P 0.
# -2147483648
# oops; not ok: 101  36 gives I 1616 vs. P 0.
# -2147483648
# oops; not ok: 101  37 gives I 3232 vs. P 0.
# -2147483648
# oops; not ok: 101  38 gives I 6464 vs. P 0.
# -2147483648
# oops; not ok: 101  39 gives I 128000128 vs. P 0.
# -2147483648
# oops; not ok: 101  40 gives I 256000256 vs. P 0.
# -2147483648
# oops; not ok: 101  41 gives I 512000512 vs. P 0.
# -2147483648
# oops; not ok: 101  42 gives I 1024001024 vs. P 0.
# -2147483648
# oops; not ok: 101  43 gives I 2048002048 vs. P 0.
# -2147483648
# oops; not ok: 101  44 gives I -198963200 vs. P 0.
# -198963200
# oops; not ok: 101  45 gives I -397926400 vs. P 0.
# -397926400
# oops; not ok: 101  46 gives I -795852800 vs. P 0.
# -795852800
# oops; not ok: 101  47 gives I -1591705600 vs. P 0.
# -1591705600
# oops; not ok: 101  48 gives I 556096 vs. P 0.
# -1591705600
# oops; not ok: 101  49 gives I -2071855104 vs. P 0.
# -2071855104
# oops; not ok: 101  50 gives I 151257088 vs. P 0.
# -2071855104
# oops; not ok: 101  51 gives I 302514176 vs. P 0.
# -2071855104
# oops; not ok: 101  52 gives I 605028352 vs. P 0.
# -2071855104
# oops; not ok: 101  53 gives I 1210056704 vs. P 0.
# -2071855104
# oops; not ok: 101  54 gives I -1874853888 vs. P 0.
# -1874853888
# oops; not ok: 101  55 gives I 545259520 vs. P 0.
# -1874853888
# oops; not ok: 101  56 gives I 1090519040 vs. P 0.
# -1874853888
# oops; not ok: 101  57 gives I -2113929216 vs. P 0.
# -2113929216
# oops; not ok: 101  58 gives I 67108864 vs. P 0.
# -2113929216
# oops; not ok: 101  59 gives I 134217728 vs. P 0.
# -2113929216
# oops; not ok: 101  60 gives I 268435456 vs. P 0.
# -2113929216
# oops; not ok: 101  61 gives I 536870912 vs. P 0.
# -2113929216
# oops; not ok: 101  62 gives I 1073741824 vs. P 0.
# -2113929216
# oops; not ok: 101  64 gives I 101 vs. P 0.
# -2147483648
# oops; not ok: 101  65 gives I 202 vs. P 0.
# -2147483648
# oops; not ok: 101  66 gives I 404 vs. P 0.
# -2147483648
# oops; not ok: 101  67 gives I 808 vs. P 0.
# -2147483648
# oops; not ok: 101  68 gives I 1616 vs. P 0.
# -2147483648
# oops; not ok: 101  69 gives I 3232 vs. P 0.
# -2147483648
# oops; not ok: 101  70 gives I 6464 vs. P 0.
# -2147483648
# oops; not ok: 101  71 gives I 128000128 vs. P 0.
# -2147483648
# oops; not ok: 101  72 gives I 256000256 vs. P 0.
# -2147483648
# oops; not ok: 101  73 gives I 512000512 vs. P 0.
# -2147483648
# oops; not ok: 101  74 gives I 1024001024 vs. P 0.
# -2147483648
# oops; not ok: 101  75 gives I 2048002048 vs. P 0.
# -2147483648
# oops; not ok: 101  76 gives I -198963200 vs. P 0.
# -198963200
# oops; not ok: 101  77 gives I -397926400 vs. P 0.
# -397926400
# oops; not ok: 101  78 gives I -795852800 vs. P 0.
# -795852800
# oops; not ok: 101  79 gives I -1591705600 vs. P 0.
# -1591705600
# oops; not ok: 101  80 gives I 556096 vs. P 0.
# -1591705600
# oops; not ok: 101  81 gives I -2071855104 vs. P 0.
# -2071855104
# oops; not ok: 101  82 gives I 151257088 vs. P 0.
# -2071855104
# oops; not ok: 101  83 gives I 302514176 vs. P 0.
# -2071855104
# oops; not ok: 101  84 gives I 605028352 vs. P 0.
# -2071855104
# oops; not ok: 101  85 gives I 1210056704 vs. P 0.
# -2071855104
# oops; not ok: 101  86 gives I -1874853888 vs. P 0.
# -1874853888
# oops; not ok: 101  87 gives I 545259520 vs. P 0.
# -1874853888
# oops; not ok: 101  88 gives I 1090519040 vs. P 0.
# -1874853888
# oops; not ok: 101  89 gives I -2113929216 vs. P 0.
# -2113929216
# oops; not ok: 101  90 gives I 67108864 vs. P 0.
# -2113929216
# oops; not ok: 101  91 gives I 134217728 vs. P 0.
# -2113929216
# oops; not ok: 101  92 gives I 268435456 vs. P 0.
# -2113929216
# oops; not ok: 101  93 gives I 536870912 vs. P 0.
# -2113929216
# oops; not ok: 101  94 gives I 1073741824 vs. P 0.
# -2113929216
# oops; not ok: 101  96 gives I 101 vs. P 0.
# -2147483648
# oops; not ok: 101  97 gives I 202 vs. P 0.
# -2147483648
# oops; not ok: 101  98 gives

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

2007-06-18 Thread Bob Rogers

   From: chromatic (via RT) [EMAIL PROTECTED]
   Date: Mon, 18 Jun 2007 15:13:15 -0700

   # New Ticket Created by  chromatic 
   # Please include the string:  [perl #43245]
   # in the subject line of all future correspondence about this issue. 
   # URL: http://rt.perl.org/rt3/Ticket/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 it comes to JIT.  (As you may have
guessed.)  It seems that the emit_shift_* routines need to emit code
that does what bit_shift_left would do, but I don't know how yet.  If
TODO-marking is OK for now, then please do so, and I'll work on it ASAP.

-- Bob

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

2007-05-06 Thread Paul Cochrane


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 you wish.  Send questions, comments, complaints, performance
  data, etc to [EMAIL PROTECTED]


possibly it should be exempt from coding standards.


Agreed.  The file has been set exempt from the coding standards in r18434.

Paul

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

2007-05-03 Thread Leopold Toetsch

Am Mittwoch, 2. Mai 2007 21:25 schrieb Yehoshua Sapir:
 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 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/jit/arch/*.c.

See also src/jit/skeleton/jit_emit.h 

leo

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

2007-05-02 Thread Yehoshua Sapir


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 now as I'm moving the function implementations to
a new jit_emit.c, and so I want to remove this.)

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

2007-05-01 Thread Nicholas Clark

 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 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 you wish.  Send questions, comments, complaints, performance
  data, etc to [EMAIL PROTECTED]


possibly it should be exempt from coding standards.

Also, did it have any local modifications?
And why does Parrot needs its own malloc?

Nicholas Clark

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

2007-05-01 Thread Steve Peters

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]
 
 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 you wish.  Send questions, comments, complaints, performance
   data, etc to [EMAIL PROTECTED]
 
 
 possibly it should be exempt from coding standards.
 
 Also, did it have any local modifications?
 And why does Parrot needs its own malloc?
 

According to our file, our version in 2.7.2.  The current free version is
2.8.3.  Obviously, if we need to keep this file, we should get up to the 
most recent version.  I wouldn't however, mess with it much to make it 
pass coding standards, since that would make it much more difficult to 
patch to keep up to date with the original.

Steve Peters
[EMAIL PROTECTED]

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

2007-04-14 Thread chromatic

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/i386/jit_emit.h
   trunk/src/jit/sun4/jit_emit.h
   trunk/t/tools/pmc2c.t

Log:
Added typedef for struct _vtable, then used VTABLE everywhere, as it was 
already available.

Modified: trunk/docs/pdds/draft/pddXX_pmc.pod
==
--- trunk/docs/pdds/draft/pddXX_pmc.pod (original)
+++ trunk/docs/pdds/draft/pddXX_pmc.pod Sat Apr 14 20:31:19 2007
@@ -49,7 +49,7 @@
   +---+
 
   #define THE_PMC \
-struct _vtable* vtable; \
+VTABLE *vtable; \
 UINTVAL flags
 
 An Integer Value PMC could be defined with:

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

2006-12-21 Thread [EMAIL PROTECTED] via RT

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

2006-12-16 Thread [EMAIL PROTECTED] via RT

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, 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 it's in no way  
 relevant to Iterator. It needs to be confirmed or rejected. And if it  
 *is* confirmed, it needs to be added as a test somewhere else.
 
Well, in core.jit I see:

TEMPLATE Parrot_ifunless_x_ic {
 /*
  * FIXME  - the compare prev_op[1] == cur_op[1] should do it
  * dec I1
  * inc I0
  * if I1, boom
  */
if ( P_ARITH  jit_info-prev_op[1] == jit_info-cur_op[1]) {

It's not clear to me from that comment if the text after FIXME explains
that the test does not work or that it was added to do the fix. I
suspect the second - it's the Right Thing to do as far as I can see, and
trying to re-create the bug does not show it up. I swapped those lines
round on the test, and it still passes under -j.

I think maybe this bug is resolved and the FIXME comment should go, but
a comment from someone who's worked on the JIT would be nice.

Jonathan

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

2006-11-10 Thread via RT

# New Ticket Created by  Matt Diephouse 
# Please include the string:  [perl #40802]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40802 


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, 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 it's in no way  
relevant to Iterator. It needs to be confirmed or rejected. And if it  
*is* confirmed, it needs to be added as a test somewhere else.

--
Matt Diephouse

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

2006-11-10 Thread via RT

# 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 to be the
result of Mac system software requiring that the stack be at least 16-byte
aligned at all times.  I can tell this because when running with -j, Parrot
ends up at an invalid instruction fault at this instruction in a Mac system
library:

   movdqa %xmm0, 32(%esp)

Note the a there: Aligned.  There is a movdqu instruction in the CPU,
but the Mac library doesn't use it.

Therefore it's important for the x86 JIT code on Mac to make sure that it
either (1) maintain the stack 16-byte aligned, or (2) leave the stack
unaligned inside the JIT code, but ensure that the stack is aligned at the
point of calling out of the JIT code.
-- 
Chip Salzenberg [EMAIL PROTECTED]

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

2006-08-19 Thread Leopold Toetsch

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 with -S or -C as well. But given 
that 2 threads are changing the same (unprotected?) global, it is not 
surprising that it fails.

leo

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

2006-08-18 Thread via RT

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40200]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40200 


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...
-- 
Chip Salzenberg [EMAIL PROTECTED]

[perl #38593] [TODO] JIT compiler improvements

2006-02-19 Thread via RT

# 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/jit/*/core.jit by expanding some macros and templates, creating JIT 
opcode functions and generating a table of these.

There are several possibilities for improvements, but be warned - some 
are hard(er).

Easy bits:

*) jit2h.pl doesn't create a .h  file - a better util name couldn't harm

*) warn about an attempt to create non-existing opcodes

   I had e.g. defined Parrot_sqrt_n but there is no such opcode sqrt_n 
(it's sqrt_n_n).
   The JIT compiler should emit a warning for such cases

*) tidy perl code - only the visuals - no functional changes

Hard ones:

*) unify macros across architectures and jit/exec

   jit/exec has some differences but not that much as handled inside 
jit2h.pl

*) cleanup jit2h.pl functionality

   the code is a mess with a lot of addons and exceptions

All need testing on ppc and x86 to verify changes with 'make testj'. 
(exec is for sure broken but fixable later).

Thanks,
leo

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

2006-02-19 Thread Joshua Hoblitt

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

--


pgpKmgEPzFvGO.pgp
Description: PGP signature

PIC/JIT update

2006-02-09 Thread Leopold Toetsch


* 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)


$ time ./parrot -Oc -C examples/shootout/ack.pir 9
Ack(3, 9) = 4093

real0m26.173s

$ time ./parrot -Oc -Sj examples/shootout/ack.pir 9
Ack(3, 9) = 4093

real0m0.582s

(-Sj and -Cj are for sure very similar, as the main function doesn't 
much)


leo

[1] integer code only on both platforms

1 2 3 4 5 6 >

1 - 100 of 594 matches

Mail list logo