April 2014 - ghc-tickets

[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

[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] #8883: FlexibleContexts checking should happen also on inferred signature
by GHC 30 Jun '14

30 Jun '14

#8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------+------------------------------------- Reporter: Blaisorblade | 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 assume that if a program typechecks, adding any missing top-level signature inferred by GHC should be a meaning-preserving transformation and yield a new program which typechecks. (Please correct me if I'm wrong). But I've found a violation: namely, given enough other extensions (I think TypeFamilies is the relevant one), GHC will infer signatures which would require FlexibleContexts! Arguably, either those signatures should be rejected in the first place with a special error message (since GHC is not supposed to show code the user didn't write in error messages), or TypeFamilies should imply FlexibleContexts (or a restricted form which is sufficient for what TypeFamilies produces - namely, constraints can contain type families in place of raw type variables). Here's an example - without FlexibleContexts it does not typecheck , unless you comment out the signature of fold and unfold. Those signatures where produced by GHCi (with :browse) in the first-place. {{{#!haskell {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} -- , FlexibleContexts data Fix f = In { out :: f (Fix f) } data Expr = Const Int | Add Expr Expr data PFExpr r = ConstF Int | AddF r r deriving Functor type Expr' = Fix PFExpr class Regular0 a where deepFrom0 :: a -> Fix (PF a) deepTo0 :: Fix (PF a) -> a type family PF a :: * -> * type instance PF Expr = PFExpr instance Regular0 Expr where deepFrom0 = In . (\expr -> case expr of Const n -> ConstF n Add a b -> AddF (deepFrom0 a) (deepFrom0 b)) deepTo0 = (\expr' -> case expr' of ConstF n -> Const n AddF a b -> Add (deepTo0 a) (deepTo0 b)) . out class Regular a where from :: a -> PF a a to :: PF a a -> a instance Regular Expr where from expr = case expr of Const n -> ConstF n Add a b -> AddF a b to expr' = case expr' of ConstF n -> Const n AddF a b -> Add a b -- But in fact, the construction is just an instance of fold. fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b unfold :: (Functor (PF b), Regular b) => (a -> PF b a) -> a -> b fold f = f . fmap (fold f) . from unfold f = to . fmap (unfold f) . f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[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] #8972: Investigate adding fast compare-and-swap Int type/primops
by GHC 24 Jun '14

24 Jun '14

#8972: Investigate adding fast compare-and-swap Int type/primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've received reports that using `IORef Int` and `atomicModifyIORef` to implement an atomic counter in the ekg package has become a bottleneck for some of its users. These users update the counter thousands of times per second, using multiple threads. I will investigate whether adding a dedicated atomic `Int` reference type will offer significant speed improvements. Such a type can also be used to implement cheaper locks (by using bits in the int to represent different lock states, such as reader/write locks.) Lets call this new type `AtomicIntRef` for now. This new type needs to support at least these functions: {{{#!haskell add :: AtomicIntRef -> Int -> IO Int set :: AtomicIntRef -> Int -> IO () get :: AtomicIntRef -> IO Int }}} `add` would be implemented using the `lock` and `xaddq` instructions. `set` and `get` are just simple loads and stores on x86, as these are atomic. We might also want to consider having other functions, such as a `cas`. Furthermore, there are subtleties with memory barriers that might motivate having barrier/barrier-less versions of some functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9047: Testsuite fails on OS X Mavericks
by GHC 24 Jun '14

24 Jun '14

#9047: Testsuite fails on OS X Mavericks ------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Perhaps this is already well-known, but the testsuite utterly fails on Mavericks. Most tests fail because of extra output from clang. Here is a representative: {{{ Actual stderr output differs from expected: --- ./tcfail188.stderr 2014-02-07 15:28:16.000000000 -0500 +++ ./tcfail188.comp.stderr 2014-04-28 14:37:03.000000000 -0400 @@ -0,0 +1,3 @@ +clang: warning: argument unused during compilation: '-fno-stack- protector' +clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' +clang: warning: argument unused during compilation: '-I .' *** unexpected failure for tcfail188(normal) }}} Is this a local setting problem? Or is this something that can be fixed centrally? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #8753: Import constructor but not the data type
by GHC 09 Jun '14

09 Jun '14

#8753: Import constructor but not the data type ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (A) defines a parametrized data type (D a) which I want to use in my code (B) in instantiated form (D Int) but with the same name (D). I want to pattern match against inhabitants of type D, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "D". module A where data D a = D a module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11