May 2014 - ghc-tickets

[GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv)
by GHC 10 Jul '14

10 Jul '14

#9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------------------+------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- A patch in GHC-7.7 modified the "thread stop status" encoding, so the current ghc-events (version 0.4.2.0 from 2012) produces wrong stop reasons when reading an eventlog written by GHC-7.8.2. The GHC patch is http://git.haskell.org/ghc.git/commit/70e20631742e516c6a11c3c112fbd5b4a08c1… The MVarRead block reason was added in the middle, shifting all following block reason codes one up. The error can be observed when a thread blocks on a black hole during a program run. Attached is a small test program which produces this situation, and two event logs for the same program run with the same arguments and RTS parameters. The program's two threads evaluate the same data, the parent thread typically blocks on a blackhole created by a forked child thread. Note the sequence around user event "child": The log written by GHC-7.6.3 correctly shows blocking on a black hole, while the log written by GHC-7.8.2 claims the main thread blocks "on I/O read". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9023: Error when using empty record update on binary pattern synonym
by GHC 03 Jul '14

03 Jul '14

#9023: Error when using empty record update on binary pattern synonym --------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+--------------------------------- Using an empty record update with patterns works here {{{ pattern Singleton a = [a] isSingleton :: [a] -> Bool isSingleton Singleton{} = True isSingleton _ = False }}} but fails in the follow example (there may exist a more minimal example) {{{ pattern P a b = Just (a, b) foo P{} = True }}} which outputs (GHC 7.8.2) {{{ $ ghci -ignore-dot-ghci tmp.g2WZtTUkhJ.hs GHCi, version 7.8.2: 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 1] Compiling Main ( tmp.g2WZtTUkhJ.hs, interpreted ) Var/Type length mismatch: [t{tv aIW} [sk]] [] Ok, modules loaded: Main. *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9018: GHC suppresses too much kind information
by GHC 03 Jul '14

03 Jul '14

#9018: GHC suppresses too much kind information ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC tends to hide important kind polymorphism in error messages and in GHCi. (I came across this when looking at #9017.) For example, try this: {{{ bash$ cat Test.hs {-# LANGUAGE PolyKinds #-} module Test where foo :: m a foo = foo bash$ ghci Test.hs ghci> :t foo foo :: m a ghci> :i foo foo :: m a bash$ ghci Test.hs -XPolyKinds ghci> :t foo foo :: m a ghci> :i foo goo :: m a bash$ ghci Test.hs -fprint-explicit-foralls -fprint-explicit-kinds ghci> :t foo foo :: foo :: forall (m :: * -> *) d. m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d bash$ ghci Test.hs -XPolyKinds -fprint-explicit-foralls -fprint-explicit- kinds ghci> :t foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d }}} Pretty confusing eh? * Without `-fprint-explicit-foralls -fprint-explicit-kinds` you don't see the kinds on the types at all. * Without `-XPolyKinds` in GHCi, when you say `:t foo` you are asking for the type of the expression `foo` (it could be an arbitrary expression). So `foo` is instantiated and then re-generalised; but without `-XPolyKinds` we don't get a poly-kinded type. Hence the difference in what is printed by `:type` and `:info`. Here's a proposal: even without `-fprint-explicit-foralls`, we should print any foralls that bind a type variable whose kind includes a kind variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module
by GHC 03 Jul '14

03 Jul '14

#9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -----------------------------------+--------------------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- == Mu in the same file == ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where newtype Mu f = Mu (f (Mu f)) newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 1] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:7:37: No instance for (Functor Mu) arising from the first field of ‘F’ (type ‘Mu (K a)’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Functor F) }}} == Mu in a separate file == ''src/Mu.hs'' {{{ module Mu where newtype Mu f = Mu (f (Mu f)) }}} ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where import Mu newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 2] Compiling Mu ( src/Mu.hs, dist/build/panic/panic- tmp/Mu.o ) [2 of 2] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:8:37:ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Prelude.(!!): index too large Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object)
by GHC 02 Jul '14

02 Jul '14

