- ghc-tickets - Haskell.org

[GHC] #8036: Demand analyser is unpacking too deeply
by GHC 04 Jul '13

04 Jul '13

#8036: Demand analyser is unpacking too deeply ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ The demand analyser reports that fixpoint iterations are sometimes going on forever; in particular, this debug trace trips: {{{ | + = -- pprTrace "dmdFix loop" (ppr n <+> (vcat | + -- [ text "Sigs:" <+> ppr [ (id,lookupVarEnv | (sigEnv env) id, | + -- lookupVarEnv | (sigEnv env') id) | + -- | (id,_) <- pairs], | + -- text "env:" <+> ppr env, | + -- text "binds:" <+> pprCoreBinding (Rec }}} This happens during bootsrapping GHC itself, and maybe somewhere in the testsuite; I forget. The reason is that I thought a neater way to control unpacking of recursive products would work (see the `ae_rec_tc` field of `AnalEnv`) but I was wrong. This doesn't bite often but it's plainly wrong and needs fixing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8029: batch-mode recompilation checking sometimes fails
by GHC 04 Jul '13

04 Jul '13

#8029: batch-mode recompilation checking sometimes fails -----------------------------+---------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: recompilation, batch-mode Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The batch-mode recompilation checker seems to be broken. Suppose you have a source tree with {{{ Data/List.hs Data/Top.hs }}} and Data/List.hs defining 'foo' and Data/Top.hs importing Data.List (local file). Compile Data/Top.hs, then rename Data.List so you have {{{ Data/List.{hi,o} Data/OtherList.hs -- exports 'foo' Data/Top.hs -- imports Data.List and Data.OtherList Data/Top.{hi.o} }}} Attempting to run 'ghc -c Data/Top.hs' will now fail with " Failed to load interface for `Data.OtherList'". This error appears to be specific to built-in modules, if I use a library module (e.g. Data.Vector from the vector package) I instead get an error that multiple definitions of 'foo' are in scope. A test repo is available at https://github.com/JohnLato/tripping-octo- avenger Incidentally, everything works if I use 'ghc -c --make'. I think a reasonable fix would be for --make to be on by default for batch-mode compilation as well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls
by GHC 03 Jul '13

03 Jul '13

#8031: Template Haskell gets confused with kind variables introduced in separate foralls -----------------------------+---------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: TemplateHaskell PolyKinds Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following file compiles without complaint: {{{ {-# LANGUAGE TemplateHaskell, RankNTypes, PolyKinds, DataKinds, TypeOperators, GADTs #-} module S2 where import Language.Haskell.TH data Proxy a = Proxy data SList :: [k] -> * where SCons :: Proxy h -> Proxy t -> SList (h ': t) dec :: Q [Dec] dec = [d| foo :: forall (a :: k). Proxy a -> forall (b :: [k]). Proxy b -> SList (a ': b) foo a b = SCons a b |] foo' :: forall (a :: k). Proxy a -> forall (b :: [k]). Proxy b -> SList (a ': b) foo' a b = SCons a b }}} Note that `foo` and `foo'` are identical, just at different compilation stages. However, the following module does not compile: {{{ {-# LANGUAGE TemplateHaskell, DataKinds, PolyKinds, RankNTypes #-} module S3 where import S2 $(dec) }}} The error is {{{ S3.hs:7:3: Couldn't match kind ‛k’ with ‛k1’ ‛k’ is a rigid type variable bound by the type signature for foo :: Proxy k a0 -> forall (k1 :: BOX) (b0 :: [k1]). Proxy [k1] b0 -> SList k1 ((':) k1 a0 b0) at S3.hs:7:3 ‛k1’ is a rigid type variable bound by the type signature for foo :: Proxy k a0 -> Proxy [k1] b -> SList k1 ((':) k1 a0 b) at S3.hs:7:3 Expected type: SList k1 ((':) k1 a0 b) Actual type: SList k ((':) k a0 b) Relevant bindings include foo :: Proxy k a0 -> forall (k1 :: BOX) (b0 :: [k1]). Proxy [k1] b0 -> SList k1 ((':) k1 a0 b0) (bound at S3.hs:7:3) a_aTCB :: Proxy k a0 (bound at S3.hs:7:3) b_aTCC :: Proxy [k1] b (bound at S3.hs:7:3) In the expression: SCons a_aTCB b_aTCC In an equation for ‛foo’: foo a_aTCB b_aTCC = SCons a_aTCB b_aTCC }}} If I change the nested `forall`s in the definition of `foo` to be just one top-level `forall`, the problem goes away. This may seem terribly esoteric, but it's easier to generate nested `forall`s than to float them all to the top-level after processing a type. I received an email requesting that I get the `singletons` library to compile with HEAD, and this seems to be why it doesn't. This is a regression error: the code compiles fine with 7.6.3 but not with HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1593: Improve runInteractiveProcess error message when working directory does not exist
by GHC 03 Jul '13

