- ghc-tickets - Haskell.org

[GHC] #14616: panic! initTc: unsolved constraints
by GHC 26 Dec '17

26 Dec '17

#14616: panic! initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: w-j-w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- New haskeller here, I was doing an exercise at http://exercism.io/exercises/haskell /rotational-cipher/readme and got the following error message from the compiler. {{{ Compiling Main ( RotationalCipher.hs, .stack-work/dist/x86_64 -linux-tinfo6/Cabal-1.24.2.0/build/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] find_a7hU :: t_a7hT[tau:1] (CHoleCan: find) [W] find_a7iF :: t_a7iE[tau:1] (CHoleCan: find)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Progress: 16/17 -- While building custom Setup.hs for package rotational-cipher-1.1.0.1 using: /home/websterw/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64 -linux-tinfo6/Cabal-1.24.2.0 build lib:rotational-cipher test:test --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} I was using the normal project setup that exercism uses for this problem, with my code residing a file called `RotationalCipher.hs`. The contents of this file are as follows. {{{ rotate :: Int -> String -> String rotate n = map (rot n) rot :: Int -> Char -> Char rot i c | c `elem` ['a'..'z'] = let translate = zip (lowershift n) ['a'..'z'] in fst (find (\x -> snd x == c) translate) | c `elem` ['A'..'Z'] = let translate = zip (uppershift n) ['A'..'Z'] in fst (find (\x -> snd x == c) translate) | otherwise = c where lowershift n = take 26 $ drop n $ cycle ['a'..'z'] uppershift n = take 26 $ drop n $ cycle ['A'..'Z'] }}} The error occured when I ran `stack test` I am using fedora linux as my operating system on x86_64 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14614: Compile time regression when compiling alex generated files
by GHC 25 Dec '17

25 Dec '17

#14614: Compile time regression when compiling alex generated files -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11380 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile time increased slightly from 7.10.3 to 8.0.2 and significantly when going to 8.2.2 {{{ compiler=ghc-7.10.3 /c/test/happy-example $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.243s compiler=ghc-8.0.2 /c/test/happy-example $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.286s compiler=ghc-8.2.2 $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.721s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11380: `cabal repl` exhausts memory
by GHC 24 Dec '17

24 Dec '17

#11380: `cabal repl` exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a project that depends on happy/alex to generate parsers. (https://github.com/TOSPIO/pyn) Running `cabal repl` on my laptop (Gentoo Linux amd64) with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic. `cabal build` works fine. Problem arises when compiling the giant happy- generated dist/build/Language/Python/Parser/Parse.hs file also `cabal repl --ghc-options=-fobject-code` works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #8033: add AVX register support to llvm calling convention
by GHC 24 Dec '17

24 Dec '17

#8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): have the GHC calling conventions bits by default been flipped on in HEAD? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8033#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure
by GHC 22 Dec '17

22 Dec '17

#10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., ```#!asm # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) ``` This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13001: EnumFromThenTo is is not a good producer
by GHC 22 Dec '17

22 Dec '17

#13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) testFromThenTo :: Int -> Int testFromThenTo n = length ([0,2..(10^n)] :: [Int]) }}} {{{ $ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). Prelude Foo> :set +s :set +s Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 97,992 bytes) Prelude Foo> testFromThenTo 5 testFromThenTo 5 50001 (0.00 secs, 5,694,424 bytes) Prelude Foo> testFromThenTo 6 testFromThenTo 6 500001 (0.02 secs, 56,095,288 bytes) Prelude Foo> }}} I set the Type to bug rather than feature request as the source code in http://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.Enum.html#enum… seems to be trying to do list fusion: {{{#!hs -- efdInt and efdtInt deal with [a,b..] and [a,b..c]. -- The code is more complicated because of worries about Int overflow. -- See Note [How the Enum rules work] {-# RULES "efdtInt" [~1] forall x1 x2 y. efdtInt x1 x2 y = build (\ c n -> efdtIntFB c n x1 x2 y) "efdtIntUpList" [1] efdtIntFB (:) [] = efdtInt #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12905: Core lint with pattern synonym
by GHC 22 Dec '17

22 Dec '17

