From @skids

Per spec Int should emulate 2's complement storage with infinitely extended
sign bit.

For example, these results are not correct​:

# perl6 -e 'say -0x800000000000001 +| 0;'
576460752303423487
# perl6 -e 'say -5 +& -2'
0

The current nqp bitops routines implement this incorrectly for bitwise
operations when both operands are negative, only implementing
2's-complement emulation for cases when one operand is negative.

Also, when simultaneously inverting and growing a 1's complement negative
integer, new MP_DIGITS should be set to all ones. Instead, there is
off-end-of-array access possible with the current implementation.
The grow_and_negate subroutine of nqp's nqp_bigint.ops may
attempt read access past the end of argument *a's valid data when the
argument *b has more used MP_DIGITS.

Finally, current code may produce incorrect results when operations
involve large negative values who's one's-complement representation fits
directly on an MP_DIGIT boundary, because it uses the high bit in the
result to determine its sign, while there is no guarantee that either
operand will have a correct sign bit in this position. This guarantee
must be met for proper emulation of sign bits under bitops.

A suggested fix is at https://gist.github.com/4187527

Tests​:
is (-5 +& -2),(-6), "logical AND of two negative Int is twos complement";
is (-7 +| -6),(-5), "logical OR of two negative Int is twos complement";
is (-7 +^ -6),( 3), "logical XOR of two negative Int is twos complement";
is ({ my $b; eval("$b = -0b1" ~ (0 x $_) ~ "1;"); sign($b +| 0) } for ^129),
  (-1 xx 128), "logical OR correctly handles sign across size sweep";

From @masak

<skids> r​: 0x0123456789abcdef.perl.say
<camelia> rakudo-moar 1a28ed​: OUTPUT«81985529216486896␤»
<camelia> ..rakudo-{parrot,jvm} 1a28ed​: OUTPUT«81985529216486895␤»
<skids> r-m's bitops are even more hosed than r-p.
<masak> skids​: is that one rakudobug-submitted?
* masak submits rakudobug

That Moar is wrong here can clearly be seen because the literal is odd
but the output is even.

From @coke

Recent failure, parrot only

  # Negative numbers. These really need more tests for bigint vs sized natives
  is (-5 +& -2),(-6), "logical AND of two negative Int is twos complement";
  is (-7 +| -6),(-5), "logical OR of two negative Int is twos complement";
  is (-7 +^ -6),( 3), "logical XOR of two negative Int is twos complement";

now failing with​:

not ok 9 - logical AND of two negative Int is twos complement
# got​: '0'
# expected​: '-6'
not ok 10 - logical OR of two negative Int is twos complement
# got​: '-7'
# expected​: '-5'
not ok 11 - logical XOR of two negative Int is twos complement
# got​: '-1'
# expected​: '3'

--
Will "Coke" Coleda

From @FROGGS

Fixed in Raku/nqp@34bd42590c

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

From @usev6

Well, things look better today (results are identical on Moar, Parrot and JVM)​:

$ perl6 -e 'say -5 +& -2'
-6

$ perl6 -e '0x0123456789abcdef.perl.say'
81985529216486895

$ perl6 -e 'say -0x800000000000001 +| 0;'
-576460752303423489

Also there were some tests added to S03-operators/bit.t (Raku/roast@5313c52b38 and Raku/roast@7896054a35).

So my question​: Do we need more tests or can this ticket be closed?

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

From @skids

This is pretty much fixed and tested for, so closing.

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