03 Jul '13

#1593: Improve runInteractiveProcess error message when working directory does not exist ----------------------------------------+----------------------------------- Reporter: tomasz.zielonka@… | Owner: simonmar Type: task | Status: closed Priority: low | Milestone: _|_ Component: libraries/process | Version: 6.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: process004 | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Yes; we now get: {{{ q: echo: runInteractiveProcess: runInteractiveProcess: chdir: does not exist (No such file or directory) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1593#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error
by GHC 03 Jul '13

03 Jul '13

#7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error --------------------------------+------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC 7.7.20130526 for Windows x86_64 fails with the following error: {{{ "inplace/bin/ghc-stage1.exe" -static -optc-DDEBUG -ticky -DTICKY_TICKY -O -H256m -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.debug_o Cmm lint error: in basic block cf in MachOp application: I32[ALLOC_PRIM_adm] + (8 + 8) op is expecting: [W32, W32] arguments provide: [I32, I64] Program was: {offset cc: _cd::I64 = R1; if (I64[CurrentNursery + 16] == 0) goto cg; else goto ci; ci: if (I64[I64[g0] + 56] >= %MO_SS_Conv_W32_W64(I32[large_alloc_lim])) goto cg; else goto ch; cg: HpAlloc = 0; R9 = stg_newByteArrayzh; R1 = _cd::I64; call stg_gc_prim_n(R1) args: 8, res: 0, upd: 8; ch: _cj::I64 = (_cd::I64 + 8 - 1) / 8; _cn::I64 = (8 + 8) / 8 + _cj::I64; _cm::I64 = allocate; _cl::I64 = BaseReg - 24; _ck::I64 = _cn::I64; (_ce::P64) = call "ccall" arg hints: [PtrHint,] result hints: [PtrHint] (_cm::I64)(_cl::I64, _ck::I64); I32[ALLOC_PRIM_ctr] = I32[ALLOC_PRIM_ctr] + 1 :: W32; I32[ALLOC_PRIM_adm] = I32[ALLOC_PRIM_adm] + (8 + 8); I32[ALLOC_PRIM_gds] = I32[ALLOC_PRIM_gds] + _cj::I64 * 8; I32[ALLOC_PRIM_slp] = I32[ALLOC_PRIM_slp] + 0; I64[_ce::P64] = stg_ARR_WORDS_info; I64[_ce::P64 + 8 + 0] = _cd::I64; R1 = _ce::P64; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } <no location info>: Compilation had errors }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #8026: DatatypeContexts should be fixed, not deprecated
by GHC 03 Jul '13

03 Jul '13

#8026: DatatypeContexts should be fixed, not deprecated -----------------------------+---------------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- To borrow an example from the [http://hackage.haskell.org/trac/haskell- prime/wiki/NoDatatypeContexts prime wiki page], the following code fails to compile: {{{ data Eq a => Foo a = Foo a isEq :: Foo a -> Foo a -> Bool isEq (Foo x) (Foo y) = x == y }}} We have to tell the compiler that {{{Eq a => Foo a}}} in {{{isEq}}}, even though this is part of the data type's definition. Furthermore, {{{ getVal :: Foo a -> a getVal (Foo x) = x }}} will also fail because of the missing constraint, even though it isn't used in the function's definition. Rather than just deprecating the {{{DatatypeContexts}}} extension, it should be "fixed" to remember the context wherever the data type is used. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #1593: Improve runInteractiveProcess error message when working directory does not exist
by GHC 03 Jul '13

03 Jul '13

#1593: Improve runInteractiveProcess error message when working directory does not exist ----------------------------------------+----------------------------------- Reporter: tomasz.zielonka@… | Owner: simonmar Type: task | Status: new Priority: low | Milestone: _|_ Component: libraries/process | Version: 6.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: process004 | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Changes (by simonmar): * cc: igloo (added) Comment: @igloo: this is fixed now, right? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1593#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8034: Missing ambiguity test for class methods
by GHC 03 Jul '13

03 Jul '13

