December 2013 - ghc-tickets

[GHC] #8097: internal error: getMBlock: mmap: Operation not permitted
by GHC 18 Sep '14

18 Sep '14

#8097: internal error: getMBlock: mmap: Operation not permitted ------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+---------------------------------- I get the following: {{{ <interactive>: internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} when running {{{parseOnly queryKeyParse (Data.Text.pack "hello")}}} where: {{{ queryKeyParse :: Attoparsec.Parser [T.Text] queryKeyParse = do top <- Attoparsec.takeTill (=='[') keys <- many key return (top:keys) where key = many (Attoparsec.char '[') *> Attoparsec.takeTill (==']') <* many (Attoparsec.char ']') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8052: make ghci look for the files made by -dynamic-too
by GHC 03 Sep '14

03 Sep '14

#8052: make ghci look for the files made by -dynamic-too -----------------------------------+--------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- If I compile with `-dynamic-too`, ghci still re-interprets the source code instead of finding the `Test.dyn_o` file. {{{ $ inplace/bin/ghc-stage2 -O1 -dynamic-too -c Test.hs $ inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.7.20130710: 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 Test ( Test.hs, interpreted ) Ok, modules loaded: Test. *Test> }}} I'm guessing that ghci sees the `.o` file isn't suitable for dynamic loading and then falls-back to the interpreter without first checking for the `.dyn_o` file. ghci loads `Test.o` as expected if I instead compile with `-dynamic`. I'm on OS X 64-bit, if that might matter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8288: add idris style EDSL support for deep embedding lambdas
by GHC 27 Aug '14

27 Aug '14

#8288: add idris style EDSL support for deep embedding lambdas ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- I could be wrong, but I think this would actually make it much easier to write interesting EDSLs and have a native haskelly syntax. This would sort of be in the same vein as the recently requested applicative brackets idea, albeit a tad more going on . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by GHC 19 Aug '14

19 Aug '14

#8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------------+------------------------------- Reporter: jimenezrick | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Discussion in the mailing list (I fixed both commented silly issues): http://www.haskell.org/pipermail/libraries/2013-December/021756.html Please review this pull request: https://github.com/jimenezrick/unix/compare/master...file-utils.patch If you find interesting this patch, then: git pull https://github.com/jimenezrick/unix.git file-utils -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8569: ASSERT in testcase type-rep, only in some ways:
by GHC 06 Aug '14

06 Aug '14

#8569: ASSERT in testcase type-rep, only in some ways: ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: | ------------------------------------+------------------------------------- On HEAD, I currently (d55cc30658ae7c5afc0d62f3bd118fb2a5fcee40) get {{{ =====> type-rep(normal) 2696 of 3834 [0, 0, 0] =====> type-rep(hpc) 2696 of 3834 [0, 0, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(hpc) =====> type-rep(optasm) 2696 of 3834 [0, 1, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optasm) =====> type-rep(ghci) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded1) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded2) 2696 of 3834 [0, 2, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(threaded2) =====> type-rep(dyn) 2696 of 3834 [0, 3, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(dyn) =====> type-rep(optllvm) 2696 of 3834 [0, 4, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optllvm) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons
by GHC 01 Aug '14

01 Aug '14

#8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------+------------------------------------------------- Reporter: | Owner: blitzcode | 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: | -------------------------+------------------------------------------------- I encountered a 'RULE left-hand side too complicated to desugar' warning when trying to reduce some typeclass overhead through a SPECIALIZE pragma. The change I had to make to my program to make the warning go away seems rather strange, so I thought it might be worth reporting as a bug. This is the small test case I wrote to understand the problem better: {{{ {-# LANGUAGE FlexibleInstances, RankNTypes #-} module Main (main) where import Control.Monad import Control.Monad.Reader import Control.Monad.ST import Control.Applicative class (Applicative m, {- Functor m ,-} Monad m) => MonadAbstractIOST m where addstuff :: Int -> m Int type ReaderST s = ReaderT (Int) (ST s) instance MonadAbstractIOST (ReaderST s) where addstuff a = return . (a +) =<< ask runAbstractST :: (forall s. ReaderST s a) -> a runAbstractST f = runST $ runReaderT f 99 {-# SPECIALIZE INLINE useAbstractMonad :: ReaderST s Int #-} useAbstractMonad :: MonadAbstractIOST m => m Int useAbstractMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] -- useConcreteMonad :: ReaderST s Int -- useConcreteMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] main :: IO () main = do let st = runAbstractST useAbstractMonad putStrLn . show $ st }}} The use case here is simply having a library of functions which are abstracted from the underlying implementation of state (Reader / IO, Reader / ST, etc.) and operate on it with a small set of typeclass functions. This has very severe runtime overhead (~5x) compared to using the actual transformer stack directly, so a SPECIALIZE pragma seemed a good idea. The simple program above works as expected, but the warning appears as soon as the 'Functor' superclass is commented back in. It seems to me this should make no difference as Functor is already a superclass of Applicative. It was still there simply by oversight. I think SPECIALIZE should not fail in this case, and if it does, it would be really helpful to have a better error message. 'Too complicated' does not help in tracking down what needs to be changed for the specialization to happen, and given how harsh the overhead is otherwise, this is quite painful. In any case, once the specialization is applied in my actual program, the following error appears: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_saCf{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 66169 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It seems like I need a -fsimpl-tick-factor of 450-500 for the compilation to succeed, resulting in a ~3x increase in binary size and a ~4x increase in compile time. The resulting code at least seems to benefit from the specialization as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8407: Module re-exports at the package level
by GHC 26 Jul '14

