January 2016 - ghc-tickets

[GHC] #11519: Inferring non-tau kinds
by GHC 18 Feb '16

18 Feb '16

#11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While up to my usual type-level shenanigans, I found that I want this definition: {{{ data TypeRep (a :: k) -- abstract data TypeRepX :: (forall k. k -> Constraint) -> Type where TypeRepX :: forall k (c :: forall k'. k' -> Constraint) (a :: k). c a => TypeRep a -> TypeRepX c }}} Note `TypeRepX`'s higher-rank kind. The idea is that I want to optionally constrain `TypeRepX`'s payload. Without using a higher-rank kind, the constraint would necessary fix the kind of the payload, and I don't want that. For example, I sometimes use `TypeRepX ConstTrue`, where {{{ class ConstTrue (a :: k) instance ConstTrue a }}} This actually works just fine, and I've been using the above definition to good effect. But then I wanted a `Show` instance: {{{ instance Show (TypeRep a) -- elsewhere instance Show (TypeRepX c) where show (TypeRepX tr) = show t }}} Looks sensible. But GHC complains. This is because it tries to infer `c`'s kind, by inventing a unification variable and then unifying. But this doesn't work, of course, because `c`'s kind is not a tau-type, so unification fails, lest we let impredicativity sneak in. What's particularly vexing is that, even if I annotate `c` with the correct kind, unification ''still'' fails. This is because that `c` is a ''usage'' of `c`, not a ''binding'' of `c`. Indeed, there is no place in an instance declaration to bind a type variable explicitly, so I have no recourse. I'm not sure what the solution is here. Somehow, it feels that inferring a non-tau kind for `c` is perfectly safe, because the kind is known from the use of `TypeRepX`. This would allow me to drop the kind annotation in the definition of `TypeRepX`, which looks redundant to me. But I'm not fully sure about this assumption. At the least, we could introduce a spot for explicit binding of type variables in instance declarations. I think, actually, I just figured it out. Use `ExpType`s when kind- checking types. Then I think the normal bidirectional thing (actually already implemented) will do the Right Thing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found
by GHC 18 Feb '16

18 Feb '16

#11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: Strict | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE Strict #-} main = print $ let x = undefined in True }}} Using HEAD or GHC 8.0: {{{ $ ghc-8.0.0.20160109 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160109 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIP_aDK local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Using a devel2 build: {{{ $ ./inplace/bin/ghc-stage2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :->] WARNING: file compiler/coreSyn/CoreSubst.hs, line 278 CoreSubst.lookupIdSubst simpleOptExpr $dIP_aDO InScope [aDM :-> a_aDM] WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160103 for x86_64-unknown-linux): ASSERT failed! file compiler/stgSyn/CoreToStg.hs line 1025 $dIP_aDO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9648: ghci fails to reload after deleting/creating an imported module
by GHC 17 Feb '16

17 Feb '16

#9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the dependent module but erroneously claims that parent can't find the child. Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid {{{ $ echo module Util where > Util.hs $ echo import Util; main = print 1 > Main.hs $ ghci Main.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Util, Main. *Main> :!del Util.hs *Main> :r Main.hs:1:8: Could not find module `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util, Main. *Main> :!echo module Util where > Util.hs *Main> :r [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed] Main.hs:1:1: Failed to load interface for `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9041: NCG generates slow loop code
by GHC 17 Feb '16

17 Feb '16

#9041: NCG generates slow loop code -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler (NCG) | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In http://stackoverflow.com/a/23322255/263061 we compile the code {{{ main :: IO () main = do loop (maxBound :: Word32) $ \i -> do when (i `rem` 100000000 == 0) $ putStrLn "foo" }}} and compare the assembly generated by the NCG and `-fllvm`. The LLVM code is 10 times faster. While the LLVM code looks great, NCG one generated looks quite unfortunate and messy, with a lot of unnecessary `mov`ing around. I am by no means an expert in this, but some of it looks like low hanging potential improvements. This is the '''LLVM code''': {{{ Main_zdwa_info: .LBB1_1: movl $4294967295, %esi /* load the loop bound */ movabsq $-6067343680855748867, %rdi /* load a magic number for the modulus */ jmp .LBB1_2 .LBB1_4: incl %ecx /* loop core start */ .LBB1_2: cmpq %rsi, %rcx je .LBB1_6 /* check loop bound */ /* do the modulus with two multiplications, a shift and a magic number */ /* note : gcc does the same reduction */ movq %rcx, %rax mulq %rdi shrq $26, %rdx imulq $100000000, %rdx, %rax cmpq %rax, %rcx jne .LBB1_4 /* loop core end */ /* Code omitted: print, then return to loop beginning */ .LBB1_6: }}} So the core of the loop is a nice and short: {{{ incl cmpq je movq [division replaced by magic multiplication] mulq shrq imulq cmpq jne }}} Now what '''NCG''' produces: {{{ Main_zdwa_info: /* loop core start */ .Lc3JD: leaq -16(%rbp),%rax /* stack check */ cmpq %r15,%rax jb .Lc3JO /* jump not taken in the normal case */ .Lc3JP: movl $4294967295,%eax /* issue: loading the bound on every iteration */ cmpq %rax,%r14 jne .Lc3JB .Lc3JC: /* Return from main. Code omitted */ .Lc3JB: /* test the index for modulus */ movl $100000000,%eax /* issue: unnecessary moves */ movq %rax,%rbx /* and loading the modulo arg on every iteration */ movq %r14,%rax xorq %rdx,%rdx /* shorter alternative to mov $0,%rdx */ divq %rbx /* issue: doing the division (llvm and gcc avoid this) */ testq %rdx,%rdx jne .Lc3JU /* This jump is usually taken. */ .Lc3JV: /* do the printing. Code omitted. Not relevant */ .Lc3JN: /* increment index and (I guess) restore registers messed up by the printing */ movq 8(%rbp),%rax /* This code is not very relevant because we don't almost never */ incq %rax movl %eax,%r14d addq $16,%rbp jmp Main_zdwa_info .Lc3JU: leaq 1(%r14),%rax /*issue: why not just increment r14? */ movl %eax,%r14d jmp Main_zdwa_info }}} So the core of this loop is {{{ movl [stack check] cmpq jne movl movq movq xorq divq testq jne leaq movl jmp }}} Some issues here: * the stack check is inside the loop * the loop limit is loaded every time inside the loop * the modulo arg is loaded every time inside the loop * we are shuffling around registers * no strength reduction (div is not replaced by cheaper magic number imul) * weird increment using leaq It would be great if somebody with codegen insight could comment on whether these are easy targets for improvement! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11483: Ghci integration with readline
by GHC 17 Feb '16

