March 2016 - ghc-tickets

[GHC] #9445: GHC Panic: Tick Exhausted with high factor
by GHC 22 May '17

22 May '17

#9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: panic | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: 5539 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello guys, this is an old bug which has been reported so many times that I'm not sure this will be noise or something useful. In a nutshell I have been hit by this bug installing the library "SFML", which relies heavily on FFI. The only interesting thing of this report is that it was necessary an very high simpl-factor to make the installation go through! Pre-bump: {{{ Resolving dependencies... In order, the following will be installed: SFML-0.2.0.0 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [...] [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.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sZQW{v} [lid] 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: 2655928 }}} And this was the magic line: {{{ cabal install SFML --ghc-option=-fsimpl-tick-factor=1630 }}} HTH, it turns out it's quite an annoying one! And yes, "1630" was the smaller factor which made the installation possible. Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9700: Support C structures in Haskell FFI
by GHC 22 May '17

22 May '17

#9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D252 -------------------------------------+------------------------------------- This ticket is for tracking progress on [[CStructures]] language extension proposal. The idea is to support C structures in Haskell FFI. See wiki for details. If it will be accepted, I'm going to implement it in few steps. The first one is to support structures as return value. Platform specific part for that is already implemented, see Phab:D252 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing.
by GHC 21 May '17

21 May '17

#11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #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