August 2016 - ghc-tickets

[GHC] #11532: ghc: panic! occured
by GHC 19 Nov '16

19 Nov '16

#11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- I'd like to try install by following: {{{ $ cabal sandbox init $ cabal install metadata Resolving dependencies... Notice: installing into a sandbox located at /home/cutsea110/devel/haskell/sandbox/.cabal-sandbox Configuring metadata-0.4.2.0... Building metadata-0.4.2.0... : : [1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot ) [1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): LocalReg's live-in to graph cpd3t {_sp8MJ::P64} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: metadata-0.4.2.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- regards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ()))
by GHC 18 Nov '16

18 Nov '16

#12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu (Const ())) }}} produces {{{ • No instance for (Data (Const () (Mu (Const ())))) arising from a use of ‘k’ • In the expression: (z Mu `k` a1) In an equation for ‘gfoldl’: gfoldl k z (Mu a1) = (z Mu `k` a1) When typechecking the code for ‘gfoldl’ in a derived instance for ‘Data (Mu (Const ()))’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Data (Mu (Const ()))’ }}} while other type constructors work, e.g. {{{#!hs deriving instance Data.Data.Data (Mu []) deriving instance Data.Data.Data (Mu ((,) ())) }}} i am not sure if #10835 is related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks
by GHC 17 Nov '16

17 Nov '16

#8321: improve basic block layout on LLVM backend by predicting stack/heap checks ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (LLVM) | 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: | ------------------------------------+------------------------------------- Currently we don't give the LLVM optimizer any information about which branch of an `if` is likely to be taken. As a result, the optimizer is likely to produce a basic block layout which is not optimal. Improving the layout can improve performance through better instruction cache usage and better branch prediction by the hardware. We can control LLVM's idea of what is likely with the `llvm.expect` intrinsic function. Some obvious branches which we can predict accurately are the stack and heap checks that appear near the entry of many functions. Here's a small example of some Cmm code and the output of the LLVM optimizer/compiler. {{{ block_c2Lc_entry() // [R1, R2] { info_tbl: [(c2Lc, label: block_c2Lc_info rep:StackRep [])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c2Lc: Hp = Hp + 24; if (Hp > HpLim) goto c2Lm; else goto c2Ll; c2Lm: HpAlloc = 24; R2 = R2; R1 = R1; call stg_gc_pp(R2, R1) args: 8, res: 8, upd: 24; c2Ll: I64[Hp - 16] = :_con_info; P64[Hp - 8] = R1; P64[Hp] = R2; R1 = Hp - 14; Sp = Sp + 8; call (P64[Sp])(R1) args: 24, res: 0, upd: 24; } }] }}} {{{ 00000000000002b8 <c2Lc_info>: 2b8: 4c 89 e0 mov %r12,%rax 2bb: 4c 8d 60 18 lea 0x18(%rax),%r12 2bf: 4d 3b a5 18 01 00 00 cmp 0x118(%r13),%r12 2c6: 76 10 jbe 2d8 <c2Lc_info+0x20> 2c8: 49 c7 85 48 01 00 00 movq $0x18,0x148(%r13) 2cf: 18 00 00 00 2d3: e9 00 00 00 00 jmpq 2d8 <c2Lc_info+0x20> 2d4: R_X86_64_PC32 stg_gc_pp+0xfffffffffffffffc 2d8: 48 c7 40 08 00 00 00 movq $0x0,0x8(%rax) 2df: 00 2dc: R_X86_64_32S ghczmprim_GHCziTypes_ZC_con_info 2e0: 48 89 58 10 mov %rbx,0x10(%rax) 2e4: 4c 89 70 18 mov %r14,0x18(%rax) 2e8: 48 8b 45 08 mov 0x8(%rbp),%rax 2ec: 48 83 c5 08 add $0x8,%rbp 2f0: 49 8d 5c 24 f2 lea -0xe(%r12),%rbx 2f5: ff e0 jmpq *%rax 2f7: 90 nop }}} It would likely be better to invert the branch at `2c6` to a `ja`, so that the common case is adjacent to the function entry, and when `llvm.expect` is used on the condition in the branch, the LLVM optimizer does produce this alternate layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing.
by GHC 16 Nov '16

16 Nov '16

#9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11832: Allow reify to yield types in the current declaration group
by GHC 16 Nov '16

16 Nov '16

#11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: template- | Operating System: Unknown/Multiple haskell reify | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | TemplateHaskell/Reify -------------------------------------+------------------------------------- Here is the motivation TemplateHaskell/Reify. It would be useful to have a way to obtain types of identifiers in the current declaration group in splices. However, {{{reify}}} is defined to provide information about identifiers in previous declaration groups only. It would be fine to allow {{{reify}}} to work in a scheme combined with {{{addModFinalizer}}} or similar so it is executed when the types are known. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10771: Installation of Ivory - Static flags have not been initialised
by GHC 14 Nov '16

14 Nov '16

