October 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] #12754: Adding an explicit export list halves compilation time.
by GHC 18 Nov '16

18 Nov '16

#12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- A file only containing a 10000 constructor enumeration type compiles twice as fast with an explicit export list compare to having no export list. {{{ # print "module A where" print "module A (T ( .. ) ) where" print "\n" print "data T = C" for i in range(0,10000): print (" | C" + str(i)) }}} Without an export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m22.872s user 0m19.653s sys 0m0.868s }}} With the export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m11.249s user 0m10.428s sys 0m0.435s }}} The culprit here is `exports_from_avail`, in the case that no export list is provided, the things to export are gathered from the `GlobalRdrEnv`. Each constructor is placed in its own `Avail` which are then combined by `plusAvail` which is implemented using the expensive `unionLists`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12777: reify yields the wrong type in the presence of functional rependencies
by GHC 18 Nov '16

18 Nov '16

#12777: reify yields the wrong type in the presence of functional rependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- {{{reify}}} yields an incomplete type in the following program. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE FunctionalDependencies #-} module B where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH class C a b | a -> b where yo :: a -> IO b instance C Bool Int where yo = undefined t3 :: IO () t3 = do x <- yo True $(do addModFinalizer $ TH.reify 'x >>= runIO . print [| return () |] ) }}} {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627401898 (VarT a_1627404604) Nothing }}} The problem seems to be that finalizers run before functional dependencies are considered. Hacking ghc to run finalizers after {{{simplifyTop}}} produces the expected output instead: {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627404863 (ConT GHC.Types.Int) Nothing }}} Would anyone object to running finalizers after {{{simplifyTop}}}? This implies that finalizers shouldn't add definitions (with {{{addTopDecls}}}) which depend on {{{simplifyTop}}} to be type-checked. Another option is to call {{{simplifyTop}}} before and after running finalizers. But is it safe to do so? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #12702: Don't warn about redundant constraints for necessary
by GHC 17 Nov '16

17 Nov '16

#12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | 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: -------------------------------------+------------------------------------- In the attached example, GHC warns that the constraint on line 16 of Main.hs is redundant. {{{ • Redundant constraint: e ~ FGCD r s • In the type signature for: foo :: (e ~ FGCD r e', e' ~ (e * (s / r)), e ~ FGCD r s) => Proxy s -> Proxy r -> () }}} However, when I remove that constraint, I get the following error: {{{ • Occurs check: cannot construct the infinite type: t0 ~ Factored.FMul (FGCD r t0) (Factored.FDiv s r) The type variable ‘t0’ is ambiguous • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: forall e e' r s. (e ~ FGCD r e', e' ~ (e * (s / r))) => Proxy s -> Proxy r -> () }}} I'm not entirely sure if the error is correct or not; I can't figure out what it's getting on about. So: if the constraint is required to make `foo` compile, then it is most certainly ''not'' redundant, and there shouldn't be a warning suggesting its removal. If the constraint really isn't required, then the error is a bug. (I apologize for the second bug involving singletons in as many days; I simply don't know an easy way to remove that dependency.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #12744: Register Allocator Unit Tests
by GHC 16 Nov '16

16 Nov '16

#12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | 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: -------------------------------------+------------------------------------- Currently the backend only has end-to-end tests and I think it would benefit from some unit tests starting with (for no special reason) the register allocator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12568: Release hsc2hs new version to Hackage
by GHC 14 Nov '16

14 Nov '16

#12568: Release hsc2hs new version to Hackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- Richard Cook recently fixed #12054 in f5ae016e5a69ebf42d612805e51afd9227df9389. This needs to be released to Hackage before the 8.0.2 GHC release -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3