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

Closed
mratsim opened this issue Nov 8, 2019 · 5 comments

Comments

@mratsim
Copy link
Member

@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

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

type
  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)
@narimiran

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 = a.int shr 16 and 0xff
  var g = a.int shr 8 and 0xff
  var b = a.int 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 = (a.int and 0xff0000) shr 16
  var g = (a.int and 0x00ff00) shr 8
  var b = (a.int 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).

@jangko

This comment has been minimized.

Copy link
Contributor

@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.

@narimiran

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.

@stefantalpalaru

This comment has been minimized.

Copy link
Contributor

@stefantalpalaru stefantalpalaru commented Nov 10, 2019

runnableExamples are extracted in separate files and compiled: https://github.com/nim-lang/Nim/blob/a4d43d7d0c8ef245e0f50732119f666965b322a8/compiler/docgen.nim#L398

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

@mratsim

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

DeepinScreenshot_select-area_20191112124325

@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
Projects
None yet
4 participants
You can’t perform that action at this time.