May 2014 - ghc-tickets

[GHC] #8582: Record syntax for pattern synonyms
by GHC 04 Dec '15

04 Dec '15

#8582: Record syntax for pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement syntax for {{{ pattern Cons{car, cdr} = (car, cdr) }}} which can then be used just like a regular record constructor, so the following are all valid patterns: {{{ Cons (Just x) [] Cons{car = Just x} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8098: Faulty Word64 arithmetic if optimized
by GHC 02 Dec '15

02 Dec '15

#8098: Faulty Word64 arithmetic if optimized ----------------------------+--------------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The following program produces different results depending on optimization: Checked.hs: {{{ module Checked ((.-.)) where (.-.) :: (Bounded a, Integral a) => a -> a -> Maybe a x .-. y | x >= 0 && y < 0 = if z > x then Just z else Nothing | x >= 0 = if z <= x then Just z else Nothing | x < 0 && y > 0 = if z < x then Just z else Nothing | otherwise = Just z where z = x - y }}} Main.hs: {{{ module Main (main) where import Data.Maybe import Data.Word import Numeric import Checked main :: IO () main = print $ showHex (fromJust ((0xFFFFFFFF00000000 :: Word64) .-. 0x00000000FFFFFFFF)) "" }}} {{{ D:\dev\haskell\ch1>ghc --make Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffffffe00000001" D:\dev\haskell\ch1>del *.hi *.o *.exe D:\dev\haskell\ch1>ghc --make -O2 Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffe00000001" D:\dev\haskell\ch1> }}} The bug disappears if definition and usage of (.-.) are in the same module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8079: Redo T7919 with a cabal file
by GHC 22 Nov '15

22 Nov '15

#8079: Redo T7919 with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8199: Get rid of HEAP_ALLOCED
by GHC 22 Nov '15

22 Nov '15

#8199: Get rid of HEAP_ALLOCED ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC, as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. The attached patchset is *almost* able to support GHC itself; a ghc-stage2 built this way can compile most files, but is much slower in some cases, and probably has some correctness bugs. Improvements possible: * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * Closure tables should have their indirections short-circuited by the initialization code. * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * Properly handle the Windows DLL case (e.g. SRTs); this should be simpler now that everything is an indirection. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs. * Need to implement a new megablock tracking structure so we can free/check for lost blocks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306
by GHC 21 Oct '15

21 Oct '15

