From @lizmat

10​:43​:13] <dwarring> I've bisected parrot failures affecting advent2010-07.t and other advent tests...
[10​:43​:55] <dwarring> (test suite had been out of action on parrot for about a week)
[10​:44​:43] <FROGGS> dwarring​: and?
[10​:44​:52] <dwarring> looks like this test started hanging around rakudo commit 3e96fe51a29fd3758fe774b5e3e95aae9e7196dd
[10​:44​:55] <FROGGS> dwarring​: I am about checking panda on parrot again
[10​:45​:31] <FROGGS> dwarring​: yes, that seems also to be the panda problem
[10​:45​:51] <lizmat> dwarring​: going to check that now
[10​:45​:58] <lizmat> (as that commit was my doing)
[10​:46​:25] <dwarring> there's also a second regression at df2f8b4954477f02f2481f981a7d7c564a959544
[10​:47​:01] <dwarring> hoping this gist explains things a bit more - https://gist.github.com/dwarring/12c1e32440a8aea43337
[10​:47​:12] <dwarring> (see comments)
[10​:48​:21] <lizmat> dwarring​: I'm on it
[11​:26​:38] <lizmat> looks like parrot has a problem with basic math
[11​:26​:46] <lizmat> 1 + 1 + 0 = 0
[11​:32​:41] <lizmat> more specifically​: $moving = $chars + 1 + nqp​::eqat($ns, $CRLF, $nextpos);
[11​:33​:09] <lizmat> seems to come out as 0 always on parrot
[11​:36​:08] <FROGGS> lizmat​: what is the test case you're using?
[11​:36​:27] <lizmat> say "a\r\nb\nc\n".lines.elems
[11​:36​:33] <FROGGS> k
[11​:37​:10] <lizmat> that hangs on parrot atm
[11​:37​:40] <lizmat> if I put the result of nqp​::eqat in a temp variable, it works ok
[11​:38​:42] <lizmat> something like my int $extra = nqp​::eqat; $moving = $chars + 1 + extra;
[11​:39​:32] <lizmat> some code gen, maybe optimization issue ?
[11​:40​:16] <FROGGS> I would say that a code-gen bug on parrot is very unlikely
[11​:40​:45] <FROGGS> and we cannot change the optimization level for perl6-p because some stuff relies on optimization and will break without
[11​:46​:57] <FROGGS> p​: say nqp​::eqat(nqp​::unbox_s("foo\r\nbar"), nqp​::unbox_s("\r\n"), 3)
[11​:46​:59] <+camelia> rakudo-parrot 351c12​: OUTPUT«1␤»
[11​:47​:03] <FROGGS> p​: say 0 + nqp​::eqat(nqp​::unbox_s("foo\r\nbar"), nqp​::unbox_s("\r\n"), 3)
[11​:47​:04] <+camelia> rakudo-parrot 351c12​: OUTPUT«1␤»
[11​:47​:17] <FROGGS> p​: say 0 + 1 + nqp​::eqat(nqp​::unbox_s("foo\r\nbar"), nqp​::unbox_s("\r\n"), 4)
[11​:47​:18] <+camelia> rakudo-parrot 351c12​: OUTPUT«1␤»
[11​:47​:39] <FROGGS> why does that work here?
[11​:48​:11] <lizmat> because you're not using variables?
[11​:48​:36] <pmurias> lizmat​: reducing the bug to an nqp level test that we could put into the nqp test suit would be great
[11​:48​:45] <FROGGS> then it might be really a code-gen bug
[11​:49​:05] <FROGGS> it could be that eqat uses a hard coded register
[11​:49​:10] <FROGGS> lemme look
[11​:49​:13] <lizmat> but one that exists on parrot only
[11​:49​:22] <lizmat> jvm is also clean, I just checked
[11​:49​:25] <FROGGS> lizmat​: code-gen is backend specific
[11​:52​:45] <pmurias> all the code-gen in jvm, moar, parrot is a very similiar manner
[11​:59​:36] <FROGGS> p​: my str $CRLF = nqp​::unbox_s("\r\n"); my int $chars; say $chars + 1 + nqp​::eqat(nqp​::unbox_s("a\r\nb"), $CRLF, 0) # here is the bug
[11​:59​:37] <+camelia> rakudo-parrot 351c12​: OUTPUT«0␤»
[12​:01​:08] <FROGGS> it vanishes when I make $chars an Int, and also when I replace nqp​::eqat by a literal 0
[12​:02​:45] anaeem1 (~anaeem1@​119.154.219.52) joined the channel.
[12​:05​:12] <lizmat> shall I rakudobug it ?
[12​:05​:42] <FROGGS> yes...

