August 2013 - ghc-tickets

[GHC] #8085: Both GHC and its installer don't run on current Debian Stable
by GHC 04 May '15

04 May '15

#8085: Both GHC and its installer don't run on current Debian Stable -------------------------------------+------------------------------------- Reporter: ppetr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC doesn't work Difficulty: Easy (less than 1 | at all hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Currently it's not possible to run GHC or its installer. It fails with: {{{ ghc: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} The problem is that the current Debian stable is Wheezy and it uses a newer version of libgmp. Proposed solution: Recompile on a recent Debian stable (Wheezy). Applies to x86_64 as well, most likely all architectures supported by Debian are affected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8057: PackageImports with versions for ghci
by GHC 06 Apr '15

06 Apr '15

#8057: PackageImports with versions for ghci ------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Imports with explicit package names and versions would be nice to have in GHCi, because you cannot use the -package and -hide-package options from within GHCi. This is what currently happens: {{{ $ ghci-7.6.3 -XPackageImports GHCi, version 7.6.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. Prelude> import Control.Monad.Trans.List <no location info>: Ambiguous module name `Control.Monad.Trans.List': it was found in multiple packages: transformers-0.3.0.0 List-0.5.1 Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List <no location info>: Could not find module `Control.Monad.Trans.List' It is not a module in the current program, or in any known package. Prelude> :q Leaving GHCi. $ ghci-7.6.3 -hide-package List GHCi, version 7.6.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. Prelude> import Control.Monad.Trans.List Prelude Control.Monad.Trans.List> }}} However, I now see that the import with explicit package name works, if I omit the package version. I think GHCi should at least warn that providing a version does not work. See also #2362 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8078: Core lint failure for profiled code
by GHC 23 Mar '15

23 Mar '15

#8078: Core lint failure for profiled code -----------------------------------+--------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: T4492 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Probably related to the cardinality changes. Here is the dump: =====> T4492(profasm) 3361 of 3686 [2, 51, 0] cd ./indexed-types/should_compile && '/srv/code/ghc-build- sandbox/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4492.hs -O -prof -static -auto-all >T4492.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of CorePrep *** {-# LINE 12 "T4492.hs #-}: Warning: [RHS of T4492.$fCMaybe_$cgo :: forall a_aex. T4492.C a_aex => forall b_ae0. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_ae0 -> a1_ae1) -> Data.Maybe.Maybe a_aex -> T4492.F (Data.Maybe.Maybe a_aex) b_ae0] Demand type has 4 arguments, rhs has 3 arguments, T4492.$fCMaybe_$cgo Binder's strictness signature: DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U> *** Offending Program *** T4492.go [InlPrag=INLINE] :: forall a_adZ. T4492.C a_adZ => forall b_ae0. (forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1) -> a_adZ -> T4492.F a_adZ b_ae0 [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType <S,U>, Unf=OtherCon []] T4492.go = \ (@ a_adZ) (tpl_sgH [Occ=Once] :: T4492.C a_adZ) -> tpl_sgH `cast` (T4492.NTCo:C[0] <a_adZ> :: T4492.C a_adZ ~# (forall b_ae0. (forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1) -> a_adZ -> T4492.F a_adZ b_ae0)) T4492.$fCMaybe1 :: forall a_aex. T4492.C a_aex => forall b_afH. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) -> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>, Unf=OtherCon []] T4492.$fCMaybe1 = \ (@ a_aex) ($dC_sgI [Occ=OnceL] :: T4492.C a_aex) (@ b_afH) (f_sgJ :: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) (a1_sgK [Occ=OnceL] :: Data.Maybe.Maybe a_aex) (b1_sgL [Occ=OnceL] :: b_afH) -> scctick<go> let { sat_sgM [Occ=Once] :: a_aex [LclId, Str=DmdType] sat_sgM = f_sgJ @ a_aex a1_sgK b1_sgL } in ($dC_sgI `cast` (T4492.NTCo:C[0] <a_aex> :: T4492.C a_aex ~# (forall b_ae0. (forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1) -> a_aex -> T4492.F a_aex b_ae0))) @ b_afH f_sgJ sat_sgM T4492.$fCMaybe_$cgo :: forall a_aex. T4492.C a_aex => forall b_ae0. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_ae0 -> a1_ae1) -> Data.Maybe.Maybe a_aex -> T4492.F (Data.Maybe.Maybe a_aex) b_ae0 [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>, Unf=OtherCon []] T4492.$fCMaybe_$cgo = (\ (@ a_aex) (eta_B3 [Occ=Once] :: T4492.C a_aex) (@ b_afH) (eta_B2 [Occ=Once] :: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) (eta_B1 [Occ=Once] :: Data.Maybe.Maybe a_aex) -> T4492.$fCMaybe1 @ a_aex eta_B3 @ b_afH eta_B2 eta_B1) `cast` (forall a_aex. <T4492.C a_aex> -> forall b_afH. <forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1> -> <Data.Maybe.Maybe a_aex> -> Sym (T4492.TFCo:R:FMaybeb[0] <a_aex> <b_afH>) :: (forall a_aex. T4492.C a_aex => forall b_afH. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) -> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH) ~# (forall a_aex. T4492.C a_aex => forall b_afH. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) -> Data.Maybe.Maybe a_aex -> T4492.F (Data.Maybe.Maybe a_aex) b_afH)) T4492.$fCMaybe [InlPrag=INLINE (sat-args=0)] :: forall a_aex. T4492.C a_aex => T4492.C (Data.Maybe.Maybe a_aex) [GblId[DFunId(nt)], Arity=3, Caf=NoCafRefs, Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>, Unf=OtherCon []] T4492.$fCMaybe = (\ (@ a_aex) (eta_B3 [Occ=Once] :: T4492.C a_aex) (@ b_afH) (eta_B2 [Occ=Once] :: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) (eta_B1 [Occ=Once] :: Data.Maybe.Maybe a_aex) -> T4492.$fCMaybe1 @ a_aex eta_B3 @ b_afH eta_B2 eta_B1) `cast` (forall a_aex. <T4492.C a_aex> -> (forall b_afH. <forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1> -> <Data.Maybe.Maybe a_aex> -> Sym (T4492.TFCo:R:FMaybeb[0] <a_aex> <b_afH>)) ; Sym (T4492.NTCo:C[0] <Data.Maybe.Maybe a_aex>) :: (forall a_aex. T4492.C a_aex => forall b_afH. (forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1) -> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH) ~# (forall a_aex. T4492.C a_aex => T4492.C (Data.Maybe.Maybe a_aex))) *** End of Offense *** <no location info>: Compilation had errors *** unexpected failure for T4492(profasm) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8150: Foreign export requires redundant type signature
by GHC 19 Mar '15

