# New Ticket Created by Elizabeth Mattijsen # Please include the string: [perl #122783] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=122783 >
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...
