- ghc-tickets - Haskell.org

[GHC] #16121: testsuite: only_ways(llvm_ways) behaves strangely
by GHC 02 Jan '19

02 Jan '19

#16121: testsuite: only_ways(llvm_ways) behaves strangely -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 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: -------------------------------------+------------------------------------- It appears that specifying `only_ways(llvm_ways)` for tests is not sufficient. E.g. when looking for the test T8131 in the llvm-CI-runner's logs, you won't find it. It is written like this: {{{#!python test('T8131', [cmm_src, only_ways(llvm_ways)], compile_fail, ['']) }}} The only `optllvm`-way tests are on `validate-aarch64-linux-deb9` {{{ =====> T5681(optllvm) 2409 of 6747 [0, 83, 8] cd "llvm/should_compile/T5681.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T5681.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm =====> T6158(optllvm) 2410 of 6747 [0, 83, 8] cd "llvm/should_compile/T6158.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T6158.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm -package vector -package primitive =====> T7571(optllvm) 2411 of 6747 [0, 83, 8] cd "llvm/should_compile/T7571.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T7571.cmm -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm -no-hs-main =====> T8131b(optllvm) 2413 of 6747 [0, 83, 8] cd "llvm/should_compile/T8131b.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T8131b.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm =====> T11649(optllvm) 2414 of 6747 [0, 83, 8] }}} These are triggered by the magic incantation: {{{#!python def f( name, opts ): opts.only_ways = ['optllvm', 'llvm', 'debugllvm'] setTestOpts(f) }}} `validate-x86_64-linux-deb9-llvm` won't even test those... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15914: haddock-library-1.7.0 fails to build on ppc64 BE
by GHC 02 Jan '19

02 Jan '19

#15914: haddock-library-1.7.0 fails to build on ppc64 BE -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was trying to build ghc-8.6.2 for Fedora 28 and it failed on ppc64 (Bigendian) with: {{{ utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:99:25: error: • GHC internal error: ‘TableRow’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [aIy :-> Type variable ‘id’ = id :: k, rHO :-> ATcTyCon Table :: k -> *, rHP :-> APromotionErr RecDataConPE] • In the type ‘[TableRow id]’ In the definition of data constructor ‘Table’ In the data declaration for ‘Table’ | 99 | { tableHeaderRows :: [TableRow id] | ^^^^^^^^ utils/haddock/dist/build/haddock/autogen/Paths_haddock.hs:41:22: error: • Couldn't match type ‘a’ with ‘String’ Expected type: IO a Actual type: IO String • In the first argument of ‘catchIO’, namely ‘(getEnv "haddock_libdir")’ In the expression: catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) In an equation for ‘getLibDir’: getLibDir = catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) | 41 | getLibDir = catchIO (getEnv "haddock_libdir") (\_ -> return libdir) | ^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Paths_haddock.dyn_o] Error 1 utils/haddock/haddock-api/src/Haddock/Syb.hs:22:1: warning: [-Wunused-top- binds] Defined but not used: ‘isType’ | 22 | isType _ = isJust $ eqT @a @b | ^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:38:1: warning: [-Wunused-top- binds] Defined but not used: ‘everythingBut’ | 38 | everythingBut k f x = let (v, stop) = f x | ^^^^^^^^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:60:21: warning: [-Wunused- matches] Defined but not used: ‘s’ | 60 | everythingWithState s k f x = | ^ utils/haddock/haddock-api/src/Haddock/Syb.hs:75:1: warning: [-Wunused-top- binds] Defined but not used: ‘everywhereBut’ | 75 | everywhereBut q f x | ^^^^^^^^^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.6.2 for powerpc64-unknown-linux): urk! lookup local fingerprint $fShowTokenType [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Error 1 make: *** [Makefile:127: all] Error 2 }}} https://koji.fedoraproject.org/koji/taskinfo?taskID=30919315 (the log files are only preserved for 2 weeks) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #4450: Do stack squeezing before expanding stack
by GHC 01 Jan '19

01 Jan '19

