March 2015 - ghc-tickets

[GHC] #10195: GHC forgets constraints when matching on GADTs
by GHC 14 Apr '15

14 Apr '15

#10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here's a relatively short piece of code that doesn't compile: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GADTs, ConstraintKinds, KindSignatures, FlexibleInstances #-} module Foo where import GHC.Exts data Foo m zp r'q = Foo zp data Dict :: Constraint -> * where Dict :: a => Dict a type family BarFamily a b :: Bool class Bar m m' instance (BarFamily m m' ~ 'True) => Bar m m' magic :: (Bar m m') => c m zp -> Foo m zp (c m' zq) magic = error "" getDict :: a -> Dict (Num a) getDict _ = error "" fromScalar :: r -> c m r fromScalar = error "" foo :: (Bar m m') => c m zp -> Foo m zp (c m' zq) -> Foo m zp (c m' zq) foo b (Foo sc) = let scinv = fromScalar sc in case getDict scinv of Dict -> magic $ scinv * b }}} GHC complains that it {{{ cannot deduce (BarFamily m m' ~ 'True) arising from a use of `magic` }}} in the definition of `foo`. Of course this is silly: `magic` requires `Bar m m'`, which is supplied as a constraint to `foo`. So GHC is forgetting about the constraint on `foo` and instead trying to satisfy the generic instance of `Bar` which has the constraint `(BarFamily m m' ~ 'True)`. I've found no less than six different ways to poke this code to make it compile, and some of them seem to reveal dangerous/unexpected behavior. The following are all deltas from the original code above and result in compiling code. 1. Add `ScopedTypeVariables` and give `scinv` an explicit signature: {{{ let scinv = fromScalar sc :: c m z in ... }}} I'm not sure why this would make GHC suddenly realize that it already has the constraint `Bar m m'`, but it seems to. (What it definitely does *not* do is result in a `BarFamily m m' ~ 'True` constraint.) 2. Remove the instance for `Bar`. This seems highly suspicious: the presence (or lack thereof) of an instance changes how GHC resolves the constraint in `foo`. 3. Change the constraint on `foo` to `BarFamily m m' ~ 'True`. In this case, GHC does *not* forget the constraint on `foo` and successfully uses it to satisfy the instance of `Bar`. Why does GHC forget about `Bar m m'` but not `BarFamily m m' ~ 'True`? 4. Add the superclass constraint `BarFamily m m' ~ 'True` to class `Bar`. Adding this constraint either makes GHC find the `Bar m m'` constraint on `foo` or, even more bizarrely, GHC still forgets about `Bar m m'` but manages to get the superclass constraint from `Bar m m'` and uses it to satisfy the instance. 5. Add `PolyKinds`. Not sure why this would affect anything. 6. Change the signature of `fromScalar` to `r -> s`. Not sure why this would affect anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10148: Optimization causes repeated computation
by GHC 14 Apr '15

14 Apr '15

#10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The attached program, when compiled with `-O0`, calls `array_adjust` 6 times and hence prints 6 lines of trace output. However, with `-O1`, it prints 37 lines of trace output instead. Moreover, this number grows quadratically rather than linearly when I increase the value of `n`. `-fno-state-hack` did not help. I can reproduce the issue with both GHC 7.8.4 and 7.10.0.20150123. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10218: GHC creates incorrect code which throws <<loop>>
by GHC 14 Apr '15

14 Apr '15

#10218: GHC creates incorrect code which throws <<loop>> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- My co-worker and I have spent almost two weeks tracking down this bug. We have finally produced a reasonably small test case... please take a look: https://github.com/yongqli/ghctestcase Under certain circumstances GHC generates incorrect code which goes into <<loop>>. When you compile and run the project without profiling and with eager black-holing, it will throw <<loop>> and exit. If you compile either without eager black-holing or with profiling, it will run correctly. See setup.hs for further details. This bug can be delicate to trigger, inlining certain things will prevent it from occurring. However, we've encountered this in production, and it is much harder to work-around in an actual project. We've had to resort to inlining every function in the affected module, which slows down compilation considerably. We've found that this bug triggers on 7.10.1 and 7.8.4. The test case will only compile on 7.10.1. Please let me know if there are any questions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux
by GHC 14 Apr '15

