April 2016 - ghc-tickets

[GHC] #8048: Register spilling produces ineffecient/highly contending code
by GHC 21 May '17

21 May '17

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: register | Operating System: Unknown/Multiple allocator spill | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values. Consider the following program: {{{ {-# LANGUAGE BangPatterns #-} module Spill where import GHC.Exts data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int spill :: S -> S -> S -> S spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _) = S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u) }}} Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like: {{{ _cnc: addq $80,%r12 cmpq 144(%r13),%r12 ja _cni movq $Spill.S_con_info,-72(%r12) movq 32(%rbp),%rax movq %rax,-64(%r12) movq 24(%rbp),%rax movq %rax,-56(%r12) movq 16(%rbp),%rax movq %rax,-48(%r12) movq 8(%rbp),%rax movq %rax,-40(%r12) movq 40(%rbp),%rax movq %rax,-32(%r12) movq 48(%rbp),%rax movq %rax,-24(%r12) movq 56(%rbp),%rax movq %rax,-16(%r12) movq 64(%rbp),%rax movq %rax,-8(%r12) movq 7(%rbx),%rax movq %rax,0(%r12) leaq -71(%r12),%rbx addq $72,%rbp jmp *0(%rbp) }}} {{{ _csv: movq 63(%rbx),%rax movq %rax,-56(%rbp) movq 55(%rbx),%rax movq %rax,-48(%rbp) movq 47(%rbx),%rax movq %rax,-40(%rbp) movq 39(%rbx),%rax movq %rax,-32(%rbp) movq 31(%rbx),%rax movq %rax,-24(%rbp) movq 23(%rbx),%rax movq %rax,-16(%rbp) movq 71(%rbx),%rax movq %rax,-8(%rbp) movq 15(%rbx),%rax movq %rax,0(%rbp) }}} And likewise for LLVM: {{{ .LBB10_1: # %coZ movq 7(%rbx), %rcx movq $Spill_S_con_info, 8(%rax) movq 8(%rbp), %rdx movq %rdx, 16(%rax) movq 16(%rbp), %rdx movq %rdx, 24(%rax) movq 24(%rbp), %rdx movq %rdx, 32(%rax) movq 32(%rbp), %rdx movq %rdx, 40(%rax) movq 40(%rbp), %rdx movq %rdx, 48(%rax) movq 48(%rbp), %rdx movq %rdx, 56(%rax) movq 56(%rbp), %rdx movq %rdx, 64(%rax) movq 64(%rbp), %rdx movq %rdx, 72(%rax) movq %rcx, (%r12) movq 72(%rbp), %rax leaq 72(%rbp), %rbp leaq -71(%r12), %rbx jmpq *%rax # TAILCALL }}} Quoting from #ghc "the [register allocator] core algo is '96 vintage". Improvements are needed; * Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention * Sink memory reads in order to reduce register pressure -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors
by GHC 19 May '17

19 May '17

#11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: GADTs | Operating System: Linux Architecture: x86 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://www.youtube.com/watch?v=6snteFntvjM A Practical Introduction to Haskell GADTs] from LambdaConf 2015, example from attachment Hole.hs: {{{#!hs {-# LANGUAGE GADTs #-} data STy ty where SInt :: STy Int SBool :: STy Bool SMaybe :: STy a -> STy (Maybe a) zero :: STy ty -> ty zero ty = case ty of SInt -> 5 SBool -> False SMaybe a -> _ }}} When running with "GHCi, version 7.11.20151226": {{{ % ghci -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.11.20151226: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: error: • Found hole: _ :: ty Where: ‘ty’ is a rigid type variable bound by the type signature for: zero :: forall ty. STy ty -> ty at /tmp/Hole.hs:8:9 • In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } • Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) Failed, modules loaded: none. Prelude> }}} when older versions (GHCi version 7.10.2) refine the type of `_` to `Maybe a`: {{{ % ghci-7.10.2 -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: Found hole ‘_’ with type: Maybe a Where: ‘a’ is a rigid type variable bound by a pattern with constructor SMaybe :: forall a. STy a -> STy (Maybe a), in a case alternative at /tmp/Hole.hs:12:3 Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } Failed, modules loaded: none. Prelude> }}} Regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11439: Request for comments: Allow duplicate type signatures
by GHC 17 May '17

17 May '17

#11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Interested in feedback (Code inspired by [http://www.cs.ox.ac.uk/projects/utgp/school/idris-tutorial.pdf Idris tutorial]) {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue x = x sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Allow duplicate type signatures: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum :: SBool True -> Natural -> Natural sum STrue x = x sum :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Where {{{#!hs data SBool b where STrue :: SBool True SFalse :: SBool False type family IsSingleton (b :: Bool) :: Type where IsSingleton True = Natural IsSingleton False = [Natural] }}} ---- == Behaviour == You could do something fancy but I would be happy with a check that any duplicate type signature is a specialization of the ''top'' top-level one, this would allow something like this: {{{#!hs length :: [a] -> Int length :: [()] -> Int length [] = 0 length (_:xs) = 1 + length xs }}} Which isn't very useful, hah what ever. ---- == Benefits == Mainly compiler-checked documentation, for the `sum` function we make it clearer that a `STrue` gives you `Natural -> Natural` while `SFalse` gives you `[Natural] -> Natural`. This is most apparent in the final syntax idea: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural @False :: _ -> [Natural] -> Natural }}} Reader need not look at definition of `IsSingleton`, it is fully described by the duplicate signatures. See ''lens'' where most functions have some kind of type specialisation declared in comments: [https://hackage.haskell.org/package/lens-4.13/docs /Control-Lens-Fold.html#v:-94--63- (^?)] whose type is `(^?) :: s -> Getting (First a) s a -> Maybe a`: {{{#!hs (^?) :: s -> Getter s a -> Maybe a (^?) :: s -> Fold s a -> Maybe a (^?) :: s -> Lens' s a -> Maybe a (^?) :: s -> Iso' s a -> Maybe a (^?) :: s -> Traversal' s a -> Maybe a }}} ---- == Alternative syntax == Throwing it out there, regardless of ambiguity: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural :: SBool True -> Natural -> Natural sum STrue x = x :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... :: SBool True -> Natural -> Natural sum STrue x = x ... :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... @True :: _ -> Natural -> Natural sum STrue x = x ... @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural sum STrue x = x @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym
by GHC 12 May '17

12 May '17

#11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- For convenience, I'll use GHCi to demonstrate flag behavior. First, we define a file: ``` {-# LANGUAGE TypeInType #-} import Data.Kind type Star = Type newtype T k (t :: k) = T () ``` Next, we load it up in GHCi, WITHOUT `-XTypeInType`. Now we observe strange behavior: ``` ezyang@sabre:~$ ghc-8.0 --interactive C.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( C.hs, interpreted ) Ok, modules loaded: Main. *Main> :k T Type Int T Type Int :: * *Main> :k T Star Int <interactive>:1:3: error: • Data constructor ‘Star’ cannot be used here (Perhaps you intended to use DataKinds) • In the first argument of ‘T’, namely ‘Star’ In the type ‘T Star Int’ ``` Of course, if we pass `-TypeInType` to GHCi that fixes the problem (BTW, `DataKinds` does NOT solve the problem.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11966: Surprising behavior with higher-rank quantification of kind variables
by GHC 12 May '17

12 May '17

#11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry about the rubbish title. I wrote the following code, which type checks: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Test where import Data.Kind (Type) -- Simplification type family Col (f :: k -> j) (x :: k) :: Type -- Base types data PGBaseType = PGInteger | PGText -- Transformations data Column t = Column Symbol t newtype Nullable t = Nullable t newtype HasDefault t = HasDefault t -- Interpretations data Expr k data Record (f :: forall k. k -> Type) = Record {rX :: Col f ('Column "x" 'PGInteger) ,rY :: Col f ('Column "y" ('Nullable 'PGInteger)) ,rZ :: Col f ('HasDefault 'PGText)} }}} However, if I play with this in GHCI, I can get the following error: {{{ λ> let x = undefined :: Record Expr <interactive>:136:29-32: error: • Expected kind ‘forall k. k -> Type’, but ‘Expr’ has kind ‘forall k. k -> *’ • In the first argument of ‘Record’, namely ‘Expr’ In an expression type signature: Record Expr In the expression: undefined :: Record Expr }}} It seems that if I write {{{#!hs data Expr :: forall k. k -> Type }}} things work, but I'm unclear if/why that is necessary, and the error message certainly needs to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11722: No TypeRep for unboxed tuples
by GHC 11 May '17

11 May '17

#11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- This now crashes on GHC HEAD: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import Data.Typeable import GHC.Exts main :: IO () main = print $ typeOf (Proxy :: Proxy (# Int, Int #)) }}} {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Main ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Previously, this was rejected with an error message, since you couldn't put an unlifted type as the argument of `Proxy`.) (Copied from comment:28:ticket:11471.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11722> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9450: GHC instantiates Data instances before checking hs-boot files
by GHC 11 May '17

11 May '17

#9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: boot,deriving | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling a file with deriving instances in it and making use of boot files, it appears that the derivation is attempted before the boot files are checked for consistency. This can lead to GHC panics, as when compiling GHC after this commit https://github.com/alanz/ghc/commit/c73182ca7345f0debba47d0b17a907bcac27c41f In the attached files, if you try to load HsLit.lhs into ghci it will complain about the missing Data instance, not about the boot file inconsistency. If you remove the Data from the deriving clause of HsOverLit, it complains about the boot file inconsistency. I have not managed to reproduce the original panic in this stripped down environment, but if it is needed to more fully understand the problem I can try again to do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10584: Installation of SFML failed
by GHC 10 May '17

10 May '17

#10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This report is bad because I have no idea what I'm reporting but the compiler asked me to so there you go: % cabal install sfml :( Resolving dependencies... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Failed to install SFML-0.2.0.0 Build log ( /home/user/.cabal/logs/SFML-0.2.0.0.log ): Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [ 1 of 71] Compiling SFML.Window.WindowHandle ( src/SFML/Window/WindowHandle.hs, dist/build/SFML/Window/WindowHandle.o ) [ 2 of 71] Compiling SFML.SFDisplayable ( src/SFML/SFDisplayable.hs, dist/build/SFML/SFDisplayable.o ) [ 3 of 71] Compiling SFML.SFCopyable ( src/SFML/SFCopyable.hs, dist/build/SFML/SFCopyable.o ) [ 4 of 71] Compiling SFML.System.InputStream ( dist/build/SFML/System/InputStream.hs, dist/build/SFML/System/InputStream.o ) [ 5 of 71] Compiling SFML.SFResource ( src/SFML/SFResource.hs, dist/build/SFML/SFResource.o ) [ 6 of 71] Compiling SFML.Utils ( src/SFML/Utils.hs, dist/build/SFML/Utils.o ) [ 7 of 71] Compiling SFML.Window.VideoMode ( dist/build/SFML/Window/VideoMode.hs, dist/build/SFML/Window/VideoMode.o ) [ 8 of 71] Compiling SFML.Window.Types ( src/SFML/Window/Types.hs, dist/build/SFML/Window/Types.o ) [ 9 of 71] Compiling SFML.Window.Keyboard ( dist/build/SFML/Window/Keyboard.hs, dist/build/SFML/Window/Keyboard.o ) [10 of 71] Compiling SFML.Window.Joystick ( dist/build/SFML/Window/Joystick.hs, dist/build/SFML/Window/Joystick.o ) [11 of 71] Compiling SFML.Window.ContextSettings ( dist/build/SFML/Window/ContextSettings.hs, dist/build/SFML/Window/ContextSettings.o ) [12 of 71] Compiling SFML.Window.Context ( dist/build/SFML/Window/Context.hs, dist/build/SFML/Window/Context.o ) [13 of 71] Compiling SFML.System.Vector3 ( dist/build/SFML/System/Vector3.hs, dist/build/SFML/System/Vector3.o ) [14 of 71] Compiling SFML.System.Vector2 ( dist/build/SFML/System/Vector2.hs, dist/build/SFML/System/Vector2.o ) [15 of 71] Compiling SFML.Window.Mouse ( dist/build/SFML/Window/Mouse.hs, dist/build/SFML/Window/Mouse.o ) [16 of 71] Compiling SFML.Window.Event ( dist/build/SFML/Window/Event.hs, dist/build/SFML/Window/Event.o ) [17 of 71] Compiling SFML.Window.SFWindow ( src/SFML/Window/SFWindow.hs, dist/build/SFML/Window/SFWindow.o ) [18 of 71] Compiling SFML.Window.Window ( dist/build/SFML/Window/Window.hs, dist/build/SFML/Window/Window.o ) [19 of 71] Compiling SFML.System.Time ( dist/build/SFML/System/Time.hs, dist/build/SFML/System/Time.o ) [20 of 71] Compiling SFML.Audio.SFSoundBuffer ( src/SFML/Audio/SFSoundBuffer.hs, dist/build/SFML/Audio/SFSoundBuffer.o ) [21 of 71] Compiling SFML.System.Sleep ( dist/build/SFML/System/Sleep.hs, dist/build/SFML/System/Sleep.o ) [22 of 71] Compiling SFML.System.Clock ( src/SFML/System/Clock.hs, dist/build/SFML/System/Clock.o ) [23 of 71] Compiling SFML.System ( src/SFML/System.hs, dist/build/SFML/System.o ) [24 of 71] Compiling SFML.Window ( src/SFML/Window.hs, dist/build/SFML/Window.o ) [25 of 71] Compiling SFML.Graphics.Types ( src/SFML/Graphics/Types.hs, dist/build/SFML/Graphics/Types.o ) [26 of 71] Compiling SFML.Graphics.SFSmoothTexture ( src/SFML/Graphics/SFSmoothTexture.hs, dist/build/SFML/Graphics/SFSmoothTexture.o ) [27 of 71] Compiling SFML.Graphics.SFShapeResizable ( src/SFML/Graphics/SFShapeResizable.hs, dist/build/SFML/Graphics/SFShapeResizable.o ) [28 of 71] Compiling SFML.Graphics.SFCoordSpace ( src/SFML/Graphics/SFCoordSpace.hs, dist/build/SFML/Graphics/SFCoordSpace.o ) [29 of 71] Compiling SFML.Graphics.SFBindable ( src/SFML/Graphics/SFBindable.hs, dist/build/SFML/Graphics/SFBindable.o ) [30 of 71] Compiling SFML.Graphics.Rect ( dist/build/SFML/Graphics/Rect.hs, dist/build/SFML/Graphics/Rect.o ) [31 of 71] Compiling SFML.Graphics.SFBounded ( src/SFML/Graphics/SFBounded.hs, dist/build/SFML/Graphics/SFBounded.o ) [32 of 71] Compiling SFML.Graphics.SFViewable ( src/SFML/Graphics/SFViewable.hs, dist/build/SFML/Graphics/SFViewable.o ) [33 of 71] Compiling SFML.Graphics.Texture ( src/SFML/Graphics/Texture.hs, dist/build/SFML/Graphics/Texture.o ) [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_sJFj To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 190129 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: SFML-0.2.0.0 failed during the building phase. The exception was: ExitFailure 1 cabal install sfml 7.18s user 0.76s system 93% cpu 8.460 total -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8