#4450: Do stack squeezing before expanding stack -------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Sebastian Graf <sgraf1337@…>): In [changeset:"e2d614e40e8b049ac0bcf3c6ccc6f0009864511e/nofib" e2d614e/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="e2d614e40e8b049ac0bcf3c6ccc6f0009864511e" Disable timer-based context switches Summary: In the past, we repeatedly had problems with non-deterministic allocations due to stack squeezing during context switches (#4450, #8611). This patch adds `+RTS -V0 -RTS` as extra `RUNTEST_OPTS` for every single- threaded benchmark. Is this the right place to add the flags? Should we also do this for all the other benchmarks? Reviewers: simonmar, osa1, nomeata, O26 nofib GHC Trac Issues: #8611 Differential Revision: https://phabricator.haskell.org/D5470 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4450#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16048: Show Instance for IOException discards error code
by GHC 01 Jan '19

01 Jan '19

#16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The `Show` instance for `IOException` currently looks like this: {{{ instance Show IOException where showsPrec p (IOError hdl iot loc s _ fn) = (case fn of Nothing -> case hdl of Nothing -> id Just h -> showsPrec p h . showString ": " Just name -> showString name . showString ": ") . (case loc of "" -> id _ -> showString loc . showString ": ") . showsPrec p iot . (case s of "" -> id _ -> showString " (" . showString s . showString ")") }}} Notice that it discards the error code (the fifth field in the data constructor). This means that when we call `ioError` to raise an `IOException`, we end up missing out on useful information. For example, in a project I'm working on now, I get this: {{{ *** Exception: Network.Icmp.Ping: ping: permission denied (Permission denied) }}} But I expected to see the original error code in there as well, which would help me diagnose issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16117: Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning sections
by GHC 01 Jan '19

01 Jan '19

#16117: Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning sections -------------------------------------+------------------------------------- Reporter: gwynne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Linking) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC-built binaries sometimes crash at runtime on Mojave. The crash is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; instead the entire file is mapped directly in using `mmap()`, which results in sections often loading at addresses which are only 8-byte aligned. The files on disk are not properly aligned, since `ld` was never given the opportunity to correctly arrange them. In turn, this causes any SSE instructions which load from memory (as found in, especially, crypto algorithms implemented in C) to raise `#GP` faults - SSE memory loads require 16-byte alignment. It's essentially blind luck that this has been working for any length of time in the past. This technique of loading static archives directly into memory at runtime is problematic at best; this crash is far from the only issue. With no involvement by `ld` and `dyld`, no symbols or debug information were available. There was absolutely no evidence anywhere in the crash logs to even make a start at tracking down the issue; only the presence of a consistent repro case and a lot of examining memory regions by hand made finding the root cause possible. `MH_OBJECT` files are not intended to be treated as final executable code. And to add insult to injury, the technique is fundamentally incompatible with code signing. Re-implementing parts of `dyld` by hand like this is not a replacement for macOS not supporting static linking. In the absence of switching to a supported behavior (e.g. dynamic loading), an appropriate fix consists of: 1. Disable the `mmap()` codepath in the Mach-O loader. It prevents correct alignment handling and does not provide a significant performance benefit. 2. Teach the loader to handle alignment on a section-by-section (''not'' segment!) basis and to correctly apply the appropriate relocations. The existing "align the entire file" codepath is not sufficient. 3. Remove the conceit that there will be only one segment to load. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16058: GHC built on macOS Mojave nondeterministically segfaults
by GHC 01 Jan '19

01 Jan '19

#16058: GHC built on macOS Mojave nondeterministically segfaults -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am seeing perhaps a quarter of GHC builds on the GitLab Darwin builder (running Mojave) fail with a segfault in `ghc-stage1`. Unfortunately I've been entirely unable to reproduce this in a debugger (which isn't surprising given the low probability of the crash manifesting). Given that we haven't seen this in any Darwin builds until now I'm suspicious of either the XCode toolchain or Mojave itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package
by GHC 31 Dec '18

31 Dec '18