19 Mar '15

#8150: Foreign export requires redundant type signature -------------------------+------------------------------------------------- Reporter: | Owner: evincarofautumn | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With a source file such as: {{{ module FFITest where foreign export ccall "function" function :: IO () function :: IO () function = putStrLn "Hello, world!" }}} The second `function :: IO ()` signature is required to satisfy `-fwarn- missing-signatures`, even though a signature is already present in the `foreign export` declaration, and the types are required to be the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | 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: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #8100: Standalone deriving using template haskell
by GHC 01 Dec '14

01 Dec '14

#8100: Standalone deriving using template haskell ------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, there seems to be no support for standalone deriving in TemplateHaskell: {{{ Prelude Data.Typeable Language.Haskell.TH> :set -XStandaloneDeriving Prelude Data.Typeable Language.Haskell.TH> data Weird a (b :: * -> * -> *) c = Weird Prelude Data.Typeable Language.Haskell.TH> runQ $ [d| deriving instance Typeable Weird |] [] }}} ''Use case'': The library [http://hackage.haskell.org/package/typeable-th typeable-th] can already generate Typeable instances using TH for GHC 7.4 and 7.6. To add support for GHC 7.8 in a way that the user doesn't have to care about the version, there has to be a way to make Typeable instances via TH in GHC 7.8. This is currently impossible, but with StandaloneDeriving support for TH, it would be possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8046: Make the timer management scale better across multicore
by GHC 22 Nov '14

22 Nov '14

#8046: Make the timer management scale better across multicore ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- A recent commit {{{ commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8054: Undefined symbol during linking
by GHC 22 Nov '14

22 Nov '14

#8054: Undefined symbol during linking ------------------------------------+------------------------------------- Reporter: case | 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: | ------------------------------------+------------------------------------- On OSX, using GHC 7.6.3 and the package recursion-schemes 3.0.0.2, the following code causes the compiler to emit an error about undefined symbols. Code: {{{ import Data.Functor.Foldable x = project 1 :: Integer main = x `seq` return () }}} Error: {{{ λ ~/ ghc test.hs Linking test ... Undefined symbols for architecture x86_64: "_Main_x_closure", referenced from: _Main_main_info in test.o _Main_main_srt in test.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8056: Make Install fails on HEAD
by GHC 22 Nov '14

22 Nov '14

#8056: Make Install fails on HEAD ------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm trying to build the `perf` flavor of head and I'm getting an error with `make install`. The `quick` flavor works as expected. {{{ $ uname -a Linux ... 3.6.5-1.fc17.x86_64 ... $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library $ gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) ... $ git clone http://darcs.haskell.org/ghc.git/ ghc-7.8/ ... $ cd ghc-7.8 $ ./sync-all --testsuite get ... $ cp mk/build.mk.sample mk/build.mk $ vi mk/build.mk $ diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf $ perl boot ... $ ./configure --prefix=/localdisk/ryates/ghc-7.8-build/ ... $ make -j8 ... $ make install ... Installing library in /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/haskell2010-1.1.1.0 "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg" --force --global-package-db "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/package.conf.d" update rts/dist/package.conf.install /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg: symbol lookup error: /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin /ghc-pkg: undefined symbol: base_DataziList_intercalatezuzdspolyzugo_info make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1