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

Unsigned 64b shl does not work for values above 32 #3123

Closed
Wh1teDuke opened this issue Jul 15, 2015 · 10 comments
Closed

Unsigned 64b shl does not work for values above 32 #3123

Wh1teDuke opened this issue Jul 15, 2015 · 10 comments

Comments

@Wh1teDuke
Copy link
Contributor

let i: uint64 = 1 shl 50

equals to 0. Declaring 1 and 50 as uint64 does not affect the result.


nim -v

Nim Compiler Version 0.11.3 (2015-07-15) [Windows: i386]
Copyright (c) 2006-2015 by Andreas Rumpf

git hash: 6c8e9da9ee8173091931980b64aa21a839fc1424
@Wh1teDuke Wh1teDuke changed the title Unsigned shl does not work Unsigned 64b shl does not work Jul 15, 2015
@Wh1teDuke Wh1teDuke changed the title Unsigned 64b shl does not work Unsigned 64b shl does not work for values above 32 bits Jul 15, 2015
@Wh1teDuke Wh1teDuke changed the title Unsigned 64b shl does not work for values above 32 bits Unsigned 64b shl does not work for values above 32 Jul 15, 2015
@Araq
Copy link
Member

Araq commented Jul 15, 2015

Produces 1125899906842624 for me.

@Wh1teDuke
Copy link
Contributor Author

What exactly do you need? i'm under winXP 32b. Still getting the same result (in case you were wondering if i typed it wrongly):

let a: uint64 = 1 shl 31
let b: uint64 = 1 shl 50
echo a        # outputs: 2147483648
echo b        # outputs: 0

(could be somewhat related to #3028)

@Araq
Copy link
Member

Araq commented Jul 15, 2015

I'm on Windows 7, 32 bit. Maybe you use a different GCC version?

@matkuki
Copy link
Contributor

matkuki commented Jul 15, 2015

Tried on Windows XP 32-bit, I get the same result as Abrasax!
Nim: 0.11.3 (2015-07-15)
gcc: i686-win32-dwarf-rev1, Built by MinGW-W64 project, 4.9.1 (installs with the Nim installer)

@Wh1teDuke
Copy link
Contributor Author

gcc -v:
gcc version 5.1.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

@Wh1teDuke
Copy link
Contributor Author

proc foo =
  var
   a: uint64 = 1
   b: uint64 = 50
  let i: uint64 = a shl b
  assert i != 0
  echo i

foo()

Here, the assertion doesn't fail, but echo outputs 0. My former snippet does not pass the assertion

On the other hand, let i: uint64 = 1 shl 50 generates this c code: i_93005 = 0ULL;
whereas let a: uint64 = 1 shl 31: a_93004 = 2147483648ULL;

@Araq
Copy link
Member

Araq commented Jul 16, 2015

I use GCC version 4.8.1. Maybe that's the reason?

@ReneSac
Copy link
Contributor

ReneSac commented Jul 16, 2015

For me it is working fine on Linux 64bit. GCC 4.9.1 here. Per last Abrasax- comment, it don't seems a GCC problem if the generated C code already has i_93005 = 0ULL; in it. For me it generates properly b_92056 = 1125899906842624ULL;

When I try to cross-compile a 32bit binary with nim c --cpu:i386 --passC:-m32 --passL:-m32 --parallelBuild:1 test.nim I get the error:

/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory
 #  include <sys/cdefs.h>

So I could not test it.

@matkuki
Copy link
Contributor

matkuki commented Jul 25, 2015

Araq:
Just tried GCC-4.8.1 on Windows XP 32-bit with the code:

let i: uint64 = 1 shl 50
echo i

It echoes 0 , same as GCC-4.9.1, which I used last time.

@Wh1teDuke
Copy link
Contributor Author

@Araq i don't have this problem anymore. May i close it?

>nim -v
Nim Compiler Version 0.12.0 (2015-10-28) [Windows: i386]
Copyright (c) 2006-2015 by Andreas Rumpf

git hash: 22a702868bfd242ff76bf86ea00a278f979a112e
active boot switches: -d:release

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

4 participants