#10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Unfortunately I'm a Haskell newbie and can't provide very good detail for this report (I struggled to pass the Captcha!). However I will attach the output from a "make all" from the Ivory repository: https://github.com/GaloisInc/ivory.git Commit: '7ecea5839898b65430ca298fd1f3af4d2272e3fb'. Basically from what I can see, looks like it didn't work, output ends with: examples\Coroutine.hs:26:50: Warning: Unticked promoted constructor: `:->'. Use ':-> instead of `:->'. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11660: Remove Type pretty-printer in favor of IfaceType
by GHC 13 Nov '16

13 Nov '16

#11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new 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: -------------------------------------+------------------------------------- The `Type` pretty-printer has a fair amount of code in common with the pretty-printer for `IfaceType`. Moreover, both cases handle a number of special cases. With the introduction of `-fprint-explicit-runtime-reps` (Phab:D1961), there is now an inconsistency between these two. Let's resolve this inconsistency by eliminating the `Type` pretty-printer in favor of using the `IfaceType` printer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12021: Type variable escapes its scope
by GHC 11 Nov '16

11 Nov '16

#12021: Type variable escapes its scope -------------------------------------+------------------------------------- Reporter: ttuegel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, I believe a type variable is incorrectly escaping its scope. The example produces the error: {{{ Bug.hs:20:20: error: • Expected kind ‘Cat k’, but ‘(:-)’ has kind ‘Constraint -> Constraint -> *’ • In the first argument of ‘Iso’, namely ‘(:-)’ In the type signature: functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) In the class declaration for ‘Functor’ }}} If the definition of `Iso` is changed from {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t }}} to {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. p a b -> p s t }}} then this error does not occur. (The example still will not compile because I have omitted almost the entire implementation, but it should not fail here.) I am not certain what is really happening here, but it seems to me that when the RHS of `Iso` is constrained, then the type variable `k` introduced on the LHS of `Iso` is being unified incorrectly with the type variable `k` introduced in the definition of the `Functor` class. When the constraint is removed, GHC seems to recognize (correctly!) that the type variables are distinct. (This bug actually occurs with GHC 8.0.1-rc4, but the "Version" menu doesn't give me that option.) {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import GHC.Base ( Constraint, Type ) type Cat k = k -> k -> Type class Category (p :: Cat k) where type Ob p :: k -> Constraint class (Category (Dom f), Category (Cod f)) => Functor (f :: j -> k) where type Dom f :: Cat j type Cod f :: Cat k functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) class (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) | f -> p q instance (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) data Nat (p :: Cat j) (q :: Cat k) (f :: j -> k) (g :: j -> k) type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t data (p :: Constraint) :- (q :: Constraint) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11369: Suppress redundant-constraint warnings in case of empty classes
by GHC 07 Nov '16

07 Nov '16

#11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- The technique described in http://www.well-typed.com/blog/2015/07/checked-exceptions/ makes use of a class without any methods, i.e. {{{#!hs class Throws e }}} However, this by definition results in redundant constraints, e.g. {{{#!hs readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} which GHC 8.0 warns about. I propose to suppress warnings in case a class which has no methods is used as seemingly redundant constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables.
by GHC 07 Nov '16

07 Nov '16

#12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux DefaultSignatures, | TypeApplications | Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example code throws an error. The example code: {{{#!hs {-#LANGUAGE TypeApplications#-} {-#LANGUAGE MultiParamTypeClasses #-} {-#LANGUAGE AllowAmbiguousTypes #-} {-#LANGUAGE FlexibleInstances #-} {-#LANGUAGE ScopedTypeVariables #-} {-#LANGUAGE DefaultSignatures #-} module Test1 where -- | Type a is only used for -- type application. class ToUse a where toUse :: Int -> Int -- | The type used for -- type application data Default -- | The instance using Default as type application. -- To call use: -- > toUse @Default instance ToUse Default where toUse a = 3*a -- | Typeclass whose methods work -- only with type application. class (ToUse a) => Uses a b where uses :: b -> [b] -- | Default Signature, which generates the problem. -- It is the same as the normal one -- Comment it to 'fix' the bug. default uses :: b -> [b] uses v = [v] -- | Normal instances, nothing special instance Uses Default Int where uses v = take (toUse @Default 3) $ repeat v -- | Another normal one instance Uses Default String where uses v = take (toUse @Default 2) $ repeat v -- | This one works nicely instance (ToUse t, Uses t a, Uses t b) => Uses t (a,b) where uses (vl,vr) = zip ls rs where ls = uses @t vl rs = uses @t vr -- | But this one doesn't. -- Unless you comment the default signature. instance (ToUse t, Uses t a, Uses t b, Uses t c) => Uses t (a,b,c) }}} The error: {{{ • Could not deduce (Uses a0 a) arising from a use of ‘Test1.$dmuses’ from the context: (ToUse t, Uses t a, Uses t b, Uses t c) bound by the instance declaration at Test1.hs:47:10-66 The type variable ‘a0’ is ambiguous Relevant bindings include uses :: (a, b, c) -> [(a, b, c)] (bound at Test1.hs:47:10) • In the expression: Test1.$dmuses In an equation for ‘uses’: uses = Test1.$dmuses In the instance declaration for ‘Uses t (a, b, c)’ }}} Commenting out the default signature fixes the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8