Arithmetic tests are expecting the wrong result. VM int32, int64, uint64 evaluation does not match runtime.

[genotrance]

Test in tarithm.nim fails on armv6 and armv7 but passes on arm64.

https://github.com/nim-lang/Nim/blob/devel/tests/arithm/tarithm.nim#L129

Expected value is 1 but actual is 0. Tested 1 << 32 on a real RPi and it is 0 there as well. Seems like the test needs to be updated.

[mratsim]

The tests are completely wrong and linked to VM bug #9572.

Forcing runtime evaluation, we should get all 0:

proc doShl(T: typedesc[SomeSignedInt], shift: int): T =
    1.T shl shift

block:
  let t0 = doShl(int8, 8)
  let t1 = doShl(int16, 16)
  let t2 = doShl(int32, 32)
  let t3 = doShl(int64, 64)
  echo t0
  echo t1
  echo t2
  echo t3

Merely using a let instead of const won't work because Nim still compute 1 shl 32 at compile-time and inlines it.

Edit:

Unsigned u64 is wrong as well and showstopper for bigint library that want to do compile-time shifts like Stint

Nim/tests/arithm/tarithm.nim

Lines 132 to 141 in 3d0190f

	# Unsigned types
	block:
	const t0: uint8 = 1'u8 shl 8
	const t1: uint16 = 1'u16 shl 16
	const t2: uint32 = 1'u32 shl 32
	const t3: uint64 = 1'u64 shl 64
	doAssert t0 == 0
	doAssert t1 == 0
	doAssert t2 == 0
	doAssert t3 == 1

Edit 2:
Changed the title to make it clear that the issue is not the ARM target but Nim VM and the tests that are incorrect.

[krux02]

To be honest, I don't understand these tests. Bitshifting these amount of bits in C is undefined behavior. Since the shl is basically a wrapper for the C bitshifting operator, I don't get why these tests have been written in this way. Neither do I understand the logic behind them, nor do I have any clue on how we can ensure these results in the future.

[Araq]

Maybe because Nim is not C and it's defined behavior in Nim? Wasn't that hard to figure it out, was it...

[genotrance]

Well the results are inconsistent and blocking megatest on arm nightlies. Please suggest a fix - either when arm or removing these overflow bit-shift tests altogether.

[jangko]

Looks like the behavior is architecture dependent, see: stackoverflow.

If that is the case, the tests are tied to specific architecture.

If we want to make VM and runtime produce the same result, we should not let it have undefined behavior as in C, but should define the behavior for both VM and runtime in case of shift overflow.

[krux02]

The tests in discussion have been removed by new, because they were incorrect.