November 2014 - ghc-tickets

[GHC] #9341: Evaluate default CPUs setting for validate
by GHC 14 Nov '14

14 Nov '14

#9341: Evaluate default CPUs setting for validate -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This is a fork off #9315:comment 16. `./validate` runs `-j2` (i.e. CPUS=1). I guess most developers these days have a stronger system that would allow for more cores to be used. This ticket should discuss if this default should changed to something higher, or possibly something dynamic. On Linux, there is the command `nproc`, part of coreutils, for that – is that also provided by our default windows environment? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9347: forkProcess does not acquire global handle locks
by GHC 14 Nov '14

14 Nov '14

#9347: forkProcess does not acquire global handle locks -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The global I/O handles (`stdout`, `stdin`, `stderr`) all make use an `MVar` wrapping a `Handle__`, and many I/O functions temporarily take this `MVar` (for instance, functions such as `hPutStr` include a call to `wantWritableHandle`, which uses `withHandle_'`, which involves taking the `MVar`, executing some operation, and then putting the `MVar` back). Suppose we have a program consisting of two threads A and B, where thread A is doing I/O. If thread B does a call to `forkProcess` then it is possible that the `fork()` happens at the point that A has just taken, say, the `MVar` for `stdout`. If this happens, every use of `stdout` in the child process will now forever deadlock. This is not a theoretical scenario. The example code reported by Michael Snoyman a few years ago http://www.haskell.org/pipermail/haskell-cafe/2012-October/103922.html exhibits precisely this behaviour: the child process deadlocks (not all the the time, but very frequently), exactly because of this problem. In `forkProcess` we avoid this sort of situation for all of the global RTS locks by acquiring the lock just before the call to `fork()`, and then releasing the lock in the parent again and re-initializing the lock in the child. But there are no provisions for Haskell-land locks such as the above `MVar`. In principle we can work around this problem entirely in user-land. Here is a modified version of Michael's code that does not deadlock (at least, it never has in my tests..), that basically takes the same acquire- release*2 trick that `forkProcess` does for RTS locks in the lines marked `(*)`: {{{ import System.Posix.Process (forkProcess, getProcessID) import Control.Concurrent (forkIO, threadDelay) import System.IO (hFlush, stdout) import System.Posix.Signals (signalProcess, sigKILL) import Control.Exception (finally) import Control.Concurrent import GHC.IO.Handle.Types import System.IO main :: IO () main = do mapM_ spawnChild [1..9] ioLock <- lockIO -- (*) child <- forkProcess $ do unlockIO ioLock -- (*) putStrLn "starting child" hFlush stdout loop "child" 0 unlockIO ioLock -- (*) print ("child pid", child) hFlush stdout -- I've commented out the "finally" so that the zombie process stays alive, -- to prove that it was actually created. loop "parent" 0 -- `finally` signalProcess sigKILL child spawnChild :: Int -> IO () spawnChild i = do _ <- forkIO $ loop ("spawnChild " ++ show i) 0 return () loop :: String -> Int -> IO () loop msg i = do pid <- getProcessID print (pid, msg, i) hFlush stdout threadDelay 1000000 loop msg (i + 1) -------------------------------------------------------------------------------- lockIO :: IO Handle__ lockIO = case stdout of FileHandle _ m -> takeMVar m unlockIO :: Handle__ -> IO () unlockIO hout = case stdout of FileHandle _ m -> putMVar m hout }}} I guess that _any_ global `MVar` or `TVar` is suspect when using `forkProcess`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9350: Consider using xchg instead of mfence for CS stores
by GHC 14 Nov '14

14 Nov '14

#9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- To get sequential consistency for `atomicWriteIntArray#` we use an `mfence` instruction. An alternative is to use an `xchg` instruction (which has an implicit `lock` prefix), which might have lower latency. We should check what other compilers do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7484: Template Haskell allows building invalid record fields/names
by GHC 14 Nov '14

14 Nov '14

#7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8750 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7484#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2526: Warn about missing signatures only for exported functions
by GHC 14 Nov '14

14 Nov '14

#2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: fergushenderson | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2526#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8750: Invalid identifier generated with Template Haskell not rejected
by GHC 14 Nov '14

14 Nov '14

#8750: Invalid identifier generated with Template Haskell not rejected --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I wrote Template Haskell code that generates this declaration: {{{ data (:+Sym1) (a:: Nat) (b :: TyFun Nat Nat) }}} `(:+Sym1)` is not a valid identifier and this declaration fails when I simply put it in a source file and try to compile it. However I get no errors when this definition is generated from Template Haskell. Not sure if this is intended behaviour or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #393: functions without implementations
by GHC 13 Nov '14

13 Nov '14

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ⊥ Priority: normal | Version: None Component: Compiler | Keywords: newcomer (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 13 Nov '14

13 Nov '14

#1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: philip.weaver@… | Status: new Type: feature | Milestone: ⊥ request | Version: 6.6 Priority: normal | Keywords: newcomer Component: Template | Architecture: Unknown/Multiple Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1262#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #17: Separate warnings for unused local and top-level bindings
by GHC 13 Nov '14

13 Nov '14

#17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused- Resolution: None | binds newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3283 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: -fwarn-unused-binds => -fwarn-unused-binds newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/17#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 13 Nov '14

13 Nov '14

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: deriving, Resolution: | newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: deriving => deriving, newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0