May 2018 - ghc-tickets

[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] #15180: Make Control.Exception.throw levity polymorphic
by GHC 14 Jun '18

14 Jun '18

#15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `error` function has a levity-polymorphic type. I propose that the same be done for `throw`. I just encountered a situation where I needed this, and instead of calling `throw x`, I had to call `raise# (toException x)` because `throw` is unnecessarily restrictive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis
by GHC 12 Jun '18

12 Jun '18

#15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast. 72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxresident)k When i upgrade to LTS-11.9 compiling gets slow. To test if it was a problem with new package or GHC (ghc gives some new packages too) i ran: /usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts- suggestions" with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. Now the compile times are much higher: 2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata 674732maxresident)k I already took out parts of the grammar to get it even to compile. When i have the full grammar i can let my laptop compile 24 hours and it's still busy. I was not sure how to further reduce the code. Maybe when a lot of effort i can cut out a few lines here and there. So i uploaded the entire project here https://github.com/flip111/parser-calledarityanalysis i already took out a lot of code. If anyone has suggestions on how to further reduce the code i can try. Because i had debug info on (-v3 flag) i saw it was stuck for a long time at "Called arity analysis" I prioritize this bug high because i think the slowdown is very problematic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[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