January 2018 - ghc-tickets

[GHC] #14600: Work out why Hadrian builds routinely fail
by GHC 15 Jun '18

15 Jun '18

#14600: Work out why Hadrian builds routinely fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with, {{{ | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so | Successfully built custom library 'libffi' Too long with no output (exceeded 10m0s) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions
by GHC 14 Jun '18

14 Jun '18

#14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `-fopt-coercions` flag finds its way to `OptCoercion.optCoercion` by way of the terrible `unsafeGlobalDynFlags`. In general it's nice to minimize the uses of `unsafeGlobalDynFlags`. However, it's not entirely clear that passing a `DynFlags` to `optCoercion` is worthwhile in this case as `-fopt-coercion` is essentially a debug flag. Leaving this here for later consideration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14392: `make binary-dist` is broken
by GHC 14 Jun '18

14 Jun '18

#14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we run {{{#!bash ./boot ./configure make make binary-dist }}} We are soon greeted with the following error {{{ cd bindistprep && "/bin/tar" hcf - -T ../bindist-list.uniq | /usr/bin/xz -c > ../bindistprep/ghc-8.3.20171025-x86_64-unknown-linux.tar.xz /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/build/.depend.c_asm: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/build/.depend.haskell: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/package-data.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/ghc.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist- install/build/.depend.c_asm: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist- install/build/.depend.haskell: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist-install/package- data.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/ghc.mk: Cannot stat: No such file or directory /bin/tar: Exiting with failure status due to previous errors mv bindistprep/*.tar.xz "." }}} I suspect https://github.com/ghc/ghc/commit/1e9f90af7311c33de0f7f5b7dba594725596d675 is to blame: bindist was not updated. A temporary work around I'm using is {{{ + $(filter-out testsuite/utils/check-ppr/% testsuite/utils/check-api- annotations/% %/project.mk mk/config.mk %/mk/install.mk,$(MAKEFILE_LIST)) \ }}} in top level {{{ghc.mk}}} in {{{bindist-list}}} {{{eval}}} section. I have reported this in #ghc to Ben but I am creating this ticket such that we can track the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14492: Tiered memory allocation restricts available memory
by GHC 14 Jun '18

14 Jun '18

#14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: memory ulimit | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was first noticed when running a binary produced with GHC 8.0.2 through a queueing system (Sun Grid Engine) that limits available memory by setting `ulimit -v`. When running with **unlimited** address space, the binary reserves 1TB of RAM and everything works as expected. When running with **limited** address space, reservation happens in powers of 2 leading to significant unused memory at higher memory values. The tests are summarized in the following table: {{{ Limit VIRT Unused (all in GB) 8 4 8 10 8 2 16 8 8 32 16 16 34 32 2 64 32 32 66 64 2 128 64 64 130 128 2 256 128 128 258 256 2 512 256 256 514 512 2 1024 512 512 }}} In the last line, setting `ulimit -v` to 1024GB (1073741824) causes the binary to only be able to reserve 512GB. If at runtime the software needs more than 512GB it will abort with "out of memory" instead of expanding to as close to the specified ulimit as possible. PS: Is there any way to make the "out of memory" error a little bit more informative? Something that informs the user of how much memory was already being used and how much more was going to be reserved when the failure was seen? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit
by GHC 14 Jun '18

14 Jun '18

#11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHCi crash Test Case: ghcilink004, | Blocked By: prog001, and 11 more | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64. See the following test failures. ghcilink004: {{{ ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): loadArchive "dir004/libfoo.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} prog001: {{{ ghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21) ghc-iserv.bin: loadArchive "/home/peter/ghc/libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.0.0.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink ghc-stage2: ghc-iserv terminated (1) }}} Using the system runtime linker fixes 13 failing tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13634: num009 fails on POWER8
by GHC 14 Jun '18

14 Jun '18

#13634: num009 fails on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.1 libraries/base | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime libraries/base/tests/Numeric/num009| Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le: {{{ +uh oh! tanf 1.5707964 +-2.2877334e7 +-2.2877332e7 +(-11438667,1) +(-11438666,1) Done }}} The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12903: SIGINT is not handled in forked process
by GHC 14 Jun '18

14 Jun '18

#12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If haskell program is forked in a toplevel hander that sends UserInterrupt in the main thread doesn't work, because Thread 1 doesn't exists in forked program, so that action is noop. Minimal example: {{{#!hs import Control.Concurrent import Control.Exception import System.Posix main = do pid <- forkProcess $ do handle (\UserInterrupt{} -> putStrLn "caught") $ threadDelay 2000000 signalProcess sigINT pid threadDelay 2000000 }}} Expected result: "caught" printed to stdout. Actual result: nothing is printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13564: Why does memory usage increase so much during CoreTidy?
by GHC 13 Jun '18

13 Jun '18

#13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made GHC display the live data size before and after each pass and while compiling DynFlags, the live data size increased by almost 50% during the CoreTidy pass, even though the Core program size hardly changed: {{{ ... Result size of Simplifier = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Simplifier [DynFlags]: 19.69 221248736: finished in 5337.48 milliseconds, allocated 4416.624 megabytes *** Demand analysis [DynFlags]: 19.69 221248152: Result size of Demand analysis = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Demand analysis [DynFlags]: 20.77 248604416: finished in 1349.45 milliseconds, allocated 2298.950 megabytes *** CoreTidy [DynFlags]: 20.77 248603432: Result size of Tidy Core = {terms: 104,440, types: 264,565, coercions: 15,700, joins: 58/679} !!! CoreTidy [DynFlags]: 21.43 342594336: finished in 1124.37 milliseconds, allocated 736.209 megabytes }}} I find the amount of this increase surprising considering what CoreTidy does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9539: TQueue can lead to thread starvation
by GHC 12 Jun '18

12 Jun '18

#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14737: Improve performance of Simplify.simplCast
by GHC 11 Jun '18

11 Jun '18

#14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11735 #14683 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs] `simplCast` eats up more execution time than we think it should. From [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10] > Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given > {{{ > (fun |> co) @t1 @t2 ... @tn > }}} > we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`. > > Solution: gather up those type arguments (easy) and define > {{{ > pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion) > }}} And [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41] > OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen. > > Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions. > > This should be an easy win all around. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34