Incorrect results with uint32 types after +> was made to handle large ints

[p6rt]

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

Searchable as RT131306$

[p6rt]

From @zoffixznet

Before ef29bb9f41aa5d[^1], the +> op special cased large shifts and large numbers. Now that special-casing was removed,
it works fine in the first few runs, but then starts giving incorrect results (setting MVM_SPESH_DISABLE fixes the issue).

I couldn't repro it with *just* the `+>` op, but only in this combination​:

<Zoffix_> c​: ef29bb9f41aa5d sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
<committable6> Zoffix_, ¦ef29bb9​: «27071659120799␤27071659114496»
<Zoffix_> c​: ef29bb9f41aa5d1 sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
<committable6> Zoffix_, ¦ef29bb9f41aa5d1​: «27071659120799␤27071659120799»

[1] rakudo/rakudo@ef29bb9f41aa5d

[p6rt]

From @zoffixznet

Worth noting Rakudo change wasn't the only change. The actual fix was in MoarVM​:
MoarVM/MoarVM@362277b

[p6rt]

From @zoffixznet

https://irclog.perlgeek.de/perl6-dev/2017-05-13#i_14576494

[p6rt]

From @zoffixznet

Seems <+ is actually (or also) affected

[p6rt]

From @zoffixznet

More detective work (for a couple of screens)​: https://irclog.perlgeek.de/moarvm/2017-05-19#i_14608978

[p6rt]

From @zoffixznet

On Sat, 13 May 2017 07​:26​:05 -0700, cpan@​zoffix.com wrote​:

Before ef29bb9f41aa5d[^1], the +> op special cased large shifts and
large numbers. Now that special-casing was removed,
it works fine in the first few runs, but then starts giving incorrect
results (setting MVM_SPESH_DISABLE fixes the issue).

I couldn't repro it with *just* the `+>` op, but only in this
combination​:

<Zoffix_> c​: ef29bb9f41aa5d sub rotr(uint32 $n, uint32 $b) { $n +> $b
+| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x =
rotr 1652322944, 18 }; say $x
<committable6> Zoffix_, ¦ef29bb9​: «27071659120799␤27071659114496»
<Zoffix_> c​: ef29bb9f41aa5d1 sub rotr(uint32 $n, uint32 $b) { $n +>
$b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 {
$x = rotr 1652322944, 18 }; say $x
<committable6> Zoffix_, ¦ef29bb9f41aa5d1​:
«27071659120799␤27071659120799»

[1] rakudo/rakudo@ef29bb9f41aa5d

I added a temporary workaround[^1] as well as tests[^2] to cover this bug.

The issue still needs proper addressing as the workaround merely prevents inlining of +< and +> ops

[1] rakudo/rakudo@2f22b70
[2] Raku/roast@c1d62112f3

[p6rt]

From @zoffixznet

jnthn │ A while back I think we had to comment out (or similar) some native candidates because of a spesh bug. There's a chance it was what I just fixed in MoarVM/MoarVM@3f33a8419b

[p6rt]

From @zoffixznet

Issue appears to have been fixed. Kludge removed in rakudo/rakudo@d9f51da

[p6rt]

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