#12905: Core lint with pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yet another program from the type-indexed `Typeable` effort which breaks GHC (`master` branch as of 3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7) with a core lint error, {{{#!hs {-# LANGUAGE GADTs, TypeOperators, PatternSynonyms, TypeInType, PolyKinds, RankNTypes #-} module T where import GHC.Exts import Data.Kind import Data.Type.Equality data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TrFun arg res where TRFun arg res = TrFun arg res }}} This program produces many core lint errors, although all of them fall into only a few classes. Here's one, {{{ *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In the coercion ‘Sym (Sym cobox_a3fT |> Sym cobox_a3fU)’ Kind application error in type ‘((->) |> <*>_N ->_N <*>_N ->_N Sym cobox) a’ Function kind = * -> * -> k Arg kinds = [(a, TYPE r1)] }}} {{{ <no location info>: warning: [RHS of $d~~_a3fO :: (fun :: k) ~~ ((a -> b) :: *)] Kind application error in coercion ‘Sym (Sym (<(->)>_N |> ((<*>_N -> <*>_N -> Sym cobox_a3fU) ; Sym (<*>_N -> <*>_N -> Sym cobox_a3fH))) |> (<*>_N -> <*>_N -> Sym cobox_a3fU)) <a>_N’ Function kind = * -> * -> * Arg kinds = [(a, TYPE r1)] }}} It appears that this is yet another case of the kind of `(->)` being too restrictive (#11714) since `a -> b` appears to be lifted to the coercion `TyConAppCo role (->) [a, b]`. Adding a `FunCo` constructor to `Coercion` would likely be an easy way to resolve this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12670: Representation polymorphism validity check is too strict
by GHC 22 Dec '17

22 Dec '17

#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 GHC rejects this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data TypeRep (a :: k) where TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) }}} Claiming that it has inappropriate polymorphism over `RuntimeRep`, {{{ $ ghc hi2.hs [1 of 1] Compiling Hi ( hi2.hs, hi2.o ) hi2.hs:7:5: error: • A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r1 • In the definition of data constructor ‘TrFun’ In the data type declaration for ‘TypeRep’ }}} I suspect this check is unnecessarily strict since we never need to store a value of type `a` to represent `TypeRep a` at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14584: Core Lint error
by GHC 21 Dec '17

21 Dec '17

#14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language TypeFamilyDependencies, KindSignatures #-} {-# Language PolyKinds #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language RankNTypes #-} {-# Language NoImplicitPrelude #-} {-# Language FlexibleContexts #-} {-# Language MultiParamTypeClasses #-} {-# Language GADTs #-} {-# Language ConstraintKinds #-} {-# Language FlexibleInstances #-} {-# Language TypeOperators #-} {-# Language ScopedTypeVariables #-} {-# Language DefaultSignatures #-} {-# Language FunctionalDependencies #-} {-# Language UndecidableSuperClasses #-} {-# Language UndecidableInstances #-} {-# Language TypeInType #-} {-# Language AllowAmbiguousTypes #-} {-# Language InstanceSigs, TypeApplications #-} import Data.Monoid import Data.Kind data family Sing (a::k) class SingKind k where type Demote k = (res :: Type) | res -> k fromSing :: Sing (a::k) -> Demote k class SingI (a::k) where sing :: Sing a data ACT :: Type -> Type -> Type data MHOM :: Type -> Type -> Type type m ·- a = ACT m a -> Type type m ·-> m' = MHOM m m' -> Type class Monoid m => Action (act :: m ·- a) where act :: m -> (a -> a) class (Monoid m, Monoid m') => MonHom (mhom :: m ·-> m') where monHom :: m -> m' data MonHom_Distributive m :: (m ·- a) -> (a ·-> a) type Good k = (Demote k ~ k, SingKind k) instance (Action act, Monoid a, Good m) => MonHom (MonHom_Distributive m act :: a ·-> a) where monHom :: a -> a monHom = act @_ @_ @act (fromSing @m (sing @m @a :: Sing _)) where }}} fails on 8.2.1 and 8.3.20171208 when passed `-fdefer-type-errors -dcore- lint`, full log attached {{{ $ ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint 146-bug.hs GHCi, version 8.3.20171208: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 146-bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: In the expression: fromSing @ m_a2Ju ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14479: Partial type signatures and generalisation
by GHC 21 Dec '17

21 Dec '17

#14479: Partial type signatures and generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 should be rejected {{{ foo :: Num a => a -> a foo x = g x x where g :: Num b => _ -> b -> b g _ y = x + y }}} But it isn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2