#8034: Missing ambiguity test for class methods ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ If you write {{{ type family F a foo :: F a -> F a foo = ... }}} then `foo` is rejected as having an ambiguous type. But if instead you write {{{ class C a where type F a foo :: F a -> F a }}} no such test is made. That's inconsistent, and leads to downstream errors (see #8030 for example). Better to do an ambiguity test. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8032: Worker-wrapper transform triggers bad reboxing behavior
by GHC 03 Jul '13

03 Jul '13

#8032: Worker-wrapper transform triggers bad reboxing behavior ------------------------------------+--------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- When we worker-wrapper transform functions, we tend to be to eager to unbox all of our arguments and pass them to the worker. This backfires when the boxed version of the argument is needed: {{{ module Gnam where data KST = KST { ke :: {-# UNPACK #-} !Int , ka :: {-# UNPACK #-} !Int } data KStop r = KNeedInput Int !(KC r) data Result r = Result r type KC r = KST -> Int -> Result r newtype K r a = K { unK :: (KST -> KStop r -> Result r) -> KC r } skipWhileK :: K () () skipWhileK = K $ \kf kst@KST{ ke = e } i0 -> let loop i rw0 -- Note: removing rw0 argument gets rid of re-boxing behavior | i < e = loop (i + 1) rw0 | otherwise = unK recurse kf kst i in loop i0 (0 :: Int) where -- Note that without NOINLINE, we get an unnecessary eager -- closure allocation even when closure is never used. This -- is unfortunate because recurse is the slow path (e.g., -- called 1/4000 of the time in the real code). {-# NOINLINE recurse #-} recurse = K $ \kf kst i -> kf kst $ KNeedInput i $ unK skipWhileK kf }}} skipWhileK is an important loop which we would like to avoid performing heap allocation on. However, this code is compiled by HEAD with an allocation which reboxes KST: {{{ Gnam.$wa :: (Gnam.KST -> Gnam.KStop () -> Gnam.Result ()) -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> Gnam.Result () [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType <C(C(S)),U><L,U><L,U><L,U>, Unf=OtherCon []] = \r srt:SRT:[] [w_srG ww_srz ww1_srA ww2_srK] let { wild_srB :: Gnam.KST [LclId, Str=DmdType, Unf=OtherCon []] = NO_CCS Gnam.KST! [ww_srz ww1_srA]; } in ... }}} The worker function takes i and the unboxed KST as arguments, as one might hope, but when it discovers that it needs KST on the inside, it has no choice but to reconstruct KST inside. What should be done instead is wild_srB (produced by the case analysis on KST here: {{{ \r srt:SRT:[] [w_srV w1_srO w2_srS] case w1_srO of _ { // <--- wild_ here please! Gnam.KST ww1_srW ww2_srX -> case w2_srS of _ { GHC.Types.I# ww4_srY -> Gnam.$wa w_srV ww1_srW ww2_srX ww4_srY; }; }; }}} This is perhaps a tradeoff: passing the evaluated version of things that were unpacked costs an extra argument; however, unboxing things can result in a lot of extra arguments! (And GHC doesn't seem to eliminate unused arguments, even when the rebox is not necessary.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8030: FlexibleContexts PolyKinds Type Families bug
by GHC 02 Jul '13

02 Jul '13

#8030: FlexibleContexts PolyKinds Type Families bug --------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- A bug with TypeFamilies + FlexibleContexts + PolyKinds {{{ {-# LANGUAGE PolyKinds, FlexibleContexts, TypeFamilies #-} class Monoid (a :: k) where type Pr a :: * mempty :: Pr a mappend :: Pr a -> Pr a -> Pr a instance Monoid [b] where type Pr [b] = [b] mempty = [] mappend = (++) }}} This is compilable. But this is not: {{{ t :: (Monoid [b]) => b -> [b] t b = [b] `mappend` mempty }}} {{{ Could not deduce ([b] ~ Pr k0 a0) from the context (Monoid * [b]) bound by the type signature for t :: Monoid * [b] => b -> [b] at t.hs:26:6-29 The type variables `k0', `a0' are ambiguous Possible fix: add a type signature that fixes these type variable(s) In the expression: [b] `mappend` mempty In an equation for `t': t b = [b] `mappend` mempty Could not deduce (Pr k1 a1 ~ [b]) from the context (Monoid * [b]) bound by the type signature for t :: Monoid * [b] => b -> [b] at test4.hs:26:6-29 The type variables `k1', `a1' are ambiguous Possible fix: add a type signature that fixes these type variable(s) Expected type: Pr k0 a0 Actual type: Pr k1 a1 In the second argument of `mappend', namely `mempty' In the expression: [b] `mappend` mempty In an equation for `t': t b = [b] `mappend` mempty }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1