May 2014 - ghc-tickets

[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] #9145: hp2ps produces odd negative sawtooth
by GHC 01 Jul '14

01 Jul '14

#9145: hp2ps produces odd negative sawtooth --------------------------+------------------------------------------------ Reporter: | Owner: blackdog | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Linux Profiling | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ i'm profiling a process with about 22gb of usage before the OOMkiller gets it. the heap profile for it is very odd: -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression)
by GHC 23 Jun '14

23 Jun '14

#9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------+------------------------------------------------- Reporter: | Owner: bergmark | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 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: | -------------------------+------------------------------------------------- Reproduction: {{{ module Log where import Prelude hiding (log) f :: () f = log where log = () }}} Compiling this with -Wall On GHC 7.8.2: {{{ > ghc Log.hs -Wall [1 of 1] Compiling Log ( Log.hs, Log.o ) Log.hs:3:1: Warning: The import of ‘Prelude’ is redundant except perhaps to import instances from ‘Prelude’ To import instances alone, use: import Prelude() }}} The suggestion is incorrect since removing the import statement gives the following warning: {{{ Log.hs:4:15: Warning: This binding for ‘log’ shadows the existing binding imported from ‘Prelude’ at Log.hs:1:8-10 (and originally defined in ‘GHC.Float’) }}} On GHC 7.6.3 the Reproduction does not give any warnings (which is correct). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9061> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE
by GHC 23 Jun '14

23 Jun '14

#9128: Possible bug in strictness analyzer when where clause declared NOINLINE -----------------------------------------+--------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strictness bytestring | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: -----------------------------------------+--------------------------------- I've encountered the following error message using a relatively straight forward library that wraps postgresql-simple in certain edge cases: {{{ *** Exception: Oops! Entered absent arg a_sYDl{v} [lid] bytestring-0.10.4.0:Data.ByteString.Internal.ByteString{tc r5T} }}} This happens on an invocation of a function, `dbSelect` under certain compilation conditions: {{{ dbSelect :: (Model a) => Connection -> DBSelect a -> IO [a] {-# INLINE #-} dbSelect conn dbs = map lookupRow <$> query_ conn q where {-# NOINLINE #-} q = renderDBSelect dbs }}} A DBSelect is just a data-structure with different `Query` (wrapper around strict bytestring) fields for clauses in a SQL select query. `renderDBSelect` generates a single `Query` value from the DBSelect (by way of contructing a Blaze.Builder as an intermediate step). When compiled with no optimizations, this works fine, no issues. With -O1, I get the error above. The errors goes away, if I compile with -fno- strictness or remove the NOINLINE *or* INLINE pragmas. We've worked around this for now in the library by removgin the NOINLINE pragmas, but tracking this down it seems like the strictness analyzer might be falsly assuming `q` is never actually evaluated. For reference, this is a commit that still exhibits the bug: https://github.com/alevy/postgresql- orm/tree/93075d56ae5ffeb8f80ecc8c01436713c2656a6b I've also attached a small test application that excercises the bug. Because of how the library sets up a scratch database, the test application requires postgres and pg_ctl to be available in the path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9096: GADT definition not accepted in prefix notation
by GHC 23 Jun '14

23 Jun '14

#9096: GADT definition not accepted in prefix notation ------------------------------------+------------------------------------- Reporter: goldfire | 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: | ------------------------------------+------------------------------------- Brian Nguyen writes on haskell-cafe: The following does not work: {{{ data Foo a where {Foo :: (->) a (Foo a)} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9115: The kind of (=>)
by GHC 23 Jun '14

23 Jun '14

#9115: The kind of (=>) ------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- This is mainly a request for clarification, and not very important. Is there any good (theoretical, implementation, practical, ...) reason why (with `ConstraintKinds`) enabled, the `=>` symbol on the type-level is still treated as a built-in syntactic construct rather than a type-level operator with {{{ GHCi> :kind (=>) (=>) :: Constraint -> * -> * }}} Note that I'm not actually proposing to make it re-definable, but to treat it similarly to the `(->)` type operator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5