#9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This happens in a clean sandbox: {{{ % cabal install -j --enable-library-coverage logict Resolving dependencies... Notice: installing into a sandbox located at /home/feuerbach/tmp/sandboxes/smallcheck-bug/.cabal-sandbox Configuring mtl-2.1.3.1... Building mtl-2.1.3.1... Installed mtl-2.1.3.1 Configuring logict-0.6.0.2... Building logict-0.6.0.2... Failed to install logict-0.6.0.2 Last 10 lines of the build log ( /home/feuerbach/tmp/sandboxes/smallcheck- bug/.cabal-sandbox/logs/logict-0.6.0.2.log ): Configuring logict-0.6.0.2... Building logict-0.6.0.2... Preprocessing library logict-0.6.0.2... [1 of 2] Compiling Control.Monad.Logic.Class ( Control/Monad/Logic/Class.hs, dist/dist-sandbox- cdfcc6f0/build/Control/Monad/Logic/Class.o ) [2 of 2] Compiling Control.Monad.Logic ( Control/Monad/Logic.hs, dist /dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.o ) /usr/bin/ld: dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.dyn_o: relocation R_386_GOTOFF against undefined symbol `_hpc_tickboxes_mtlzm2zi1zi3zi1_ControlziMonadziReaderziClass_hpc' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: logict-0.6.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion
by GHC 02 Jul '14

02 Jul '14

#8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion ------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Keywords: fusion | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4218 | ------------------------------------+------------------------------------- randoms, randomRs could take advantage of list fusion. A commit is attached for consideration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9102: Assertion failure in CoreUtils.lhs
by GHC 02 Jul '14

02 Jul '14

#9102: Assertion failure in CoreUtils.lhs ------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I happened to be using a debug build of ghc-7.8.2, and got this assertion failure compiling [http://hackage.haskell.org/package/fclabels-2.0.1 fclabels]. {{{ [ 7 of 10] Compiling Data.Label.Total ( src/Data/Label/Total.hs, dist/build/Data/Label/Total.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140429 for x86_64-unknown-linux): ASSERT failed! file compiler/coreSyn/CoreUtils.lhs line 194 coercion Nth:0 dt{v d7gF} [lid] passed to mkCast base:Control.Category.id{v rkl} [gid[ClassOp]] @ ghc- prim:GHC.Prim.*{(w) tc 34d} @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} (base:Control.Arrow.$p1Arrow{v r1s} [gid[ClassOp]] @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} (base:Control.Arrow.$p1ArrowApply{v rp} [gid[ClassOp]] @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} $dArrowApply{v a72o} [lid])) @ f{tv a8m6} [tv] f{v a8hw} [lid] has wrong role nominal }}} Problem does not appear with `-O0`. I couldn't test with HEAD because fclabels isn't compatible with the changes to Template Haskell yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error
by GHC 02 Jul '14

02 Jul '14

#9085: Inaccessible equations in a closed type family should be a warning, not an error ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I say {{{ foo _ = () foo False = () }}} I get {{{ /Users/rae/temp/Bug.hs:2:1: Warning: Pattern match(es) are overlapped In an equation for ‘foo’: foo False = ... }}} But, if I say {{{ {-# LANGUAGE TypeFamilies #-} type family Foo a where Foo x = () Foo Bool = () }}} I get {{{ /Users/rae/temp/Bug.hs:5:3: Inaccessible family instance equation: Foo Bool = () In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} If this issues a warning at the term level, it probably should do the same at the type level. This was my design decision that I'm changing, and I will fix. The warning will be controlled by the same flag that controls the term-level version. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling
by GHC 02 Jul '14

02 Jul '14

#8787: compiler/ghc.mk: restore GhcHcOpts variable handling ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- wiki and mk/config.mk.in suggests setting GhcHcOpts for compiler-wide haskell flags. But it does not work for a while now. Proposed patch fixes it. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8993: Fold NullaryTypeClasses into MPTC
by GHC 01 Jul '14

01 Jul '14

#8993: Fold NullaryTypeClasses into MPTC ------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- NullaryTypeClasses are an instance of MultiParamTypeClasses, so make it so. Suggested by Austin [http://www.reddit.com/r/haskell/comments/22lw1b/ghc_781_released/cgoi79c on reddit] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11