July 2014 - ghc-tickets

[GHC] #9197: FFI types should be usable in foreign import decls without revealing representations
by GHC 15 Nov '14

15 Nov '14

#9197: FFI types should be usable in foreign import decls without revealing representations ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [pointed out http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [I suggested http://www.haskell.org/pipermail /haskell-prime/2009-February/002727.html] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [argued http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (
by GHC 14 Nov '14

14 Nov '14

#9286: ghc-7.9.20140707 fails testsuite on OS X ( ----------------------------+---------------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X testsuite | Type of failure: Building GHC failed Architecture: x86_64 | Test Case: T5435_dyn_asm T4801 T6048 (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Using ghc straight from the git repository, I just ran sh validate. The ghc that I used to build this new one was from https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as it does not mess with system system files). This is on Yosemite DP3, XCode 6 Beta 3. {{{ OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST 0:45:11 spent to go through 4039 total tests, which gave rise to 15863 test cases, of which 12161 were skipped 28 had missing libraries 3606 expected passes 65 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 14 Nov '14

14 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

13 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 13 Nov '14

13 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 13 Nov '14

13 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 13 Nov '14

13 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 13 Nov '14

13 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 13 Nov '14

13 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