#14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.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 haven't had time yet to diagnose where the memory is going to, but here's how to reproduce: {{{ cabal get mmark-0.0.5.6 && cd mmark-0.0.5.6/ cat > cabal.project <<EOF packages: . package mmark ghc-options: -Rghc-timing EOF }}} Then, `cabal new-build -w ghc-8.4.1` and ``cabal new-build -w ghc-8.2.2` will respectively output {{{ Resolving dependencies... Build profile: -w ghc-8.4.1 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 13510872 bytes, 13 GCs, 806197/1299656 avg/max bytes residency (3 samples), 4M in use, 0.001 INIT (0.000 elapsed), 0.007 MUT (0.025 elapsed), 0.018 GC (0.018 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Type.o ) Text/MMark/Type.hs:38:1: warning: [-Wunused-imports] The import of ‘Data.Semigroup’ is redundant except perhaps to import instances from ‘Data.Semigroup’ To import instances alone, use: import Data.Semigroup() | 38 | import Data.Semigroup | ^^^^^^^^^^^^^^^^^^^^^ [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Render.o ) Text/MMark/Render.hs:25:1: warning: [-Wunused-imports] The import of ‘Data.Semigroup’ is redundant except perhaps to import instances from ‘Data.Semigroup’ To import instances alone, use: import Data.Semigroup() | 25 | import Data.Semigroup | ^^^^^^^^^^^^^^^^^^^^^ [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89663269464 bytes, 1856 GCs, 338140365/1430147624 avg/max bytes residency (23 samples), 4130M in use, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) :ghc>> <<ghc: 65387008 bytes, 50 GCs, 2189716/5047200 avg/max bytes residency (5 samples), 11M in use, 0.000 INIT (0.000 elapsed), 0.021 MUT (0.207 elapsed), 0.042 GC (0.042 elapsed) :ghc>> }}} and {{{ Resolving dependencies... Build profile: -w ghc-8.4.1 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 13510872 bytes, 13 GCs, 806197/1299656 avg/max bytes residency (3 samples), 4M in use, 0.001 INIT (0.000 elapsed), 0.007 MUT (0.025 elapsed), 0.018 GC (0.018 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Type.o ) [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Render.o ) [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89663269464 bytes, 1856 GCs, 338140365/1430147624 avg/max bytes residency (23 samples), 4130M in use, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) :ghc>> <<ghc: 65387008 bytes, 50 GCs, 2189716/5047200 avg/max bytes residency (5 samples), 11M in use, 0.000 INIT (0.000 elapsed), 0.021 MUT (0.207 elapsed), 0.042 GC (0.042 elapsed) :ghc>> hvr@duo:/tmp/mmark-0.0.5.6$ cabal new-build -w ghc-8.2.2 Resolving dependencies... Build profile: -w ghc-8.2.2 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 11200976 bytes, 11 GCs, 853349/1518976 avg/max bytes residency (3 samples), 5M in use, 0.001 INIT (0.000 elapsed), 0.017 MUT (0.037 elapsed), 0.021 GC (0.021 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Type.o ) [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Render.o ) [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89565902800 bytes, 2004 GCs, 225836231/772393000 avg/max bytes residency (27 samples), 2179M in use, 0.001 INIT (0.000 elapsed), 58.237 MUT (61.472 elapsed), 25.823 GC (25.795 elapsed) :ghc>> <<ghc: 79930048 bytes, 56 GCs, 3522920/10072040 avg/max bytes residency (6 samples), 20M in use, 0.001 INIT (0.000 elapsed), 0.028 MUT (0.213 elapsed), 0.059 GC (0.059 elapsed) :ghc>> }}} Consequently, - GHC 8.2.2: **2179M in use**, 0.001 INIT (0.000 elapsed), 58.237 MUT (61.472 elapsed), 25.823 GC (25.795 elapsed) - GHC 8.4.1: **4130M in use**, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #16109: cabal install H under Windows 10 does not terminate
by GHC 30 Dec '18

30 Dec '18

#16109: cabal install H under Windows 10 does not terminate -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: cabal insall | Blocked By: H | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Under Windows 10 using ghc c8.6.3 (Haskell Platform), using cabal to install H (HaskellR) stalls after the message "Completed aeson," with ghc consuming about 5-10% of the CPU forever. I let it run all night and the situation does not change. The command used: 'cabal update; cabal install H'. I tried increasing the priority of the ghc process to "realtime." This increases the cpu usage from 5% to 10-20%, but still no progress after hours (days?). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3
by GHC 30 Dec '18

30 Dec '18

#15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Compiling jsaddle-dom (the JSDOM.Types module in particular) requires quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer able to compile it at all with 8 GB of RAM. At first I thought it could be related to https://ghc.haskell.org/trac/ghc/ticket/15304 but passing "-fno-worker-wrapper" does not seem to make much of a difference, therefore it might me a different cause here. Reproduce: git clone git@github.com:ghcjs/jsaddle-dom.git cd jsaddle-dom sed -i 's/? "default"/? "ghc843"/1' shell.nix nix-shell cabal new-build -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5