26 Jul '14

#8407: Module re-exports at the package level ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | 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: | ------------------------------------+------------------------------------- For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice. I wrote up a design spec at ModuleReexports; this bug is to track the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8615: All packages built with GHC / clang are failing
by GHC 14 Jul '14

14 Jul '14

#8615: All packages built with GHC / clang are failing ------------------------------------+------------------------------------- Reporter: sylvestre | 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: | ------------------------------------+------------------------------------- I am trying to rebuild the Debian archive using clang instead of gcc. The biggest source of errors (622 over 2188 [1]) is related to GHC. Clang does not implement the "-u" option [2]. This is causing most (all?) of the "GHC based" packages to fail to build. with: {{{ /usr/lib/ghc/libHSrts.a(RtsStartup.o): In function `hs_exit_': (.text+0x49): undefined reference to `base_GHCziTopHandler_flushStdHandles_closure' }}} Of course, if you think it is not GHC's fault at all or there is no workaround, don't hesitate to close this bug. For example: http://clang.debian.net/logs/2013-07-14/agda_2.3.2.1-1_unstable_clang.log http://clang.debian.net/logs/2013-07-14/happy_1.18.10-2_unstable_clang.log [1] http://clang.debian.net/status.php?version=3.3&key=MISSING_OPTION_U [2] http://llvm.org/bugs/show_bug.cgi?id=18250 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2)
by GHC 01 Jul '14

01 Jul '14

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) ----------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- The bug is found as a crash of gf-3.4 ('Grammatical Framework') package compiled with -O2. With some debugging I've come to roughly following minimal example: This code compiles incorrectly: {{{ import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} And this works fine: {{{ --import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} Attached minimal test tarball and my results on it are: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","x86_64-pc-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/ghc-7.6.3") ,("Global Package DB","/usr/lib64/ghc-7.6.3/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory- overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] RUN good [1 of 2] Compiling Susp ( good/Susp.hs, good/Susp.o ) [2 of 2] Compiling Main ( good/main.hs, good/main.o ) Linking good/main ... (fromList [(array (0,0) [(0,42)],0)],0) RUN bad [1 of 3] Compiling BuggyOpt ( bad/BuggyOpt.hs, bad/BuggyOpt.o ) [2 of 3] Compiling Susp ( bad/Susp.hs, bad/Susp.o ) [3 of 3] Compiling Main ( bad/main.hs, bad/main.o ) Linking bad/main ... main: Error in array index; 0 not in range [0..0) TEST FAILED in bad }}} What we see here is the test with useless import mysteriously fails: > main: Error in array index; 0 not in range [0..0) while without import it works fine: > (fromList [(array (0,0) [(0,42)],0)],0) The functions in both BuggyOpt and Susp modules contain suspiciously similar code: {{{ case Map.lookup seq' seqs of Just id' -> (seqs,id') Nothing -> let last_seq = Map.size seqs in (Map.insert seq' last_seq seqs, last_seq) }}} But in BuggyOpt ghc somehow deduces some arguments and applies that effect to (unrelated, but looking similar) Susp module. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8293: user001 spuriously fails if getGroupEntryForID correctly fails
by GHC 27 Jun '14

27 Jun '14

#8293: user001 spuriously fails if getGroupEntryForID correctly fails --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.7 libraries/unix | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: user001 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ In some cases, a user's current group ID can be a number for a non- existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1