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

Numerous problems with bigint bitops #2987

Closed
p6rt opened this issue Dec 2, 2012 · 10 comments
Closed

Numerous problems with bigint bitops #2987

p6rt opened this issue Dec 2, 2012 · 10 comments

Comments

@p6rt
Copy link

p6rt commented Dec 2, 2012

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

Searchable as RT115966$

@p6rt
Copy link
Author

p6rt commented Dec 2, 2012

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";

@p6rt
Copy link
Author

p6rt commented May 7, 2014

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.

@p6rt
Copy link
Author

p6rt commented Jul 17, 2014

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

@p6rt
Copy link
Author

p6rt commented Sep 23, 2014

From @FROGGS

Fixed in Raku/nqp@34bd42590c

@p6rt
Copy link
Author

p6rt commented Sep 23, 2014

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

@p6rt
Copy link
Author

p6rt commented Oct 21, 2014

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?

1 similar comment
@p6rt
Copy link
Author

p6rt commented Oct 21, 2014

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?

@p6rt
Copy link
Author

p6rt commented Oct 21, 2014

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

@p6rt
Copy link
Author

p6rt commented Feb 6, 2015

From @skids

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

@p6rt
Copy link
Author

p6rt commented Feb 6, 2015

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

@p6rt p6rt closed this as completed Feb 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant