August 2014 - ghc-tickets

[GHC] #9322: Modify readProcess[WithExitCode] to allow setting current directory
by GHC 14 Nov '14

14 Nov '14

#9322: Modify readProcess[WithExitCode] to allow setting current directory -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/process | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The readProcess[WithExitCode] function does not allow to modify the working directory parameter passed to createProcess. The documentation states 'readProcess and readProcessWithExitCode are fairly simple wrappers around createProcess. Constructing variants of these functions is quite easy'. I would call that a boldfaced lie, as the implementation of readProcess[WithExitCode] and its web of required, hidden helper functions spans multiple screen pages of subtle and error prone code. Just look at the numerous bug reports for it. It would seem rather unfortunate to extract and copy paste all of this from System.Process just to provide a working directory to a newly created process. Maybe the call should be changed to simply specify a default CreateProcess record so all things like cwd/env could be customized? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9323: Confusing type error behaviour
by GHC 14 Nov '14

14 Nov '14

#9323: Confusing type error behaviour -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Compile this example with GHC 7.8.3. {{{ module Foo where broken :: [Int] broken = () ambiguous :: a -> String ambiguous _ = show 0 }}} You get {{{ Foo.hs:4:10: Couldn't match expected type ‘[Int]’ with actual type ‘()’ In the expression: () In an equation for ‘broken’: broken = () Foo.hs:7:15: No instance for (Show a0) arising from a use of ‘show’ The type variable ‘a0’ is ambiguous }}} (and a similar ambiguous `(Num a0)` error). '''But if you comment out `broken`, the program compiles.''', using the defaulting rules to choose `a0` = `Integer`. This is obviously wrong. Reported by Evan Laforge. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare".
by GHC 14 Nov '14

14 Nov '14

#9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- A common use case for `on` (from `Data.Function`) is to use it with `compare`, e.g. {{{compare `on` snd}}}. In fact, this pattern is so common that there's a convenient `comparing` function which provides a shortcut for this use case such that one can write {{{ #!haskell sortBy (comparing snd) }}} instead of {{{ #!haskell sortBy (compare `on` snd) }}} I think another common use case is to use `on` together with `(==)` as in {{{ #!haskell groupBy ((==) `on` snd) }}} In a similiar vein as with `comparing`, I think it would be nice if there was a function which encapsulates this use case, like {{{ #!haskell equating :: Eq b => (a -> b) -> a -> a -> Bool equating = on (==) }}} such that one can write {{{ #!haskell groupBy (equating snd) }}} The (IMHO fairly nice) name `equating` is not my idea but was suggested by //ClaudiusMaximus// of #haskell fame. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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

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

13 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

[GHC] #9428: Pretty printer bad formatting
by GHC 13 Nov '14

13 Nov '14

#9428: Pretty printer bad formatting -------------------------------------+------------------------------------- Reporter: terrelln | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Driver | Version: 7.6.3 Keywords: pretty print | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with `-fwarn-incomplete-patterns`, the first test case `s17.hs` (attached) outputs unmatched patterns correctly. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B A B ... }}} However, when compiling `s18.hs` each argument is printed on its own line. 16 lines of the output are included below. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9431: integer-gmp small Integer multiplication does two multiplications on x86
by GHC 13 Nov '14

13 Nov '14

#9431: integer-gmp small Integer multiplication does two multiplications on x86 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `timesInteger` begins thusly: {{{ timesInteger :: Integer -> Integer -> Integer timesInteger (S# i) (S# j) = if isTrue# (mulIntMayOflo# i j ==# 0#) then S# (i *# j) else -- ... }}} The x86 backend implements `mulIntMayOflo#` as a (word, word) -> double word multiplication, followed by bit manipulation to test for overflow of the low word. Then, if there was no overflow, on the next line we multiply the operands again. We should be able to do better here. We need a new primop that combines `mulIntMayOflo#` with the actual multiplication result, at least in the non-overflow case (though with some more work we might be able to turn the double word result directly into a large Integer), and then we need to update `timesInteger` to use it. The LLVM backend probably has the same behavior, though it might be smart enough to notice that the multiplication is repeated; I haven't checked its assembly output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9442: Building GHC with Clang
by GHC 13 Nov '14

13 Nov '14

#9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: -------------------------------------+------------------------------------- How does one build GHC from scratch using Clang on OS X 10.9 and 10.10? At this time, I'm seeing the following message: $ ./configure checking for gfind... /opt/local/bin/gfind checking for sort... /usr/bin/sort checking for GHC version date... inferred 7.9.20140813 checking for ghc... no configure: error: GHC is required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2