#8957: ghci's :l -> internal error: evacuate: strange closure type 8306 ----------------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- GHCi crashes when :loading a file. Unfortunately I can't reproduce the bug, so this one's gonna be lots of information that probably will help very little. This is the actual error message: {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) <interactive>: internal error: evacuate: strange closure type 8306 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This one was the error I was working on, i.e. the (legit) error in the previous call: (Including this because it gives you a clue what I was working on, I was mostly fiddling around with parens in placeAgents' gnd function) {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) [2 of 2] Compiling SimpleCellularALife ( SimpleCellularALife.hs, interpreted ) SimpleCellularALife.hs:70:28: Couldn't match expected type `Array i0 e0' with actual type `Ground' In the return type of a call of `ground' In the first argument of `(!)', namely `ground (tiles w)' In the expression: (ground (tiles w) ! (fst $ head grp)) SimpleCellularALife.hs:70:36: Couldn't match expected type `Tile' with actual type `Array Coordinates Tile' In the return type of a call of `tiles' In the first argument of `ground', namely `(tiles w)' In the first argument of `(!)', namely `ground (tiles w)' Failed, modules loaded: CommonStatistics. }}} Included Source Files - CommonStatistics.hs: {{{ module CommonStatistics where type Memory = [Int]--Internal state of an Agent. data StatUpdate = StatUpdate{ newVictories :: [Int] -- by agentID } deriving (Show) data Agent = Agent{ agentID :: Int, sourcePath :: FilePath, --path to .hs source file. relative to executable doFunc :: [String] -> Memory -> (Memory, [String]), evFunc :: [String] -> Memory -> (Memory, String), personalMemory :: Memory } instance Show Agent where show (Agent { agentID = aID, sourcePath = path, doFunc = forgetit, evFunc = forgetittoo, personalMemory = mem }) = show (aID, path, mem) }}} And SimpleCellularALife.hs: (I am not exactly confident that this is the version that caused the error. I sadly can't reproduce it, so there's no confirming that. {{{ module SimpleCellularALife where import Data.Array import Data.List import System.Random import CommonStatistics data Ground = Ground { food :: Int } data Entity = Entity{ ai :: Agent, health :: Int } data Tile = Tile{ ground :: Ground, entities :: [Entity] } data World = World { tiles :: Array Coordinates Tile } type Coordinates = (Int, Int) getRandomPosition :: RandomGen t => World -> t -> (t, Coordinates) getRandomPosition w rand = let ((minx, miny), (maxx, maxy)) = bounds $ tiles w (x, rand2) = randomR (minx, maxx) rand (y, rand3) = randomR (miny, maxy) rand2 in (rand3, (x, y)) placeAgents :: RandomGen t => World -> [Agent] -> t -> (t, World) placeAgents w agents rand = let createTileUpdates (ag:ags) wrld rnd = let (rnd2, coords) = getRandomPosition wrld rnd (rnd3, restUpd) = createTileUpdates ags wrld rnd2 in (rnd3, (coords, ag) : restUpd) createTileUpdates [] wrld rnd = (rnd, []) (rand2, assocList) = createTileUpdates agents w rand groupedAssocList = groupBy (\(c1, a1) (c2, a2) -> c1 == c2) $ sortBy (\(c1, a1) (c2, a2) -> compare c1 c2) assocList gnd grp = ground ((tiles w) ! (fst $ head grp)) condenseGroup grp = (fst $ head grp, Tile{ground = gnd grp, entities = snd $ unzip grp}) --map condenseGroup groupedAssocList --::(Coordinates, Tile) in (rand, w) --placeAgents (placeAgent w firstAg x y) agents rand3 }}} Someone suggested that this might've been GHCI running out of memory. I am as of writing this at 66% out of 4GB used. The GHCI instance was opened for an extended period of time, so it might have racked up quite a bit of RAM usage. I can say though that considering the file sizes, 1.3GB of RAM usage seems unreasonable. And because I haven't yet written enough, here are all the variations of the line I was working on that could've caused it. Pulled them out of my text editor's buffer. {{{ gnd grp = (ground (tiles w) ! fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp)) gnd grp = (ground ((tiles w) ! (fst $ head grp)) gnd grp = ground ((tiles w) ! (fst $ head grp)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8687: Strange closure type 9983
by GHC 21 Oct '15

21 Oct '15

#8687: Strange closure type 9983 ------------------------------------+------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- {{{ *Main> :main C:\\Windows\\Media\\onestop.mid <interactive>: internal error: evacuate: strange closure type 9983 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This happened to me on {{{ghci playmidi.hs}}} from the {{{examples/}}} folder of {{{http://hackage.haskell.org/package/hmidi-0.2.1.0}}} (downloaded the tar and fixed the parsec import, removing the {{{"parsec2"}}} package import and fixing a type checking error, replacing {{{selectOutputDevice Nothing}}} by {{{selectOutputDevice "Select midi output device" Nothing}}}. (We also fixed those compile errors at https://github.com/vahokif/hmidi/tree/2124a8.) I have not been able to reproduce it since the first time :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8648: Initialization of C statics broken in threaded runtime
by GHC 20 Oct '15

20 Oct '15