From @lizmat

some more datapoints​:

12​:14​:52] <FROGGS> eww​:
[12​:14​:59] <FROGGS> p​: sub infix​:<+>(int $a, int $b) { nqp​::add_i($a, $b) }; my int $chars; say $chars + 1 + nqp​::eqat(nqp​::unbox_s("a"), nqp​::unbox_s("b"), 0)
[12​:15​:00] <+camelia> rakudo-parrot 351c12​: OUTPUT«0␤»
[12​:15​:05] <FROGGS> p​: sub infix​:<+>(int $a, int $b) { 7; nqp​::add_i($a, $b) }; my int $chars; say $chars + 1 + nqp​::eqat(nqp​::unbox_s("a"), nqp​::unbox_s("b"), 0)
[12​:15​:07] <+camelia> rakudo-parrot 351c12​: OUTPUT«1␤»
[12​:15​:36] <FROGGS> I guess it is an optimization problem with infix​:<+> on natives

From @lizmat

still more datapoints, FROGGS++

[09​:59​:17] <FROGGS> p​: my int $chars; say $chars + 1 + nqp​::add_i(0,0)
[09​:59​:22] <+camelia> rakudo-parrot de1626​: OUTPUT«0␤»
[09​:59​:24] <FROGGS> p​: my int $chars; say $chars + 1 + nqp​::add_i(0,1)
[09​:59​:26] <+camelia> rakudo-parrot de1626​: OUTPUT«2␤»
[09​:59​:35] <FROGGS> *g*
[09​:59​:40] <FROGGS> that's just insane
[10​:01​:38] <lizmat> so it's for all nqp​:: ops this happens ?
[10​:01​:51] <FROGGS> for all native ops
[10​:02​:17] <FROGGS> there is an optimization that gets applied in case the return value is a native... I bet that triggers it
[10​:02​:33] <FROGGS> p​: my int $chars; say $chars + 1 + nqp​::add_I(0,1, Int)
[10​:02​:34] <+camelia> rakudo-parrot de1626​: OUTPUT«2␤»
[10​:02​:38] <FROGGS> p​: my int $chars; say $chars + 1 + nqp​::add_I(0,0, Int)
[10​:02​:39] <+camelia> rakudo-parrot de1626​: OUTPUT«1␤»
[10​:02​:47] <FROGGS> yeah, that might be it
[10​:03​:26] <lizmat> seems so​:
[10​:03​:26] <lizmat> $ perl6-p --optimize=0 -e 'my int $chars; say $chars + 1 + nqp​::add_i(0,0)'
[10​:03​:26] <lizmat> 1
[10​:03​:54] <lizmat> $ perl6-p --optimize=2 -e 'my int $chars; say $chars + 1 + nqp​::add_i(0,0)'
[10​:03​:54] <lizmat> 0
[10​:03​:59] <lizmat> optimize=1 is also ok
[10​:04​:03] <FROGGS> ohh, good to know :o)
[10​:04​:20] lizmat adds this to the ticket

From @FROGGS

Fix​: rakudo/rakudo@e1ae1db000

@FROGGS - Status changed from 'new' to 'resolved'