November 2018 - ghc-tickets

[GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian
by GHC 22 Nov '18

22 Nov '18

#15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce on a Mac: {{{ $ ./hadrian/build.sh -c -j "binary-dist" <snip> Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: binary-dist * Raised the exception: user error (Development.Shake.cmd, system command failed Command: cp -r _D5316/stage1/lib/x86_64-darwin- ghc-8.7.20181119/rts-1.0/include _D5316/bindist/ghc-8.7.20181119-x86_64 -apple-darwin Exit code: 1 Stderr: cp: _D5316/stage1/lib/x86_64-darwin-ghc-8.7.20181119/rts-1.0/include: No such file or directory ) }}} There is an `_D5316/stage1/lib/x86_64-osx- ghc-8.7.20181119/rts-1.0/include` folder though (note the `darwin`/`osx` difference)... At a glance, I think this is a case of Cabal having a different naming convention then Hadrian's `HostOs` (I'm pretty sure that the folders in `lib` are created by Cabal using its internal convention). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15671: Link errors due to forcibly exporting findPtr
by GHC 22 Nov '18

22 Nov '18

#15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: T10955dyn | Blocked By: T10955 | Blocking: | Related Tickets: Differential Rev(s): Phab:D5138 | Wiki Page: -------------------------------------+------------------------------------- The change in https://phabricator.haskell.org/rGHC900c47f88784b91517c00be3e1087322e62f698e is causing link errors due to the combination of `-Wl,-u` and `-Wl ,--export-all-symbols` {{{ Wrong exit code for T10955dyn()(expected 0 , actual 2 ) Stderr ( T10955dyn ): E:/ghc- dev/msys64/home/Tamar/ghc/rts/dist/build/libHSrts_thr.a(Printer.thr_o): In function `findPtr': E:\ghc-dev\msys64\home\Tamar\ghc/rts/Printer.c:880: multiple definition of `findPtr' ./bin_dyn/libA.dll.a(d020776.o):(.text+0x0): first defined here }}} I believe the correct solution is to just use a cabal flag to emulate the setup we had with make, instead of forcing this symbol always. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15856: GhostScript not available for hp2ps tests
by GHC 22 Nov '18

22 Nov '18

#15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Keywords: ghostscript | Operating System: Linux gs hp2ps testsuite | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: T7919 T14761c | Blocked By: Blocking: | Related Tickets: #15736 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`. I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that). The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated. There are probably 2 ways forward: - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable - figuring out why the python script fails to understand that a ghostscript is actually present and fixing that -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition)
by GHC 22 Nov '18

22 Nov '18

#8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- == Abstract == Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6 Below is more detailed description of the problem: == The idea == I'm writing a [DSL][1], which compiles to Haskell. Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure. For example, user can write (in "pythonic" pseudocode): {{{#!python data Vector a: x,y,z :: a def method1(self, x): return x }}} (which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption): {{{#!python data Vector a: x,y,z :: a def Vector.method1(self, x): return x }}} In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type). I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time. == The problem == I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7. I want to ask you how can I fix it to make it working in the new version of the compiler? == Example code == Lets see a simplified version of generated (by my compiler) Haskell code: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ -- data types ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) -- the Vector_testid is used as wrapper over a function "testid". newtype Vector_testid a = Vector_testid a ------------------------------ -- sample function, which is associated to data type Vector ------------------------------ testid (v :: Vector a) x = x ------------------------------ -- problematic function (described later) ------------------------------ testx x = call (method1 x) $ OneTuple "test" ------------------------------ -- type classes ------------------------------ -- type class used to access "method1" associated function class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func -- simplified version of type class used to "evaluate" functions based on -- their input. For example: passing empty tuple as first argument of `call` -- indicates evaluating function with default arguments (in this example -- the mechanism of getting default arguments is not available) class Call a b where call :: a -> b ------------------------------ -- type classes instances ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where method1 = (Vector_testid . testid) instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where call (Vector_testid val) = val ------------------------------ -- example usage ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) -- following lines equals to a pseudocode of ` v.method1 "test" ` -- OneTuple is used to indicate, that we are passing single element. -- In case of more or less elements, ordinary tuples would be used. print $ call (method1 v) $ OneTuple "test" print $ testx v }}} The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error: {{{ debug.hs:61:10: Illegal instance declaration for ‛Method1 (Vector a) Vector_testid out’ The liberal coverage condition fails in class ‛Method1’ for functional dependency: ‛cls -> func’ Reason: lhs type ‛Vector a’ does not determine rhs type ‛out’ In the instance declaration for ‛Method1 (Vector a) Vector_testid out’ }}} The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`) == Some attemps to fix the problem == I was trying to overcome this problem by changing the definition of `Method1` to: {{{#!haskell class Method1 cls m func | cls -> m where method1 :: cls -> m func }}} Which resolves the problem with functional dependencies, but then the line: {{{#!haskell testx x = call (method1 x) $ OneTuple "test" }}} is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions): {{{ Could not deduce (Method1 cls m func0) arising from the ambiguity check for ‛testx’ from the context (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) bound by the inferred type for ‛testx’: (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s at debug.hs:50:1-44 The type variable ‛func0’ is ambiguous When checking that ‛testx’ has the inferred type ‛forall cls (m :: * -> *) func s. (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s’ Probable cause: the inferred type is ambiguous }}} It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar): {{{#!haskell class Method1 cls m | cls -> m where type Func cls method1 :: cls -> m (Func cls) instance Method1 (Vector a) Vector_testid where type Func (Vector a) = (t1->t1) method1 = (Vector_testid . testid) }}} We would get obvious error `Not in scope: type variable ‛t1’`, because type families does not allow to use types, which does not appear on LHS of type expression. == The final question == How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version. (without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell) Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations? There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition- introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6 [1]: http://en.wikipedia.org/wiki/Domain-specific_language -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 71

[GHC] #15933: Wrong size for int for callbacks into Haskell from foreign code
by GHC 22 Nov '18

22 Nov '18

#15933: Wrong size for int for callbacks into Haskell from foreign code -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 (FFI) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code produces different results on amd64 (64-bit little endian) and s390x (64-bit big endian). `foo.h:` {{{#!c typedef void(*hs_callback)(int x); extern void function_in_c(hs_callback cb); }}} `foo.c:` {{{#!c #include "foo.h" void function_in_c(hs_callback cb) { int x = 10; cb(x); } }}} `Foo.hs:` {{{#!hs module Main(main) where import Foreign import Foreign.C type HsCallback = CInt -> IO () foreign import ccall "foo.h function_in_c" functionInC :: FunPtr HsCallback -> IO () foreign import ccall "wrapper" wrap :: HsCallback -> IO (FunPtr HsCallback) main = do f <- wrap $ \x -> print x functionInC f freeHaskellFunPtr f }}} On amd64 the output is 10, but on s390x is 0. On both machines, `sizeOf (undefined :: CInt) == sizeof(int) == 4`. When changing `HsCallback` to: {{{#!hs type HsCallback = Int -> IO () }}} both produce the same, correct result, but the above seems wrong, as `sizeOf (undefined :: Int) == 8`. This has been reproduced with both ghc-8.4 and ghc-8.2, and causes dbus to fail to build on s390x (https://github.com/rblaze/haskell-dbus/issues/26) as it relies on libxml-sax which contains the above (simplified) code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15844: Error fetching msys2 tarballs - crt-git
by GHC 22 Nov '18

22 Nov '18

#15844: Error fetching msys2 tarballs - crt-git -------------------------------------+------------------------------------- Reporter: Viwor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On Windows 10, I've set up mingw as instructed and then proceeded to run `./configure --enable-tarballs-autodownload` which resulted in the following error: {{{ configure: loading site script /mingw64/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.7.20181102 checking for GHC Git commit id... inferred f877d9cc99dd1ba0c038e70527031e9ba0934cd3 checking for ghc... /mingw64/bin/ghc checking version of ghc... 8.4.3 GHC path canonicalised to: /mingw64/bin/ghc checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... D:/ghc configure: Checking for Windows toolchain tarballs... ######################################################################## 100.0% ######################################################################## 100.0% md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. Error fetching msys2 tarballs; see errors above. }}} After deleting the said file, the same error occurs. The same error happens when I try to build with Hadrian. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition
by GHC 21 Nov '18

21 Nov '18

#15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple MonoLocalBinds, | MonomorphismRestriction | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code sample {{{#!haskell {-# LANGUAGE MonoLocalBinds #-} {-# LANGUAGE MonomorphismRestriction #-} tmp = 10 picker x y = if tmp > 11 then x else y main = do print (picker "x" "y") print (picker 10 11) }}} It fails with the misleading error message "* No instance for (Num [Char]) arising from the literal `10'...", from what seems to be an interaction between MonoLocalBinds and MonomorphismRestriction (turn either off and the error goes away). Should this be happening only for local bindings, or is it correct for this error to occur for top-level definitions too? In either case, would it be possible to give a better error message here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5793: make nofib awesome
by GHC 21 Nov '18

21 Nov '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > '''Note''' there is a shake build system attached that does a lot of this > (done by Neil Mitchell!). An explanation of it can be found here: > http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- > shake.html > > The design discussion of it is mostly lost as it was done on private > email sorry. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful. > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful (cf. #15357). E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15519: Minor code refactoring leads to drastic performance degradation
by GHC 21 Nov '18

21 Nov '18

#15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi! I've just observed an important performance problem. This code: {{{ test0 :: Text -> Result test0 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test0 #-} }}} runs over 10 times faster than this one: {{{ testGrammar1 :: Grammar Char testGrammar1 = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' in many $! s1 <> s2 <> s3 <> s4 {-# INLINE testGrammar1 #-} test1 :: Text -> Result test1 = runTokenParser testGrammar1 {-# NOINLINE test1 #-} }}} I've also observed another thing here, namely the former code runs also over 10 times faster than this code: {{{ test2 :: Text -> Result test2 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = X $! many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test2 #-} }}} The only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`. I've created sample project for it here: https://github.com/wdanilo/ghc- bug-peg-optimization/blob/master/src/Main.hs In order to run it execute `stack build --exec test`. The results are: {{{ benchmarking test0 time 420.0 μs (417.6 μs .. 422.9 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 421.0 μs (419.2 μs .. 425.3 μs) std dev 9.286 μs (4.239 μs .. 15.30 μs) variance introduced by outliers: 14% (moderately inflated) benchmarking test1 time 6.069 ms (6.022 ms .. 6.123 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.065 ms (6.037 ms .. 6.117 ms) std dev 114.5 μs (74.30 μs .. 183.4 μs) benchmarking test2 time 6.070 ms (6.007 ms .. 6.137 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.067 ms (6.039 ms .. 6.129 ms) std dev 123.0 μs (63.88 μs .. 220.1 μs) benchmarking native time 428.0 μs (421.5 μs .. 437.4 μs) 0.998 R² (0.995 R² .. 1.000 R²) mean 427.1 μs (424.1 μs .. 434.7 μs) std dev 15.18 μs (5.678 μs .. 26.26 μs) variance introduced by outliers: 29% (moderately inflated) }}} Where "native" is just standard `Text.takeWhile ...`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15926: conversion from Integer to Double rounds differently depending on the value
by GHC 20 Nov '18

20 Nov '18

#15926: conversion from Integer to Double rounds differently depending on the value --------------------------------------+------------------------------------ Reporter: drvirgilio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------------ I'm not sure if this is intended behavior or a bug. For values less than 2^53^, the the Integer can be represented exactly as a Double so there is no issue. For values from 2^53^ to 2^63^, {{{fromInteger n}}} rounds to the nearest {{{Double}}}, where ties go toward the {{{Double}}} with even least significant bit. This matches the behavior of {{{read}}}. For values between 2^63^ and 2^1024^, {{{fromInteger n}}} ''rounds down'' to the next representable {{{Double}}}. Steps to reproduce: These values are all the same except the last one because it falls just below the threshold for the "round to nearest, ties to even" rule. In this example, (2^63^) and (2^63^-2^10^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > fromInteger (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > fromInteger (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see the behavior of {{{fromInteger}}} matches that of {{{read . show}}} {{{#!hs > (read . show) (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > (read . show) (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > (read . show) (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see {{{fromInteger}}} is rounding down. In this example, (2^64^) and (2^64^-2^11^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > fromInteger (2^64 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} Here you can see the behavior of {{{fromInteger}}} does ''not'' match the behavior of {{{read . show}}} {{{#!hs > (read . show) (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > (read . show) (2^64 - 1) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > (read . show) (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0