May 2013 - ghc-tickets

[GHC] #7912: Missing symbols from termios.h when linking on Android
by GHC 15 May '13

15 May '13

#7912: Missing symbols from termios.h when linking on Android --------------------------------+------------------------------------------- Reporter: neurocyte | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 7.7 | Keywords: Android Os: Other | Architecture: arm Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- The Bionic libc that is used on Android defines the symbols in termios.h inline. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7911: The following code makes ghc panic
by GHC 15 May '13

15 May '13

#7911: The following code makes ghc panic -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This code has a bug (lowercase show instead of uppercase Show), but it shouldn't make the compiler crash. {{{ {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, FlexibleContexts, UndecidableInstances #-} data Person = SnowWhite | Dwarf Int deriving (show, Eq, Ord) }}} Result: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.2 for i386-unknown-mingw32): nameModule show{tv avGJ} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 15 May '13

15 May '13

#4210: LLVM: Dynamic Library Support ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dterei): No more progress. If anything, perhaps things have regressed as I haven't looked at dynlib support in LLVM for a fair while. If status is the same though I don't know how much it is worth worrying about supporting 32bit. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4210#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 15 May '13

15 May '13

#4210: LLVM: Dynamic Library Support ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by carter): has more progress been made on this ticket? Or whats still needed? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4210#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7908: InstanceSigs suggestion not accepted
by GHC 14 May '13

14 May '13

#7908: InstanceSigs suggestion not accepted -----------------------------+---------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Attached testcase compiles, but when uncommenting either of the lines 19, 21 or 23, I get an error: {{{ pr7908.hs:23:12: Method signature does not match class; it should be (>>-) :: forall (c :: k -> *) d. Hidden k c -> (forall (a :: k). c a -> d) -> d In the instance declaration for `Monad' k (Hidden k)' Failed, modules loaded: none. }}} But in fact I basically copied the suggestion into my file! (with slight modification "Hidden k c" --> "Hidden c") This may be because of the rank2 type or because of the polykinds appearing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 13 May '13

13 May '13

#910: --make should have a -j flag for parallel building -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: N/A | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/910#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7043: 32-bit GHC ceiling of negative float SEGFAULT: 11
by GHC 13 May '13

13 May '13

#7043: 32-bit GHC ceiling of negative float SEGFAULT: 11 ------------------------------------------------------+--------------------- Reporter: DrGodCarl | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: Segfault, ceiling, segmentation fault | Os: MacOS X Architecture: Other | Failure: GHCi crash Difficulty: Unknown | Testcase: arith005(ghci), num010(ghci) Blockedby: 3658 | Blocking: Related: | ------------------------------------------------------+--------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7043#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7831: Bad fragmentation when allocating many large objects
by GHC 13 May '13

13 May '13

#7831: Bad fragmentation when allocating many large objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider our good old friend, the space-leaky list program: {{{ import Control.Exception import System.Environment f n = let xs = [1..n] in sum xs * product xs main = do [n] <- getArgs evaluate (f (read n :: Integer)) }}} It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program: {{{ Fragmentation, wanted 95 blocks, 105 MB free }}} (For reference, a block is 4k, so 95 blocks is a measly 380k!) The magnitude of the problem can be seen in this graphic: [[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]] (The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.) When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations. Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word "fragmentation" in them). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7890: Static linking of GHC 7.7 does not work correctly
by GHC 12 May '13

12 May '13

#7890: Static linking of GHC 7.7 does not work correctly ------------------------------------+--------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- "cabal install" with ghc-7.7.20130504 fails on Linux. One example: {{{ % cabal install yesod Preprocessing library lifted-base-0.2.0.5... [1 of 6] Compiling System.Timeout.Lifted ( System/Timeout/Lifted.hs, dist/build/System/Timeout/Lifted.o ) [2 of 6] Compiling Data.IORef.Lifted ( Data/IORef/Lifted.hs, dist/build/Data/IORef/Lifted.o ) [3 of 6] Compiling Control.Concurrent.Chan.Lifted ( Control/Concurrent/Chan/Lifted.hs, dist/build/Control/Concurrent/Chan/Lifted.o ) [4 of 6] Compiling Control.Concurrent.MVar.Lifted ( Control/Concurrent/MVar/Lifted.hs, dist/build/Control/Concurrent/MVar/Lifted.o ) [5 of 6] Compiling Control.Exception.Lifted ( Control/Exception/Lifted.hs, dist/build/Control/Exception/Lifted.o ) Control/Exception/Lifted.hs:83:1: Warning: The import of ‛Monad’ from module ‛Control.Monad’ is redundant [6 of 6] Compiling Control.Concurrent.Lifted ( Control/Concurrent/Lifted.hs, dist/build/Control/Concurrent/Lifted.o ) /usr/bin/ld: cannot find -lHSmonad-control-0.3.2.1-ghc7.7.20130504 /usr/bin/ld: cannot find -lHStransformers-base-0.4.1-ghc7.7.20130504 /usr/bin/ld: cannot find -lHSbase-unicode-symbols-0.2.2.4-ghc7.7.20130504 collect2: ld returned 1 exit status cabal: Error: some packages failed to install: lifted-base-0.2.0.5 failed during the building phase. The exception was: ExitFailure 1 }}} Another example: {{{ % cabal install hlint Configuring uniplate-1.6.10... Building uniplate-1.6.10... Preprocessing library uniplate-1.6.10... [ 1 of 21] Compiling Data.Generics.Uniplate.Data.Instances ( Data/Generics/Uniplate/Data/Instances.hs, dist/build/Data/Generics/Uniplate/Data/Instances.o ) [ 2 of 21] Compiling Data.Generics.Uniplate.Internal.Utils ( Data/Generics/Uniplate/Internal/Utils.hs, dist/build/Data/Generics/Uniplate/Internal/Utils.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.2 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.3.0 ... linking ... done. Loading package text-0.11.3.1 ... <command line>: can't load .so/.DLL for: libHStext-0.11.3.1.so (libHStext-0.11.3.1.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: haskell-src-exts-1.13.5 failed during the building phase. The exception was: ExitFailure 1 hlint-1.8.44 depends on uniplate-1.6.10 which failed to install. uniplate-1.6.10 failed during the building phase. The exception was: ExitFailure 1 }}} But "cabal install --enable-shared" works well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7841: Stage1Only conditional program/package building
by GHC 11 May '13

11 May '13

#7841: Stage1Only conditional program/package building -----------------------------+---------------------------------------------- Reporter: elliottt | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Stage1Only Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This patch includes changes to allow programs and packages to be disabled by stage when building GHC. == rule/build-package.mk == * Add guards for "disable-$(dir)-$(stage)" around the rule body == rule/build-prog.mk == * Add guards for "disabled-$(dir)-$(stage)" around the rule body == mk/build.mk.default == * Add a set of package disabling definitions when $(Stage1Only) is set to "YES" == rts/ghc.mk == * Add the all_rts target as a dependency for all, causing the rts to build when packages that depend on it are disabled -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5