Signed/unsigned integer difference between compiled and interpreted code

The following code outputs "A".

import Data.Word

x :: Word
x = 10

y :: Word
y = 11

test = case x - y of
         -1 -> "A"
         _  -> "B"
main = putStrLn $ show test

However, adding a new case that isn't matched causes the output to change:

import Data.Word

x :: Word
x = 10

y :: Word
y = 11

test = case x - y of
         5 -> "C"
         -1 -> "A"
         _  -> "B"
main = putStrLn $ show test

With the extra '5 -> "C"' line in the case, the output is "B".

It gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session:

Prelude Main> :l *T.hs
[1 of 1] Compiling Main             ( T.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
"A"
*Main> :l T.hs
Ok, modules loaded: Main.
Prelude Main> main
"B"
Prelude Main>

These examples suggest to me at least 3 improvements:

• Issue a warning when a negative number is used in a case statement in unsigned context
• Interpreted code should give the same result as compiled code
• Adding a case that isn't matched shouldn't change which other patterns get matched

Trac metadata

Trac field	Value
Version	7.8.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system	Windows
Architecture

changed weight to 5

added Tbug Trac import labels

changed weight to 7

Wow, nice catch. Something is wrong with the translation of STG-level case on Word# into Cmm.

Trac metadata

Trac field	Value
Priority	normal → high
Operating system	Windows → Unknown/Multiple

It's not specific to Word# actually. The following program has the same wrong behavior.

x :: Int
x = 11

y :: Int
y = 10

test = case x - y of
         3 -> "D"  -- comment out either of these two lines and output will be "A"
         5 -> "C"
         18446744073709551617 -> "A" -- 2^64 + 1
         _  -> "B"
main = putStrLn $ show test

If I build ghc with -DDEBUG I get panics like

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.9.20140831 for x86_64-unknown-linux):
	ASSERT failed!
    file compiler/basicTypes/Literal.lhs line 222 18446744073709551617

so I suppose the error is really in creating these Literals with out-of-range values.

Some more good stuff.

test = case 1 :: Int of
         18446744073709551617 -> "A" -- 2^64 + 1
         _  -> "B"
main = putStrLn $ show test

prints "B". The KnownBranch optimization fires (even without -O) and thinks that 1 is not 18446744073709551617.

I'm inclined to conclude that Core Literals should always be wrapped to the range of integers that their type can represent. I assume that HsLits should hold the actual integer in the source program, though, so we can display expressions as the user wrote them. Simon, any thoughts?

Also, there is no warning about the out-of-range literal patterns in any of these programs. Perhaps that ought to be a separate feature request ticket.

mentioned in issue #10245 (closed)

mentioned in issue #10246 (closed)

Also see #10246 (closed), which is basically the same, it seems.

I created #13256 (closed) and #13257 for the suggestion of "Issue a warning when a negative number is used in a case statement in unsigned context".

mentioned in commit 6dfc5ebf

closed

changed milestone to %8.2.1

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added incorrect runtime result label

added Phigh label