14 Apr '15

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- After setting `BuildFlavor = perf` in `build.mk` compilation ends with a panic: {{{ "/home/luite/buildtest/ghc-clean-buildtest/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp- dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim /ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock- prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist- install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc- prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc =-optP-include --optghc=-optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --source- module=src/%{MODULE/./-}.html --source- entity=src/%{MODULE/./-}.html#%{NAME} libraries/ghc- prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc- prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim /dist-install/build/GHC/PrimopWrappers.hs libraries/ghc- prim/./GHC/PrimWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries /ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine- readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /351) in 'GHC.PrimopWrappers' 2% ( 1 / 43) in 'GHC.PrimWrappers' 17% ( 1 / 6) in 'GHC.CString' 31% (170 /540) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130912 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc- prim.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} I've seen this problem before, but I thought that it was related to my patch. Now I got it on master branch and Luite reported the same problem on #ghc (log above is actually his). A workaround for this is disabling building of dicumentation in "perf" section of `build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1
by GHC 08 Apr '15

08 Apr '15

#9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1-rc1 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10: {{{#!hs module Main where import Control.Concurrent.Chan import Control.Monad main = do io <- newChan let inp = [0] :: [Int] mapM_ (writeChan io) inp {- -- WORKS: outp <- getChanContents io if 0 == head outp then putStrLn "OK" else error $ "Smoke test failed" -} -- BROKEN ON 7.10 (BlockedIndefinitelyOnMVar): outp <- getChanContents io if and (zipWith (==) inp outp) then putStrLn "OK" else error $ "Smoke test failed" {- -- WORKS: forM_ inp $ \xIn-> do xOut <- readChan io unless (xIn == xOut) $ error $ "Smoke test failed" -} }}} I first noticed the behavior in a Chan-like library I wrote, whose internals are completely different from Chan, but where the getChanContents is a copy-paste from Chan. So I assume it has something to do with `unsafeInterleaveIO`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10114: Kind mismatches with AnyK in rank-2 types
by GHC 08 Apr '15

08 Apr '15

#10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following module: {{{#!hs {-# LANGUAGE Rank2Types #-} module KindBug where type T = forall f a. f a foo :: T foo = undefined bar :: forall f a. f a bar = foo }}} ...produces the following error: {{{ [1 of 1] Compiling KindBug ( KindBug.hs, KindBug.o ) KindBug.hs:10:7: Kind incompatibility when matching types: f0 :: AnyK -> * f :: * -> * Expected type: f a Actual type: f0 a0 Relevant bindings include bar :: f a (bound at KindBug.hs:10:1) In the expression: foo In an equation for ‘bar’: bar = foo }}} Note that no extensions are enabled other than rank-2 types. Enabling and using kind annotations fixes the error, as does replacing the type synonym with its definition in the type signature of foo. Similar errors can also be generated with PolyKinds enabled and less plausible code, e.g. {{{ (return undefined :: forall f a. f a) :: f a }}}. The non-PolyKinds example is simplified from some actual code, where the type synonym was similar to the ones used in lens, and is the simplest example I could find (with help from Shachaf on IRC) that resembled real code. I searched for existing tickets and the closest I could find are #7916 and #5935, both of which are already fixed. Also, according to glguy (Eric Mertens) just now in #haskell-lens, the same error occurs in the 7.10 branch and in 7.11.20150120. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9160: Panic: Template variable unbound in rewrite rule
by GHC 08 Apr '15

08 Apr '15

#9160: Panic: Template variable unbound in rewrite rule ----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Installing `singletons-1.0` with GHC 7.8.2 on OS X 10.9.2 fails: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Template variable unbound in rewrite rule }}} Full build log attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10188: prefix type-level cons can't be parsed
by GHC 07 Apr '15

07 Apr '15

#10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Whereas other type operators (whether used as type families or used as data constructors) can be safely used in a prefix form, only the type- level cons of the built-in list kind can't be used in a prefix form. It really is a problem because we don't have any means to express type- level cons itself in source code. This for example prevents us from writing a generic type-level foldr that takes the built-in list and other similar data types alike. In a ghci: {{{#!hs > :set -XDataKinds -XTypeOperators > data Listy a = a ::: Listy a > :kind! (:::) (:::) :: k -> Listy k -> Listy k = forall (k :: BOX). (':::) > :kind! (:) <interactive>:1:2: parse error on input ‘:’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9964: GHC crash with NOINLINE and weird IO stuff
by GHC 07 Apr '15

07 Apr '15

#9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Crash where import GHC.Base crash :: IO Int crash = IO (\s -> let {-# NOINLINE s' #-} s' = s in (# s', 1::Int #)) }}} This compiles under 7.6.3, but both 7.8.3 and head choke: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): StgCmmEnv: variable not found s{v sLw} [lid] local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10214: parser: TransStmt has incorrect SrcSpan
by GHC 07 Apr '15

07 Apr '15

#10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for `squals` is. {{{#!hs squals :: { Located [LStmt RdrName (LHsExpr RdrName)] } -- In reverse order, because the last -- one can "grab" the earlier ones : squals ',' transformqual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> [L (getLoc $3) ((unLoc $3) (reverse (unLoc $1)))]) } }}} The location of the whole statement is set to that `transformqual` when it fact it should encompass the whole production. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6