December 2018 - ghc-tickets

[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 31 Dec '18

31 Dec '18

#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 31 Dec '18

31 Dec '18

#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 30 Dec '18

30 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

[GHC] #15945: Unable to compile GHC from source on OpenBSD (-CURRENT)
by GHC 29 Dec '18

29 Dec '18

#15945: Unable to compile GHC from source on OpenBSD (-CURRENT) -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: clang | Operating System: OpenBSD Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT): {{{ #! /bin/sh set -e BUILD_DIR=/usr/local/tmp-build-ghc export AUTOCONF_VERSION=2.69 export AUTOMAKE_VERSION=1.16 if [ ! -n "$1" ]; then echo "ERROR: Provide path for ghc source." exit 1 fi echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..." mkdir -p $BUILD_DIR cd $BUILD_DIR xzcat $1 | tar xvf - GHC_DIR=`ls | grep ghc` cd $GHC_DIR echo "Cleaning up OpenBSD-incompatible commands..." find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' echo "Building GHC... " export CC=/usr/bin/clang ./boot ./configure --with-iconv-libraries=/usr/local/lib \ --with-iconv-includes=/usr/local/include \ --with-gmp-libraries=/usr/local/lib \ --with-gmp-includes=/usr/local/include \ --with-ffi-libraries=/usr/local/lib \ --with-ffi-includes=/usr/local/include \ --with-system-libffi gmake }}} I will file a separate bug report for the **ln** incompatibility with the unsupported **-v** flag. When compiling GHC, I get the following error: {{{ ... "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc- Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o rts/RtsSymbols.c:990:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 990 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ rts/RtsSymbols.c:283:22: error: note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS' SymE_NeedsProto(_DYNAMIC) ^ | 283 | SymE_NeedsProto(_DYNAMIC) | ^ /usr/include/sys/exec_elf.h:765:17: error: note: previous definition is here | 765 | extern Elf_Dyn _DYNAMIC[]; | ^ extern Elf_Dyn _DYNAMIC[]; ^ 1 error generated. `clang' failed in phase `C Compiler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1 gmake: *** [Makefile:127: all] Error 2 }}} Any suggestions appreciated. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16098: More efficient implementation plan for primops with continuation arguments
by GHC 28 Dec '18

28 Dec '18

#16098: More efficient implementation plan for primops with continuation arguments -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | 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: #14375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Original idea from #14375: in some of the primops that take continuation arguments we currently have to allocate the continuations but sometimes we immediately enter one of these continuations. One example is {{{ maskAsyncExceptions# :: (State# RealWorld -> (# State# RealWorld, a #)) -> (State# RealWorld -> (# State# RealWorld, a #)) }}} which is implemented as {{{ stg_maskAsyncExceptionszh /* explicit stack */ { /* Args: R1 :: IO a */ STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1); if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_BLOCKEX) == 0) { /* avoid growing the stack unnecessarily */ if (Sp(0) == stg_maskAsyncExceptionszh_ret_info) { Sp_adj(1); } else { Sp_adj(-1); Sp(0) = stg_unmaskAsyncExceptionszh_ret_info; } } else { if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_INTERRUPTIBLE) == 0) { Sp_adj(-1); Sp(0) = stg_maskUninterruptiblezh_ret_info; } } StgTSO_flags(CurrentTSO) = %lobits32( TO_W_(StgTSO_flags(CurrentTSO)) | TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast [R1]; } }}} Here we want to have better compilation for `maskAsyncExceptions# c` where we don't allocate for `c`. There are some ideas in ticket:14375#comment:1, but the idea was later superseded by ticket:14375#comment:7, which suggests - Making continuation arguments explicit in STG so that an `maskAsyncExceptions#` would now look like this in STG: `maskAsyncExceptions# (\s. e)`. - Then in the code gen generating stack frame push (plus `StgTSO` updates) and then emitting code for `e` directly. (I don't understand if `bind s:=s2` part in the comment is necessary?) Some primops take more than one callback, e.g. {{{ catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> (# State# RealWorld, a #) }}} Which is implemented as {{{ stg_catchzh ( P_ io, /* :: IO a */ P_ handler /* :: Exception -> IO a */ ) { W_ exceptions_blocked; STK_CHK_GEN(); exceptions_blocked = TO_W_(StgTSO_flags(CurrentTSO)) & (TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_CATCHF_PUSHED(); /* Apply R1 to the realworld token */ TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast (CATCH_FRAME_FIELDS(,,stg_catch_frame_info, CCCS, 0, exceptions_blocked, handler)) (io); } }}} For this example ticket:14375#comment:7 suggest using join points for the `handler` argument (and using the non-allocating callback scheme for the `io` argument), but I suggest we focus on more efficient implementation of callbacks that are immediately entered, and worry about the join point stuff in another ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15921: Foldable.maximumBy uses counter-intuitive ordering
by GHC 28 Dec '18

28 Dec '18

#15921: Foldable.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: List | Operating System: Unknown/Multiple maximumBy minimumBy | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] }}} What do you expect the outcome to be? All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept. Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request: - If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it. - If its behaviour is intentionally the opposite, this should be specified in the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16034: Quadratic GC slowdown using RTS debug
by GHC 28 Dec '18

28 Dec '18

#16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 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: -------------------------------------+------------------------------------- Hello, Under some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling). I have been able to reproduce it using the following program (depending on the aeson library): {{{#!hs import Data.Aeson (eitherDecode, Value) import qualified Data.ByteString.Lazy as BL import Data.Maybe (catMaybes) import System.Directory (listDirectory) import System.FilePath ( (</>) ) main :: IO() main = do let dir = "data" files <- listDirectory dir values <- catMaybes <$> mapM (readF dir) files print $ length values readF :: FilePath -> FilePath -> IO (Maybe Value) readF dir fp = do print (dir </> fp) blob <- BL.readFile (dir </> fp) case eitherDecode blob of Left _ -> return Nothing Right v -> return $ Just $! v }}} Here data is a directory filled with (identical) JSON files. See the attached Python script for the proposed dataset. {{{ $ ghc -O -dynamic -o main Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,338,280 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 2.596s 2.597s 0.0001s 0.0006s Gen 1 14 colls, 0 par 2.422s 2.422s 0.1730s 0.7947s INIT time 0.000s ( 0.000s elapsed) MUT time 3.349s ( 3.351s elapsed) GC time 5.019s ( 5.020s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 8.368s ( 8.371s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 5,548,968,539 bytes per MUT second Productivity 40.0% of total user, 40.0% of total elapsed }}} {{{ $ ghc -O -dynamic -debug -o main.debug Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,332,424 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 172.941s 172.959s 0.0098s 0.0459s Gen 1 14 colls, 0 par 9.532s 9.532s 0.6808s 3.2061s INIT time 0.000s ( 0.000s elapsed) MUT time 5.020s ( 5.017s elapsed) GC time 182.473s (182.491s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 187.492s (187.508s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,701,999,827 bytes per MUT second Productivity 2.7% of total user, 2.7% of total elapsed }}} In debug mode, the runtime is almost quadratic: {{{ Nb of files Duration (non-debug) Duration (debug) 100 0.8s 2.8s 200 1.6s 8.8s 400 3.2s 27.6s 1000 8.2s 168.9s }}} The problem can be seen with either GHC 8.6.3 (here on Archlinux, with aeson 1.4.2.0) but was also observed using GHC 8.4.4, with static binaries, using "stack". I was able to reproduce with both threaded and non-threaded mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4