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

Surprising negative results from 32-bit bit ops when compiling to JS #2725

Closed
madsager opened this issue Apr 25, 2012 · 11 comments
Closed

Surprising negative results from 32-bit bit ops when compiling to JS #2725

madsager opened this issue Apr 25, 2012 · 11 comments
Assignees

Comments

@madsager
Copy link
Contributor

main() {
  var a = [ 0x80 ];
  print(a[0] << 24);
  print(0x80 << 24);
}

yields:

-2147483648
2147483648

The inconsistency is confusing.

Maybe we could generate JS code that yields positive numbers for 32-bit bitops?

@sethladd
Copy link
Contributor

sethladd commented May 1, 2012

Marked this as blocking #210.

@ghost
Copy link

ghost commented May 1, 2012

This surprising result is per "spec", i.e., dart2js and VM differ how left shift and also modulo/remainder are implemented.
I never liked that difference, but heard that it would be slow to implement "correctly" in dart2js. Maybe we can revisit this.


cc @floitschG.

@floitschG
Copy link
Contributor

Modulo/remainder should behave correctly. If not, it's a bug.
I just uploaded a CL that makes all bit-operations positive: https://chromiumcodereview.appspot.com/10343002/
This is still not spec-compliant, but should be less surprising.


Added Started label.

@floitschG
Copy link
Contributor

Closing as fixed (with r7278).
Bit operations still don't follow the spec but at least they shouldn't be surprising anymore.


Added Fixed label.

@rakudrama
Copy link
Member

The surprise for me is not the sign, but that the values differ.

hide(x) => [x][0];
main() {
  var c = 0x81;
  var x = hide(0x81);
  print(c << 30);
  print(x << 30);
  print(0x81 << 30);
}

prints:

138512695296
1073741824
138512695296

Given that the issue is inconsistency between constant folding and evaluation, what was the reasoning behind the decision to change the evaluation (to something less efficient?)
Is there a use case where making the faithful domain [0,2^32) works better than [-2^31,2^31) ?

@floitschG
Copy link
Contributor

The compile-time and runtime differences bug is tracked in issue #2887.

@rakudrama
Copy link
Member

I still get negative results in some cases:

main() {
  int y = ([main][0] == main) ? 0 : 1;
  print( (-1) | y);
}
prints: -1

The generated code appears to have a bug with operator precedence.

  $.print(-1 | y >>> 0);


Added Triaged label.

@floitschG
Copy link
Contributor

Issue #2908 has been merged into this issue.

@kasperl
Copy link

kasperl commented May 8, 2012

It seems like this needs a bit more work to get the precedence right (comment 7).


Set owner to @floitschG.
Added Accepted label.

@floitschG
Copy link
Contributor

Thanks Stephen.
I have uploaded a CL for the precedence bug.
https://chromiumcodereview.appspot.com/10378047/

@floitschG
Copy link
Contributor

Committed with r7414.


Added Fixed label.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants