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

Nim 1.0 backports branch - Test the following #99

mratsim opened this issue Nov 8, 2019 · 5 comments


Copy link

@mratsim mratsim commented Nov 8, 2019

cc @narimiran apparently the following (related to shr and bitand) fails on 32-bit:
->> To be tested

import colors

  a = Color(0xff_00_ff)
  b = Color(0x00_ff_cc)

  Col = range[0..255]

assert extractRGB(a) == (r: 255.Col, g: 0.Col, b: 255.Col)
assert extractRGB(b) == (r: 0.Col, g: 255.Col, b: 204.Col)

This comment has been minimized.

Copy link

@narimiran narimiran commented Nov 8, 2019

This is a part of lib/pure/colors.nim, and it is one of runnableExamples there. You can run all the examples by nim doc lib/pure/colors.nim.

The strange thing about it is that it works fine on 64-bit OS-es and in Nim's devel branch, but it keeps failing on version-1-0 branch only on 32-bit OS.
On the other hand, @SolitudeSF has tested it on 32-bit Raspberry Pi with Nim v1.0.2, and there was no problem with it.

My first suspicion are the following templates there:

template extract(a: Color, r, g, b: untyped) =
  var r = shr 16 and 0xff
  var g = shr 8 and 0xff
  var b = and 0xff

template rawRGB(r, g, b: int): Color =
  Color(r shl 16 or g shl 8 or b)

template colorOp(op): Color =
  extract(a, ar, ag, ab)
  extract(b, br, bg, bb)
  rawRGB(op(ar, br), op(ag, bg), op(ab, bb))

I've tried to refactor them a bit, just to see if there's some shr problem, e.g.:

template extract(a: Color, r, g, b: untyped) =
  var r = ( and 0xff0000) shr 16
  var g = ( and 0x00ff00) shr 8
  var b = ( and 0x0000ff)

template rawRGB(r, g, b: int): Color =
  Color(((r and 0xff) shl 16) or
        ((g and 0xff) shl 8) or
         (b and 0xff))

but Travis reported the same assert failing again. extractRGB(a) instead of producing (255, 0, 255), gave: (0, 0, 0).


This comment has been minimized.

Copy link

@jangko jangko commented Nov 9, 2019

perhaps related to #93. At that time I thought it only affected compile time shl/shr. turn out runtime also suffer from this similar problem. looks like the type requirement of the operand become stricter.
Nim compiler should have it's own basic arithmetic and logic test. If this keep going on like this, nim-stint will become Nim-math baby sitter.


This comment has been minimized.

Copy link

@narimiran narimiran commented Nov 10, 2019

I've made several potential fixes trying to see what exactly breaks, and the conclusion is:

The fails happen only when inside of runnableExamples!! Putting the same code in when isMainModule block doesn't produce the buggy behaviour.


This comment has been minimized.

Copy link

@stefantalpalaru stefantalpalaru commented Nov 10, 2019

runnableExamples are extracted in separate files and compiled:

Could the difference come from configuration files that apply to them? i.e.: if they're extracted from "foo.nim", they're no longer subjected to "foo.nim.cfg".


This comment has been minimized.

Copy link
Member Author

@mratsim mratsim commented Nov 12, 2019

Works for me on this commit: nim-lang/Nim@e2aa1d6


@mratsim mratsim closed this Nov 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.