- ghc-tickets - Haskell.org

Re: [GHC] #6135: Unboxed Booleans
by GHC 16 Jun '13

16 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): Replying to [comment:74 igloo]: > I have the impression that these patches need some more polishing before they're ready to apply, so I'm reopening the ticket. Please let me know if that's wrong. Sure. If there's anything wrong with patches please let me know - I'll do my best to make them better. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:76> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7941: Running 'make maintainer-clean' doesn't remove all build artefacts
by GHC 16 Jun '13

16 Jun '13

#7941: Running 'make maintainer-clean' doesn't remove all build artefacts -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Running `make maintainer-clean` in the build tree doesn't remove all build artefacts. I'd like to update Makefiles so that these files are removed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7986: make newBroadcastTChanIO match newBroadcastTChan
by GHC 16 Jun '13

16 Jun '13

#7986: make newBroadcastTChanIO match newBroadcastTChan -----------------------------+---------------------------------------------- Reporter: WrenThornton | 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: -----------------------------+---------------------------------------------- While looking through the pull requests for stm-chans I came across a discrepancy in the new stm. Namely, we have the following definitions: * stm == 2.4 {{{ newBroadcastTChan :: STM (TChan a) newBroadcastTChan = do dummy_hole <- newTVar TNil write_hole <- newTVar TNil read <- newTVar dummy_hole write <- newTVar write_hole return (TChan read write) newBroadcastTChanIO :: IO (TChan a) newBroadcastTChanIO = do dummy_hole <- newTVarIO TNil write_hole <- newTVarIO TNil read <- newTVarIO dummy_hole write <- newTVarIO write_hole return (TChan read write) }}} * stm == 2.4.2 {{{ newBroadcastTChan :: STM (TChan a) newBroadcastTChan = do write_hole <- newTVar TNil read <- newTVar (error ...) write <- newTVar write_hole return (TChan read write) newBroadcastTChanIO :: IO (TChan a) newBroadcastTChanIO = do dummy_hole <- newTVarIO TNil write_hole <- newTVarIO TNil read <- newTVarIO dummy_hole write <- newTVarIO write_hole return (TChan read write) }}} Thus, whoever changed the definition of newBroadcastTChan in 2.4.2 forgot to change newBroadcastTChanIO to keep it in sync. PROPOSAL: I propose changing newBroadcastTChanIO to match newBroadcastTChan. ACCEPTED: +1: wren ng thornton, Edward Kmett, John Wiegley; -1: noone. http://www.haskell.org/pipermail/libraries/2013-May/019808.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 16 Jun '13

16 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by simonmar): Replying to [comment:69 simonpj]: > > One thing I'm puzzled about is this. If `>#` yields an `Int#`, how does that `Int#` get into a register? If we branch directly on the result of the comparison, then the intermediate `Int#` is never manifested, the code generator just generates a conditional branch instruction. The optimisations in `CmmSink` try to ensure that the comparison is pushed into the `CmmCondBranch` so the code generator can spot it. If the `Int#` value is really used (as in the example with logical ops on the wiki page), then on x86 there are instructions to generate it (e.g. `sete`, `setge`, etc.). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:75> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #693: dynamic locking
by GHC 15 Jun '13

15 Jun '13

#693: dynamic locking -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: low | Milestone: 7.8.1 Component: Runtime System | Version: 6.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Moderate (less than a day) Testcase: N/A | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: patch => closed * resolution: => fixed Comment: Thanks; I've pushed a similar patch which also optimises the C users of `lockClosure`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/693#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #693: dynamic locking
by GHC 15 Jun '13

15 Jun '13

#693: dynamic locking -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: low | Milestone: 7.8.1 Component: Runtime System | Version: 6.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: N/A Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Comment(by ian@…): commit 75947bb63794cae5950f679c8df86441b736b3fa {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 15 19:07:58 2013 +0100 Optimise lockClosure when n_capabilities == 1; fixes #693 Based on a patch from Yuras Shumovich. includes/Rts.h | 2 +- includes/rts/storage/SMPClosureOps.h | 28 ++++++++++++++++++++++------ rts/PrimOps.cmm | 28 ++++++++++++++++++++++++---- 3 files changed, 47 insertions(+), 11 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/693#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7847: Maintain per-generation lists of weak pointers
by GHC 15 Jun '13

15 Jun '13

