Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Bytecode validation error at offset ..., instrucction ..., operand type 160 does not match register type 152" #5207

Closed
p6rt opened this issue Apr 1, 2016 · 8 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Apr 1, 2016

Migrated from rt.perl.org#127813 (status was 'resolved')

Searchable as RT127813$

@p6rt
Copy link
Author

p6rt commented Apr 1, 2016

From @salortiz

In code like​:

class Foo is repr('CPointer') {
  ...
  method Bar(​:named, :named2, uint32 :mode) {
  ...
  }
  ...

Calling Bar, at runtime is produced the error in the subject. The offset and the instruction varies, but removing
the 'uint32' constraint fixes that.

@p6rt
Copy link
Author

p6rt commented Apr 1, 2016

From @salortiz

Minimal case​:

<sortiz> m​: sub Foo(uint32 :$bar) { say $bar }; Foo(​:bar(4)); # btw NativeCall not needed.
<camelia> rakudo-moar ae43ba​: OUTPUT«Bytecode validation error at offset 40, instruction 6​:␤operand type 160 does not match register type 152␤ in block <unit> at /tmp/5nZ_TgBdbq line 1␤␤»
<sortiz> jnthn, minimal golf ^^^
<jnthn> sortiz​: Thanks; please drop it into the RT :)

@p6rt
Copy link
Author

p6rt commented Jul 10, 2016

From @zoffixznet

Still present in rakudo 405519​:

<Zoffix> m​: sub Foo(uint32 :$bar) { say $bar }; Foo(​:bar(4));
<camelia> rakudo-moar 405519​: OUTPUT«Bytecode validation error at offset 40, instruction 6​:␤operand type 160 does not match register type 152␤ in block <unit> at <tmp> line 1␤␤»

@p6rt
Copy link
Author

p6rt commented Jul 20, 2016

From @zoffixznet

Still present in rakudo 59d808.

jnthn++ offered some ideas on this bug​: http://irclog.perlgeek.de/perl6-dev/2016-07-20#i_12876973 estimating it may be somewhere here​: https://github.com/perl6/nqp/blob/0dde6991893c7c40d486b681a7ac3bb2a22c7075/src/vm/moar/QAST/QASTCompilerMAST.nqp#L1121

♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁

TODO-fudged tests added in Raku/roast@ea4d11d008

🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁🏁
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥

--
Cheers,
ZZ | https://twitter.com/zoffix

@p6rt
Copy link
Author

p6rt commented Jul 20, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Dec 16, 2017

From @usev6

This works now as expected​:

<bartolin> m​: sub Foo(uint32 :$bar) { say $bar }; Foo(​:bar(4))
<camelia> rakudo-moar ae6177ca2​: OUTPUT​: «4␤»

I think, it was fixed with Raku/nqp@fc727ea911 (bisectable pointed to the corresponding NQP bump).

Since the tests in S02-types/native.t are passing, I'm closing this ticket as 'resolved'.

1 similar comment
@p6rt
Copy link
Author

p6rt commented Dec 16, 2017

From @usev6

This works now as expected​:

<bartolin> m​: sub Foo(uint32 :$bar) { say $bar }; Foo(​:bar(4))
<camelia> rakudo-moar ae6177ca2​: OUTPUT​: «4␤»

I think, it was fixed with Raku/nqp@fc727ea911 (bisectable pointed to the corresponding NQP bump).

Since the tests in S02-types/native.t are passing, I'm closing this ticket as 'resolved'.

@p6rt
Copy link
Author

p6rt commented Dec 16, 2017

@usev6 - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Dec 16, 2017
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant