- ghc-tickets - Haskell.org

[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] #8023: dph-examples binaries don't use all CPUs
by GHC 29 Jun '13

29 Jun '13

#8023: dph-examples binaries don't use all CPUs ------------------------------------+--------------------------------------- Reporter: Lethalman | Owner: Type: bug | Status: new Priority: normal | Component: Data Parallel Haskell Version: 7.6.3 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: 7330 Blocking: | Related: ------------------------------------+--------------------------------------- Hi, I've run dph-spectral-quicksort 3000000 +RTS -N6 of dph-examples-0.7.0.5 but it doesn't seem to use all the 6 hyperthreads. You can see the system monitor attached. Same goes for the other quickhull-vector example. ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 llvm-config-3.0 --version 3.0 What am I possibly doing wrong? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 28 Jun '13

28 Jun '13

#7858: Fix definitions of abs/signum for Floats/Doubles -----------------------------+---------------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: floating point Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The current definition of abs doesn't work correctly for -0.0 (negative zero); and the signum function doesn't return NaN on NaN. The issue is discussed in detail in the following thread: http://www.haskell.org/pipermail/libraries/2013-April/019677.html To summarize, the proposal is to change both the Float and Double instance definitions for signum/abs as follows: {{{ signum x | x == 0 = x | isNaN x = x | x > 0 = 1 | otherwise = negate 1 abs x | isNegativeZero x = 0 | x >= 0 = x | otherwise = negate x }}} Simon PJ expressed interest in taking advantage of the underlying platforms floating-point instructions when available to speed things up, and the above referenced thread has some discussion regarding how this might be done. However, it might be best to start with a "correct" implementation first, and then later worry about speed. On a related note, this "bug" is actually present in the Haskell'98 standard definition itself, which seems to have overlooked NaN's and negative-0's. It'd be great if the standard got a similar amendment as well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 1

[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] #8020: Closed type families break substitution
by GHC 28 Jun '13

28 Jun '13

#8020: Closed type families break substitution -----------------------------+---------------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This code causes a Core Lint error: {{{ {-# LANGUAGE TypeFamilies #-} type family F a b where F (Maybe a) [a] = Int F b c = Bool data Proxy a = P type family G foo :: Proxy d -> F d d -> Bool foo _ = not bar :: Bool -> Bool bar = foo (P :: Proxy G) }}} The solution needs to freshen variables before doing apartness checking. I will fix in due course. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8019: Can't match type `1+0` with `1`. (TypeNats addition doesn't reduce)
by GHC 28 Jun '13

28 Jun '13

#8019: Can't match type `1+0` with `1`. (TypeNats addition doesn't reduce) --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: TypeNats, addition Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Here are two examples illustrating my problem: (test2 and test3 produce the errors when the line that don't work are uncommented) This is a file: --file: Scratch.hs {-# Language DataKinds, KindSignatures, TypeOperators #-} import GHC.TypeLits test1 = sing :: Sing (1) --works --test2 = sing :: Sing (1+0) --doesn't data F (n::Nat) = F () f :: F n -> F n -> () f _ _ = () x = F () :: F (1) --works --x = F () :: F (1+0) --doesn't y = F () :: F (1) test3 = f x y -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4385: Type-level natural numbers
by GHC 28 Jun '13

28 Jun '13

#4385: Type-level natural numbers ----------------------------------------+----------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by guest): Is there a way to make the following work? Couldn't match type `1 + 0' with `1' Here is a test to reproduce this. (test2 and test3 produce the errors when the line that don't work are uncommented) This is a file: --file: Scratch.hs {-# Language DataKinds?, KindSignatures?, TypeOperators? #-} import GHC.TypeLits? test1 = sing :: Sing (1) --works --test2 = sing :: Sing (1+0) --doesn't data F (n::Nat) = F () f :: F n -> F n -> () f _ _ = () x = F () :: F (1) --works --x = F () :: F (1+0) --doesn't y = F () :: F (1) test3 = f x y -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4385#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8018: GHC hangs with recursive dependency in closed type family
by GHC 28 Jun '13

28 Jun '13

#8018: GHC hangs with recursive dependency in closed type family -----------------------------+---------------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code hangs GHC: {{{ {-# LANGUAGE TypeFamilies #-} data Foo a = Bar (F a) type family F a where F (Foo a) = Bool }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD
by GHC 28 Jun '13

28 Jun '13

#8013: Strange closure type error building hs-kqueue on FreeBSD -------------------------------+-------------------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.3 | Keywords: Os: FreeBSD | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Trying to compile hs-kqueue on FreeBSD 9.1 from the port fails with the following error: {{{ c2hs: internal error: evacuate(static): strange closure type -385875968 (GHC version 7.6.3 for x86_64_portbld_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've attached the full log from the build in case it's useful. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt
by GHC 28 Jun '13

28 Jun '13

#8006: Asynchronous exception rethrown synchronously inside runStmt -----------------------------+---------------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This bug is related to various bugs to do with asynchronous exceptions [http://hackage.haskell.org/trac/ghc/ticket/3997] [http://hackage.haskell.org/trac/ghc/ticket/5902] as well as the request for a means to terminate a code snippet started with `runStmt` [http://hackage.haskell.org/trac/ghc/ticket/1381] The only means to terminate such a snippet is to send an asynchronous exception to the thread that executed the `runStmt` (while, in versions of ghc prior to Simon M's patch listed in 1381, making sure that sandboxing is disabled). The problem with this approach is that this exception might interrupt the *typechecker* instead of the snippet. This is problematic, because a relatively large part of the typechecker runs inside a call to `unsafeInterleaveIO`, through a call to `forkM` or `forkM_maybe` from * `loadDecl` in `compiler/iface/LoadIFace.lhs` [[BR]] * `tc_iface_decl`, `tcIfaceDataCons`, `tcIfaceInst`, `tcIfaceFamInst`, `tcIfaceRule`, `tcIfaceVectInfo`, `tcUnfolding`, `tcIfaceWrapper`, `tcPragExpr`, `tcUnfolding`, `tcIfaceWrapper` and `tcPragExpr` in `compiler/iface/TcIFace.lhs` [[BR]] If the asynchronous exception is caught inside `unsafeInterleaveIO` and rethrown synchronously (typically implicitly through a call to `try` or `catch` that only catches exceptions of a certain type -- specifically `IOEnvFailure` in this case) then this exception becomes the value of the thunk and any subsequent attempt to poke that thunk will rethrow the exception. The attached test case illustrates this. After some minimal set up, we repeatedly use `runStmt` to execute a snippet which simply waits for 1 second. Before we do this, we fork a thread which waits a random delay between 0 and 0.1 seconds, and then sends an asynchronous exception to the main thread. We catch this exception, make sure it's the exception we're expecting, and repeat. On every iteration we throw a different exception; however, when we run the code we will get {{{ Unexpected exception CountedThreadKilled 4 Expected (CountedThreadKilled 8) }}} or similar output. In other words, we are catching an *old* exception, that we threw and caught earlier. This must be because this exception has become the value of a thunk, either inside `unsafePerformIO` or `unsafeInterleaveIO` -- and so far the only candidate I have found is the `unsafeInterleaveIO` inside `forkM_maybe`. So this leaves us with two questions: 1. Are there other (relevant) places where `unsafePerformIO` or `unsafeInterleaveIO` are used? I ''think'' the answer to this is is no, but I am not sure. 2. Where do we catch and rethrow exceptions? Unfortunately, question 2 is more difficult to answer. The function `tryM` (`compiler/utils/IOEnv.hs`) wraps around `try`, but it in turn gets wrapped in lots of places: `recoverM`, `recoverTR`, `tryTcErrs`, `checkNoErrs` (this one is used a lot), `mapAndRecoverM` (also used frequently), `tryTc` and `runPlans`. There is a call to `tryM` directly inside the `unsafeInterleaveIO` in `forkM_maybe`, so that's an obvious candidate. However, as an experiment, I replaced the `tryM` with `tryAllM` (not really a solution, as discussed below) and re-ran the tests, and it was still failing in a similar way. This means that this `tryM` cannot be the only culprit, because with this change `forkM` will "re"throw all exceptions as an `GhcException`, never as the original exception (certainly not as the custom exception type that the test is using). Since we were still getting our custom exception, this must have been rethrown elsewhere. Unfortunately `tryM` or one of its variants gets called in lots of places: * `initDs` in `compiler/deSugar/DsMonad.lhs` [[BR]] * `dataConInfoPtrToName` in `compiler/ghci/DebuggerUtils.hs` [[BR]] * `addConstraint`, `cvObtainTerm`, `cvReconstructType` and `congruenceNewtypes` in `compiler/ghci/RtClosureInspect.hs` [[BR]] * `tcPolyBinds`, `tcPolyInfer`, `tcSpecPrags`, `tcImpPrags` and `tcTySigs` in `compiler/typecheck/TcBinds.lhs` [[BR]] * `tcClassDecl2` in `compiler/typecheck/TcClassDcl.lhs` [[BR]] * `check_instance` in `compiler/typecheck/TcDefaults.lhs` [[BR]] * `tcDeriving`, `makeDerivSpecs` and `inferInstanceContexts` in `compiler/typecheck/TcDeriv.lhs` [[BR]] * `tc_hs_type` in `compiler/typecheck/TcHsType.lhs` * `tcInstDecls1`, `tcClsInstDecl` and `tcInstDecl2` in `compiler/typecheck/TcInstDcls.lhs` [[BR]] * `tcRnExtCore`, `tc_rn_src_decls`, `rnTopSrcDecls`, `tcUserStmt`, `tcGhciStmts`, `lookup_rdr_name` in `compiler/typecheck/TcRnDriver.lhs` [[BR]] * `initTc` in `compiler/typecheck/TcRnMonad.lhs` [[BR]] * `tcTopSplice`, `tcTopSpliceExpr`, `tcTopSpliceType`, `runMeta`, `qRecover`, `reifyInstances` in `compiler/typecheck/TcSplice.lhs` [[BR]] * `tcTyAndClassDecls`, `tcTyClGroup` and `checkValidTyCon` in `compiler/typecheck/TcTyClsDecls.lhs` Figuring out which of these may be called inside the `forkM` calls is tricky. I tried running the test with a profiled built of `ghc` with `-fprof-auto` enabled, but unfortunately I was unable to reproduce a test failure with that approach, I'm not sure why. But even if we did find the culprits, fixing it will not be easy because there is no generic solution. In `forkM_maybe` we could return `Nothing` when we catch an asynchronous exception, but then we would call `pgmError` inside `forkM` thereby rethrowing the asynchronous exception as a synchronous `GhcException`. That wouldn't solve anything. Instead, we'd have to rethrow the asynchronous exception using `throwTo`, but then we need to decide what to do after the `throwTo` returns, and that might be a rather difficult question to answer generically for all of the typechecker. Can we just re-run the `thing_inside`? Probably not, there might be all kinds of side effects; and checking for all those side effects would be quite a large task, esp given that there are so many places (list above) where we are caling `tryM` (directly through `forkM` or deeper down the call stack). I think a more realistic solution is to provide a means to detect when the snippet starts running. I outlined such a solution at http://www.haskell.org/pipermail/ghc-devs/2013-June/001380.html, but Simon M objected that this proposal might not work because there is no clear point where type checking finishes and the snippet starts executing. So far I think it would probably be easier to make sure that such a point *does* exist than to fix the asynchronous exception problem. (Note that I have adopted the solution outlined in my email and it seems to work for me, but since this bug is non-deterministic that of course doesn't mean it actually works..) However, I've run out of time to work on this for now. Might be continued. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8