17 Feb '16

#11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: readline | Operating System: Unknown/Multiple complete | Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When running ghci, the word "import" is not in the list generated by readline completion. Namely, if to type {{{#!hs > i }}} the suggestions that appear after pressing <TAB> are {{{#!hs id isDenormalized isNegativeZero init isIEEE iterate interact isInfinite ioError isNaN }}} If to type {{{#!hs > im }}} then pressing <TAB> gives beep. Also, if we have at prompt {{{#!hs > import q }}} pressing <TAB> does not produce any completion. I would expect to get {{{#!hs > import qualified }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11418: Suggest correct spelling when module is not found because of typo
by GHC 17 Feb '16

17 Feb '16

#11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Given these two modules: Aaa.hs: {{{#!hs module Aaa where import BBb main :: IO () main = putStrLn myString }}} Bbb.hs: {{{#!hs module Bbb where myString :: String myString = "hi" }}} There's a typo in `Aaa.hs`, the import should be `Bbb` instead of `BBb`. Running `runhaskell Aaa.hs` results in this error: {{{ Aaa.hs:3:18: Could not find module ‘BBb’ Use -v to see a list of the files searched for. }}} The request is to have the compiler suggest that this is a typo and that it should be `Bbb` instead. It already does this for misspelled functions, if I recall correctly. Because the compiler will not continue when finding an error like this, it won't be harmful to spend a little extra time looking for possible misspellings. How typo's should be recognized is something that should be fleshed out later. For example, a hamming distance of 2 or less could indicate a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #9637: Type level programming needs an error function
by GHC 17 Feb '16

17 Feb '16

#9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | 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: -------------------------------------+------------------------------------- When doing type level programming you often need a way to report errors. I suggest a closed type family called Error with special semantics. It is kinded like this Error :: Symbol -> k1 -> k2 If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to). I've found that having this function gives more accurate and earlier error messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8927: Multiple case match at once
by GHC 16 Feb '16

16 Feb '16

#8927: Multiple case match at once -------------------------------------------+------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: case, multiple | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In F# we can do {{{ #!div style="font-size: 120%" {{{#!haskell match x with | 1 | 2 | 3 -> "123" | 4 | 5 | 6 -> "456" }}} }}} It will be nice if we have an extension which allows us to do {{{ #!div style="font-size: 120%" {{{#!haskell case x of 1 | 2 | 3 -> "123" 4 | 5 | 6 -> "456" }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers
by GHC 16 Feb '16

16 Feb '16

#11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently only `F1` through `F4` and `D1` and `D2` are assigned to registers in the PowerPC backend. Assign `F5` and `F6` and `D3` through `D6` to registers too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11273> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11361: Test tc253 doesn't pass with reversed uniques
by GHC 15 Feb '16

15 Feb '16

#11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- It fails with: {{{ tc253.hs:23:7: error: • Couldn't match type ‘Maybe Int’ with ‘(String, Bool)’ Expected type: Maybe Int -> (String, Int) -> Maybe Int Actual type: Fam Int Bool -> Fam Int Int -> Fam Int Bool • In the expression: inc (undefined :: Int) In an equation for ‘foo’: foo = inc (undefined :: Int) }}} Steps to reproduce: 1. Add line `TEST_HC_OPTS += -dinitial-unique=16777000 -dunique-increment=-1` after line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=tc253` I suspect this is related to #11148 since the symptoms are similar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11361> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12