February 2013 - ghc-tickets

[GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 05 Jul '13

05 Jul '13

#7574: Register allocator chokes on certain branches with literals -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 7571, 7573 -----------------------------+---------------------------------------------- While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend: {{{ =====> T7571(normal) 6 of 6 [0, 0, 0] cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130113 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c7 }}} The test in question is: {{{ #include "Cmm.h" testLiteralBranch (W_ dst, W_ src) { if (1) { prim %memcpy(dst, src, 1024, 4); } else { prim %memcpy(dst, src, 512, 8); } return (); } }}} If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)``` I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7647: UNPACK polymorphic fields
by GHC 29 Jun '13

29 Jun '13

#7647: UNPACK polymorphic fields ------------------------------------+--------------------------------------- Reporter: liyang | Owner: simonpj Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: 3990 ------------------------------------+--------------------------------------- comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote: […] What I mean by "polymorphic unpack" is this: {{{ data Poly a = MkP Bool {-# UNPACK #-} a data Mango = MkMango {-# UNPACK #-} (Poly Int) }}} Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus: {{{ data Mango = MkMangoRep Bool Int# MkMango :: Poly Int -> MangoRep MkMango (MkP b (I# i)) = MkMangoRep b i -- Pattern match (MkMango p -> rhs) -- is transformed to (MkMangoRep b i -> let p = MkP b (I# i) in rhs }}} Something like that would be rather nice. This ticket is just a reminder. Thanks,[[br]] /Liyang -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

[GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 28 Jun '13

28 Jun '13

#7602: Threaded RTS performing badly on recent OS X (10.8?) ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime). Some results here: [http://www.haskell.org/pipermail/cvs- ghc/2011-July/063552.html] This is because the GC code relies on having fast access to thread-local state. It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X). To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly. I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details. We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it. A workaround is to install a real gcc (using homebrew?) and use that to compile GHC. Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 25

[GHC] #7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core
by GHC 21 Jun '13

21 Jun '13

#7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core -------------------------------+-------------------------------------------- Reporter: EduardSergeev | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: -fext-core panic Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to: ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): make_exp (App _ (Coercion _)) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #7678: GHC should compile cleanly with clang
by GHC 20 Jun '13

20 Jun '13

#7678: GHC should compile cleanly with clang --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: clang Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: 7602 | Related: --------------------------------+------------------------------------------- I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like: {{{ {-# RULES "thing" ... #-} }}} becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot. This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly. As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something. This currently blocks #7602 since I can't test my fix otherwise. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 8

[GHC] #7661: GHC build system does not detect opt-3.0 and friends
by GHC 19 Jun '13

19 Jun '13

#7661: GHC build system does not detect opt-3.0 and friends --------------------------------+------------------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- It is common to install LLVM tools with a version suffix (such as opt-3.0, llc-3.0, etc) so that multiple versions may co-exist. For example, the Debian package llvm-3.0 does this. It would be nice if the build system could detect such tools without needing `--with-opt`, etc, specifically. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7694: LLVM: bootstrapping with LLVM 3.2 does not work
by GHC 17 Jun '13

17 Jun '13

#7694: LLVM: bootstrapping with LLVM 3.2 does not work --------------------------------+------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 14

[GHC] #7718: ios patch no 8: adjustor pools
by GHC 09 Jun '13

09 Jun '13

#7718: ios patch no 8: adjustor pools ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- "Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime. However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that. It consists of three parts: 1. A POOLSIZE pragma, that is used like this: foreign import ccall safe "wrapper" {-# POOLSIZE 100 #-} mkDelegate :: IO () -> IO (FunPtr (IO ())) This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS. I am not sure what the procedure is for additions of pragmas. Do pragmas require {-# LANGUAGE xx #-} ? Anyway, please review whether the approach taken here is acceptable. 2. The Haskell code in the compiler to generate the stubs for the pooled adjustors. 3. The runtime system's implementation of pooled adjustors in C. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 24

[GHC] #7653: incorrect handling of StackOverflow exception in the event manager
by GHC 08 Jun '13

08 Jun '13

#7653: incorrect handling of StackOverflow exception in the event manager --------------------------+------------------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Under high pressure of `registerTimeout`s the event manager thread's stack overflows. Testcases: Shachaf initially reported this testcase on #ghc, which is irreproducible locally: {{{ import Control.Monad; import Control.Concurrent main = replicateM_ 1000000 (forkIO (threadDelay 1)) }}} to be compiled and run as follows: {{{ $ ghc -O2 -threaded Main.hs && time ./Main +RTS -N }}} Limiting the stack to the minimum helped to reproduce this locally, both on x86 and x64: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 502 (forkIO (threadDelay 1)) -- 504 on x64 }}} {{{ $ ghc -O2 -threaded -with-rtsopts="-N8 -K4" rplfrk.hs && ./rplfrk # -K8 on x64 }}} and this, though less deterministically: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 340 ( forkIO (threadDelay 1)) }}} {{{ $ ghc -O2 -threaded -rtsopts repl2-x86.hs && ./repl2-x86 +RTS -N1 -K4 }}} Error messages look like: {{{ Stack space overflow: current size 4 bytes. Use `+RTS -Ksize -RTS' to increase it. repl2-x86: sendWakeup: invalid argument (Bad file descriptor) [...repeated...] repl2-x86: ioManagerDie: write: Bad file descriptor }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #7633: Checkable "minimal complete definitions"
by GHC 08 Jun '13

08 Jun '13

#7633: Checkable "minimal complete definitions" -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 6028 -----------------------------+---------------------------------------------- #6028 suggested warning on cyclic unimplemented defaults. This doesn't work for the reasons mentioned there, among others (also e.g. [http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html /Control-Applicative.html#g:2 `Alternative`] has mutually recursive `some` and `many` methods, which shouldn't be warned about). Figuring out when to warn automatically seems hard. But Haskell already has an ad-hoc mechanism for specifying which methods need to be implemented: A "minimal complete definition" specified in the comments of almost every class definition that has optional methods. Unfortunately comments are aren't compiler-checked. It seems that the simplest solution would be to specify these in a way that the compiler can understand. The obvious approach is to add a pragma for it in the class definition. In particular, one could write a pragma for each "minimal set" of definitions, and the compiler could warn if none of them are implemented (and suggest which methods to implement). This lets us keep the convenience of default method implementations without losing safety. Without any pragmas, the compiler could fall back to the set "all methods without defaults", which is what it uses now. It might look something like this: {{{ class Functor m => Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b m >>= f = join (fmap f m) join :: m (m a) -> m a join m = m >>= id {-# MINIMAL return, join #-} {-# MINIMAL return, (>>=) #-} class Eq a where (==), (/=) :: a -> a -> Bool x == y = not (x /= y) x /= y = not (x == y) {-# MINIMAL (==) #-} {-# MINIMAL (/=) #-} }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 12