#8648: Initialization of C statics broken in threaded runtime ------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider a tiny package `static-value`, consisting of one Haskell file {{{ foreign import ccall unsafe "returnStaticValue" c_returnStaticValue :: IO CInt printStaticValue :: IO () printStaticValue = print =<< c_returnStaticValue }}} and one corresponding C file {{{ static int theStaticValue = 0; int returnStaticValue() { // Modify the static so the C compiler doesn't optimize it away return theStaticValue++; } }}} (test case is attached). If we call `printStaticValue` using the GHC API: {{{ runGhc (Just libdir) $ do flags0 <- getSessionDynFlags void $ setSessionDynFlags flags0 { hscTarget = HscInterpreted , ghcLink = LinkInMemory , ghcMode = CompManager } setContext $ [ IIDecl $ simpleImportDecl $ mkModuleName "StaticValue" ] _ <- runStmt "StaticValue.printStaticValue" RunToCompletion }}} then we see "0", as expected. However, if we compile this code using the threaded runtime, and we wrap the above code in a call to either `forkIO` or `forkOS`, then we see a different value printed (-907777, whatever that value is). Some notes: * I have been unable to reproduce this bug without using GHC as API; in particular, calling `printStaticValue` directly, wrapped in `forkIO` or `forkOS` or not, always works as expected. * If I change the initialization value of `staticValue` from 0 to anything else (say, 1234), we always get the right answer, never the uninitialized value. Presumably this is because non-zero values require some explicit code to be run (and it does get run), while a zero value gets initialized differently (and apparently, that's where the bug is). * I have reproduced this bug in both ghc 7.4 and 7.7.20131227. This ticket is the result of tracking down a problem with calling `createProcess` from within the GHC API, which would cause the parent process to stall. As it turns out, `runProcess.c` (from the `process` library) declares a `static long max_fd = 0`, and in `runInteractiveProcess` checks for this value to be 0, and if it is, does a syscall to figure out what the maximum FD is. But since this static does not get initialized properly (the bug reported in this ticket), it gets left at its (random? but always the same) value (281474975802879), so that the child process proceeds to close rather too many file descriptors (if close_fds was set to True) and the parent stalls. Indeed, changing the initialization to `static long max_fd = -1` (and adjusting the later check for zero accordingly) fixes this (so this is a viable workaround in `process` if we cannot track down the bug in GHC). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9058: System.IO.openTempFile does not scale
by GHC 07 Oct '15

07 Oct '15

#9058: System.IO.openTempFile does not scale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- In search of a bug in darcs http://bugs.darcs.net/issue2364 i've notice very bad property of openTempFile: it's pattern is very predictable and has O(n^2) of already created temp files. Predictability allows very fun bugs survive in buggy programs, like: {{{ thread1: (fn, fh) <- openTempFile "." "hello" renameFile fn "something" -- some time after when (some_rare_buggy_condition) $ -- oops, reused temp name, but too late, other thread killed it writeFileFile fn thread2: (fn, fh) <- openTempFile "." "hello" workWithFn fn -- nobody should touch it, right? }}} It's _very_ hard to debug data corruption when all temp files are named "foo${pid}" and sometimes "foo${pid+1}". And more serious bug: the more threads you have trying to create similar temps performance drops significantly: Attached program shows the following numbers: {{{ $ time ./bench-temps same 2000 real 0m2.795s user 0m1.516s sys 0m1.190s $ time ./bench-temps diff 2000 real 0m0.161s user 0m0.043s sys 0m0.115s }}} It's O(N^2) growing open() storm. https://github.com/ghc/ghc/blob/master/libraries/base/System/IO.hs#L465 {{{ FileExists -> findTempName (x + 1) }}} This is the source of the problem. I'd suggest always using random name for it. For portability reasons I suggest adding at least insecure random '''rand()''' value from C library. That way we will succeed in opening temp file at the first attempt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8364: equip GHC with an accurate internal model of floating point
by GHC 07 Oct '15

07 Oct '15

#8364: equip GHC with an accurate internal model of floating point ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- currently there really isn't a systematic / portable story for doing compile time reduction / evaluation for floating point numbers. there are some folks in the larger haskell community who are working on high precision soft float implementations / modelling. Once that work becomes available, might be worth exploring having something like that for doing controlled high precision evaluation of intermediate expressions in ghc proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8335: Create more specialized entries to GC
by GHC 07 Oct '15

07 Oct '15

#8335: Create more specialized entries to GC ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider this Cmm code (taken from #8326): {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} We perform two different calls to garbage collection here. Calling GC after making initial stack check obviously can't use any stack, so we pass parameter to GC in regsiters: {{{ R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; }}} But in the calls that are made later on inside the function we do put some parameters on the stack, thus increasing stack usage: {{{ cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; }}} If we had more specialized entries to GC that would allow us to pass parameters in registers (or in some fixed memory location associated with TCO?) then this function would not require any stack at all. Note that there is a separate issue here - `_sEV` variable is in fact dead and should be eliminated (see #8327). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2