#7847: Maintain per-generation lists of weak pointers -----------------------------------------+---------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- Currently the runtime system keeps a list of all live weak pointers, and traverses it once every (major or minor) GC. This is very slow if the program keeps many weak pointers alive. Some comments in the rts source suggest that it should be using one weak pointer list per generation, so these patches implement that. The attached test program tries to imitate the memory behavior of code that uses a particular FRP library. The patches make the program 3x faster on my machine. One problem I can see with the patches is that it creates a race condition between finalizeForeignPtr and addForeignPtrFinalizer. I'm not even sure what the correct behavior is when addForeignPtrFinalizer is called after finalizerForeinPtr. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 13

[GHC] #7933: JavaScript Cmm backend
by GHC 15 Jun '13

15 Jun '13

#7933: JavaScript Cmm backend -----------------------------+---------------------------------------------- Reporter: bosu | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to RFC on the attached patch implementing JavaScript Cmm backend for GHC. It adds -fjavascript compilation option. Calling ghc -fjavascript produces JS in the output file. Otherwise the ghc binary should be fully functional as a native compiler. Thus -fjavascript is similar to -fllvm in spirit. The patch adds HscJavaScript constructor to HscTarget. It is used to dispatch code output to the new JsCodeGen module. Generated JavaScript code relies on the built-in JS garbage collection. JsTransforms module disables GHC Hp and Sp overflow checks. As JavaScript has no pointers, we emulate them using JS closures containing arrays and indices. To distinguish between pointers and scalars we run Hoopl heuristics in PointerMarker module. As in native world, the generated JS object files are to be linked. In order to do this, there is another project, tentatively called Josh[1]. Josh is regular cabalized Haskell binary which links JS object files using function maps provided by GHC. The JavaScript RTS has rts/*.cmm compiled to JavaScript almost as is. In addition there is a handful of handwritten JS code residing in Josh distribution[2]. ghc-prim[3], integer-gmp[4] and base[5] are compiled with small changes. Those changes seem to be orthogonal to the GHC patch. For bootstrap process please see Josh README at github. Josh also includes several tests which work on 32-bit Debian Wheezy. Generated code is in order of 2 MB uncompressed and un-minified. Most of it is in RTS. It compresses very well though (to 150Kb approx). Plenty of low-hanging fruit optimizations are possible. There are plenty caveats to the current patch. It works on 32 bits only. Math is fishy and Integer support is nonexistant. Lots of tests should be imported from GHC, GHCJS, Fay. No Handle based IO works at the moment. No performance tests were done. Despite its shortcomings, the patch is fairly non-invasive, IMHO. It should be noted, that the same approach could work for other GC based platforms (e.g. Java, C#). I'd like to continue working towards merging the patch into GHC, if possible. Could GHC committers provide any guidance of what should be done in order to merge it? [1] https://github.com/bosu/josh [2] https://github.com/bosu/josh/blob/master/etc/ptr.js [3] https://github.com/bosu/ghc-prim [4] https://github.com/bosu/integer-gmp [5] https://github.com/bosu/base -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 9

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 15 Jun '13

15 Jun '13

#4001: Implement an atomic readMVar -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Comment(by lpsmith): To clarify my previous comment, one could implement a thread-safe `isEmptyChan`[1][2] as follows: {{{ data Chan a = Chan { write_end_ref :: MVar (Stream a) , read_end_ref :: IORef (Stream a) , read_lock :: MVar () } readChan :: Chan a -> IO a readChan chan = do modifyMVarMasked (read_lock chan) $ \_ -> do read_end <- readIORef (read_end_ref chan) (ChItem val new_read_end) <- atomicReadMVar read_end writeIORef (read_end_ref chan) new_read_end return ((), val) isEmptyChan :: Chan a -> IO Bool isEmptyChan chan = do read_end <- readIORef (read_end_ref chan) mval <- atomicTryReadMVar read_end return $! case mval of Nothing -> True Just _ -> False }}} [1] [http://www.haskell.org/ghc/docs/7.6.3/html/libraries/base-4.6.0.1 /Control-Concurrent-Chan.html#v:isEmptyChan] [2] #4154 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
by GHC 15 Jun '13

15 Jun '13

#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------+-------------------------------------------- Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by igloo): So what's the proposal here exactly? Is it to deprecate these?: {{{ System.IO.hGetBufSome System.IO.hGetBufNonBlocking System.IO.hPutBufNonBlocking Data.ByteString.hGetNonBlocking Data.ByteString.hPutNonBlocking }}} There are a couple of uses of `hGetNonBlocking` in haskeline. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0