January 2014 - ghc-tickets

[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] #8646: Distinguish between update frames in rts/Printer.c
by GHC 23 Jul '14

23 Jul '14

#8646: Distinguish between update frames in rts/Printer.c ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Runtime 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: | ------------------------------------+------------------------------------- When doing printf-debugging and using Printer.c, it would be nice to see exact kind of update frame. (See attached patch) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #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] #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

[GHC] #8146: Library package cannot be found
by GHC 20 Jun '14

20 Jun '14

#8146: Library package cannot be found --------------------------------+------------------------------------------ Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ {{{ ./sync-all get warning: libffi-tarballs already present; omitting == libffi-tarballs: running git config --local core.ignorecase true warning: utils/hsc2hs already present; omitting == utils/hsc2hs: running git config --local core.ignorecase true warning: utils/haddock already present; omitting == utils/haddock: running git config --local core.ignorecase true == running git clone https://github.com/ghc/packages/array.git libraries/array Cloning into 'libraries/array'... fatal: repository 'https://github.com/ghc/packages/array.git/' not found git failed: 32768 at ./sync-all line 119. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tar ball }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8667: sync-all doesn't work properly if you run from a fork on github
by GHC 20 Jun '14

20 Jun '14

#8667: sync-all doesn't work properly if you run from a fork on github ------------------------------------+------------------------------------- Reporter: schyler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: | ------------------------------------+------------------------------------- The intuitive behaviour when working with projects on github is to make your own fork so that you can use the online interface (or GitHub for {windows,osx} apps). One would assume that this behaviour was endorsed because of the ~130 forks to the ghc repo, however forking the repo actually causes ./sync-all to stop working (it asks for a username and password to whomever@ github.com) It seems the only way for a person to work with the project from github is to clone directly from the original repo. This sounds like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8475: Library docs: broken links to Foreign.ForeignPtr
by GHC 03 Jun '14

03 Jun '14

#8475: Library docs: broken links to Foreign.ForeignPtr ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Documentation | 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: | ------------------------------------+------------------------------------- In the library docs at `http://www.haskell.org/ghc/docs/latest/html/libraries/index.html`, the `Foreign.ForeignPtr` module in the contents is the one from `haskell2010`, not `base`. This causes various problems, it seems. For instance: * the link from `ForeignPtr` to `Foreign.ForeignPtr` is broken * the link from `Foreign.Concurrent` to `Foreign.ForeignPtr` is broken there are probably other broken links too. We need to figure out what to do about overlapping modules properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11