July 2013 - ghc-tickets

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

[GHC] #8028: Panic on degenerate closed type family
by GHC 02 Jul '13

02 Jul '13

#8028: Panic on degenerate closed type family ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Creating a degenerate closed type family via TH gives a panic in `toBranchList`. {{{ module T where import Language.Haskell.TH x = do n <- newName "F" return [ClosedTypeFamilyD n [] Nothing []] }}} {{{ module A where import T $(x) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7970: Thread GC frees roots before thread actually finishes
by GHC 02 Jul '13

02 Jul '13

#7970: Thread GC frees roots before thread actually finishes -----------------------------+---------------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: 7170 -----------------------------+---------------------------------------------- In the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed: {{{ import Control.Exception as E import Data.IORef import System.Mem.Weak main :: IO () main = do ref <- newIORef 'x' weak <- mkWeakIORef ref $ putStrLn "IORef finalized" let check = deRefWeak weak >>= \m -> case m of Nothing -> putStrLn "IORef was GCed" Just ref' -> do x <- readIORef ref' putStrLn $ "IORef still alive, and contains " ++ show x let loop = loop check loop `catch` \ex -> do putStrLn $ "caught exception: " ++ show (ex :: SomeException) check readIORef ref >>= print }}} Output: {{{ IORef still alive, and contains 'x' IORef finalized caught exception: <<loop>> IORef was GCed 'x' }}} The same happens with other thread deadlocks, such as: * newEmptyMVar >>= takeMVar * atomically retry It does not happen when a `StackOverflow` or `UserInterrupt` exception is caught. This also affects `ForeignPtr`; see the attached "database" example. This is what really triggered #7170. I marked this "Runtime crash" because it can lead to a `ForeignPtr` being accessed after the garbage collector finalized it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 02 Jul '13

02 Jul '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -----------------------------+---------------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The section 4.8 of 'The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.6.3' says: {{{-fwarn-lazy-unlifted-bindings:}}} ... This will be an error, rather than a warning, in GHC 7.2. I guess the above sentence should be removed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1