December 2018 - ghc-tickets

[GHC] #13165: Speed up the RTS hash table
by GHC 09 Dec '18

09 Dec '18

#13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.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: -------------------------------------+------------------------------------- The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15794: shell.nix depends on build artifacts
by GHC 08 Dec '18

08 Dec '18

#15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Filed Mar 19, 2018, as https://github.com/snowleopard/hadrian/issues/532 **Steps to reproduce:** 1. `git clone --recursive git://git.haskell.org/ghc.git` 2. `cd ghc/hadrian` 3. `nix-shell --pure` **Expected result:** Successful build. **Actual result:** {{{ hadrian(master)$ nix-shell --pure these derivations will be built: /nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r-directory-1.3.1.5.drv /nix/store/rcg0mmq0bincjfjnzbabc8fq7307bylq-process-1.6.3.0.drv /nix/store/15alkpni823gkfp63c79962v032wxvjs-extra-1.6.4.drv /nix/store/1b54g6nv8rw0kq3i5xjpcbhy88jvdnbr-xml-1.3.14.drv /nix/store/89salv051l8yr2y2k52pzkqraw9lfib9-test-framework-0.8.1.1.drv /nix/store/iqq0xsvgf3hf551b3jj0x3lg661c5y4f-test-framework- hunit-0.3.0.2.drv /nix/store/cy7ynm7r9jb41kxb1gxbwdprhvl03ivk-parsec-3.1.13.0.drv /nix/store/rgnsvxfvmbhrkniy0c86v65jgvx8nsan-test-framework- quickcheck2-0.3.0.4.drv /nix/store/fyrj002axd2skdz370hi13fq6prjh5cz-network-uri-2.6.1.0.drv /nix/store/7qcfy5gy9sjcz7cijqghgj3cilm2pzps-HTTP-4000.3.8.drv /nix/store/gk0w3grh2hz008sp6ksy669zvl6pyznb-js-flot-0.8.3.drv /nix/store/h39chz7m8zvawlrzfjsz496vl2rbp921-hashable-1.2.6.1.drv /nix/store/zpv0xi25jq6p5kkpvbc11sq73dxi2g0a-unordered- containers-0.2.8.0.drv /nix/store/i7p5c3mv9p20z7kb2mrdlpx0fwmyz3f5-shake-0.16.2.drv /nix/store/pzfcvib6sbsaascsc7djzcfqzlw847gc-Cabal-2.3.0.0.drv /nix/store/j5w4i42pgfy03s7fjsj4dfkis26c3nnp-happy-1.19.8.drv /nix/store/pl2dxjvbqs36rh80q5i09zdhbh6hjl2r-alex-3.2.3.drv /nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv building '/nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r- directory-1.3.1.5.drv'... building '/nix/store/1b54g6nv8rw0kq3i5xjpcbhy88jvdnbr-xml-1.3.14.drv'... setupCompilerEnvironmentPhase Build with /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2. setupCompilerEnvironmentPhase Build with /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2. unpacking sources unpacking source archive /nix/store/khjm3agcb1y91925r78h3chaq56w9fi7 -6wsbrbb60dzbfqf62c6sskwcijc3arjj-directory unpacking sources unpacking source archive /nix/store/dnx7hpl7wz81r3av4l09pqqhdqi4qpg6-xml-1.3.14.tar.gz source root is xml-1.3.14 source root is 6wsbrbb60dzbfqf62c6sskwcijc3arjj-directory setting SOURCE_DATE_EPOCH to timestamp 1424727750 of file xml-1.3.14/xml.cabal patching sources patching sources compileBuildDriverPhase compileBuildDriverPhase setupCompileFlags: -package-db=/tmp/nix-build- xml-1.3.14.drv-0/package.conf.d -j1 -threaded setupCompileFlags: -package-db=/tmp/nix-build- directory-1.3.1.5.drv-0/package.conf.d -j1 -threaded [1 of 1] Compiling Main ( Setup.hs, /tmp/nix-build- directory-1.3.1.5.drv-0/Main.o ) [1 of 1] Compiling Main ( Setup.hs, /tmp/nix-build- xml-1.3.14.drv-0/Main.o ) Linking Setup ... Linking Setup ... configuring configureFlags: --verbose --prefix=/nix/store /v3yazy78gy6kkpvrcn3schm8lc8y5dgl-xml-1.3.14 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --docdir=/nix/store /zdzgar7mwysym9dbai87fann20pbw75n-xml-1.3.14-doc/share/doc --with-gcc=gcc --package-db=/tmp/nix-build-xml-1.3.14.drv-0/package.conf.d --ghc- option=-optl=-Wl,-rpath=/nix/store/v3yazy78gy6kkpvrcn3schm8lc8y5dgl- xml-1.3.14/lib/ghc-8.2.2/xml-1.3.14 --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable- coverage --enable-library-vanilla --enable-executable-dynamic --enable- tests --ghc-option=-split-sections configuring configureFlags: --verbose --prefix=/nix/store /59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --docdir=/nix/store /w0gkzrf5q6ng40vzyvdl5m8pvw9v9dxy-directory-1.3.1.5-doc/share/doc --with- gcc=gcc --package-db=/tmp/nix-build-directory-1.3.1.5.drv-0/package.conf.d --ghc-option=-optl=-Wl,-rpath=/nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/directory-1.3.1.5 --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable-coverage --enable-library-vanilla --enable- executable-dynamic --enable-tests --ghc-option=-split-sections Configuring directory-1.3.1.5... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. You probably need to run 'autoreconf -i' to generate it. Configuring xml-1.3.14... Dependency base >=3 && <5: using base-4.10.1.0 Dependency bytestring -any: using bytestring-0.10.8.2 Dependency text -any: using text-1.2.3.0 Dependency base >=4.5 && <4.12: using base-4.10.1.0 Dependency directory -any: using directory-1.3.1.5 Dependency filepath >=1.3 && <1.5: using filepath-1.4.2 Dependency time >=1.4 && <1.9: using time-1.8.0.2 Dependency unix >=2.5.1 && <2.8: using unix-2.7.2.2 Source component graph: component lib component test:test dependency lib Configured component graph: component directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include base-4.10.1.0 include time-1.8.0.2 include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include unix-2.7.2.2 component directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test include base-4.10.1.0 include directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include time-1.8.0.2 include unix-2.7.2.2 Linked component graph: unit directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include base-4.10.1.0 include time-1.8.0.2 include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include unix-2.7.2.2 System.Directory=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory,System.Directory.Internal=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory.Internal,System.Directory.Internal.Prelude=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory.Internal.Prelude unit directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test include base-4.10.1.0 include directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include time-1.8.0.2 include unix-2.7.2.2 Ready component graph: definite directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK depends base-4.10.1.0 depends time-1.8.0.2 depends filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx depends unix-2.7.2.2 definite directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test depends base-4.10.1.0 depends directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK depends filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx depends time-1.8.0.2 depends unix-2.7.2.2 Using Cabal-2.0.1.0 compiled by ghc-8.2 Using compiler: ghc-8.2.2 Using install prefix: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5 Executables installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/bin Libraries installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/directory-1.3.1.5 Dynamic Libraries installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2 Private executables installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/libexec/x86_64-linux-ghc-8.2.2/directory-1.3.1.5 Data files installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/share/x86_64 -linux-ghc-8.2.2/directory-1.3.1.5 Documentation installed in: /nix/store/w0gkzrf5q6ng40vzyvdl5m8pvw9v9dxy- directory-1.3.1.5-doc/share/doc Configuration files installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/etc No alex found Using ar found on system at: /nix/store/aplvnhqdm6s9wj9r0jh46r46wvh65j86-binutils-2.28.1/bin/ar No c2hs found No cpphs found No doctest found Using gcc version 6.4.0 given by user at: /nix/store/wriy1xis74fybcg3m1jnq5bd5myxvhm6-gcc-wrapper-6.4.0/bin/gcc Using ghc version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/ghc Using ghc-pkg version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/ghc-pkg No ghcjs found No ghcjs-pkg found No greencard found Using haddock version 2.18.1 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/haddock No happy found Using haskell-suite found on system at: haskell-suite-dummy-location Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy- location No hmake found Using hpc version 0.67 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/hpc Using hsc2hs version 0.68.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/hsc2hs Using hscolour version 1.24 found on system at: /nix/store/yf0bs1q9ph388jms8xlgcd5vh99amjm4-hscolour-1.24.2/bin/HsColour No jhc found Using ld found on system at: /nix/store/wriy1xis74fybcg3m1jnq5bd5myxvhm6-gcc-wrapper-6.4.0/bin/ld No lhc found No lhc-pkg found No pkg-config found Using runghc version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/runghc Using strip version 2.28 found on system at: /nix/store/aplvnhqdm6s9wj9r0jh46r46wvh65j86-binutils-2.28.1/bin/strip Using tar found on system at: /nix/store/vvq16kzwgx9yhkf0fwwms5xzgg0rwdpl-gnutar-1.29/bin/tar No uhc found Setup: configure script not found. builder for '/nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r- directory-1.3.1.5.drv' failed with exit code 1 cannot build derivation '/nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv': 1 dependencies couldn't be built error: build of '/nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv' failed }}} Notice that the build fails for a library shipped with GHC. In `shell.nix` it's included as `localPackage`. **Workaround** First, we need to run `configurePhase` of the default Nix derivation for GHC HEAD: 1. `cd ghc` 2. `nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD` 3. `configurePhase` 4. `exit` Now we can `cd` into `ghc/hadrian` and proceed normally, the build won't fail. The issue is that this step shouldn't be required, we must have a self- contained `shell.nix`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags
by GHC 08 Dec '18

08 Dec '18

#14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE CApiFFI #-} {-# OPTIONS_GHC -optc-O3 #-} module M where foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO () }}} However, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`. Here's the resulting C compiler invocations for different `-O` flags: {{{ $ ghc -fforce-recomp -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} To summarise, here's the resulting effective `-O`-level passed to `gcc`: ||= GHC invocation =||= GCC invocation =||= Effective C `-O`-level =|| || `ghc` || `gcc -O3` || `-O3` || || `ghc -O0` || `gcc -O3` || `-O3` || || `ghc -O1` || `gcc -O3 -O1` || `-O1` || || `ghc -O2` || `gcc -O3 -O2` || `-O2` || || `ghc -O3` || `gcc -O3 -O2` || `-O2` || Consequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-) I see a few alternatives on how to resolve this: 1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O<n>` of its own 2. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags 3. Have GHC inject `-optc` flags as late as possible on the C compiler command-line 4. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o
by GHC 08 Dec '18

08 Dec '18

#15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- If a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the ''second time'' `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type information is not collected, as if `:set +c` wasn't in effect. This means that commands like `:type-at` and `:all-types` work as if they had the old file. I expect that given `:set +c`, a successful `:load *foo.hs` would always collect the new type information for `foo.hs`. == Steps to reproduce The contents of `setc.hs` is the following, although it's pretty surely irrelevant. {{{#!hs module SetC where }}} The following is a GHCi session showing the problem (my comments are marked with `--`). {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +c -- dir /b is basically ls on Windows Prelude> :! dir /b setc* setc.hs -- When I load a file multiple times it works fine Prelude> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But if I compile it *SetC> :! ghc -c setc.hs *SetC> :! dir /b setc* setc.hi setc.hs setc.o -- The first time the type info is collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But then it is no longer collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! *SetC> }}} Then if I change `setc.hs` to add some expressions: {{{#!hs module SetC where x :: Int x = 1 }}} {{{ *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! -- The new definition is loaded fine *SetC> x 1 -- But the type information is not there (no output!) *SetC> :all-types *SetC> -- Then if I delete the compiled .hi and .o files *SetC> :! del setc.hi setc.o -- ... and load again, :all-types suddenly works *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :all-types setc.hs:(4,1)-(4,2): GHC.Types.Int setc.hs:(4,5)-(4,6): GHC.Types.Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15130: Hadrian doesn't rebuild changed `CoreUtils.hs`
by GHC 08 Dec '18

08 Dec '18

#15130: Hadrian doesn't rebuild changed `CoreUtils.hs` --------------------------------------+--------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- When compiling stage2 with Hadrian, freezing stage1 causes changes to `CoreUtils.hs` to be ignored, and `CoreUtils.hs` not being recompiled. The following steps should reproduce the problem: 1. Make a debug build with Hadrian: `./hadrian/build.sh --flavour=Devel2` 2. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 3. Edit `compiler/coreSyn/CoreUtils.hs`, adding some change that is easily detected in the output 4. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 5. Observe how `CoreUtils` does not appear in the list of modules Hadrian is compiling, and how changes to that file do not end up in the stage2 compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15902: dead symbol warning error in rts base
by GHC 08 Dec '18

08 Dec '18

#15902: dead symbol warning error in rts base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- rts/posix/OSMem.c:161:1: error: warning: 'post_mmap_madvise' defined but not used [-Wunused-function] post_mmap_madvise(int operation, W_ size, void *ret) ^~~~~~~~~~~~~~~~~ | 161 | post_mmap_madvise(int operation, W_ size, void *ret) OSX build env -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16006: Framework failures when validating
by GHC 08 Dec '18

08 Dec '18

#16006: Framework failures when validating -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 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: -------------------------------------+------------------------------------- I just tried to validate and got this: {{{ Framework failures: . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) }}} Tree based on fb669f51b3f2cae79511ac3d1c43939d951b1f69. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14251: LLVM Code Gen messes up registers
by GHC 08 Dec '18

08 Dec '18

#14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.3 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers. A slightly adapted T8064 {{{#!hs {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE p #-} p :: Int# -> Float# -> Double# -> Float# -> Double# -> String p i j k l m = "Hello" {-# NOINLINE q #-} q :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String q _ i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) {-# NOINLINE r #-} r :: Int# -> Float# -> Double# -> Float# -> Double# -> String r i = let !(I# z) = length [I# 1# .. I# i] in \j k l m -> p z j k l m -- ghc won't eta-expand around the length, because it has unknown cost main = do putStrLn (f p) -- fast call putStrLn (f r) -- slow call: function but wrong arity let g = last [q 1#] putStrLn (f g) -- slow call: thunk }}} will produce the following results: {{{ ../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-llvm ... Hello World! Hello World! Hello 4.0 5.0 World! ../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-asm ... Hello World! Hello World! Hello 6.0 6.9 World! }}} The underlying reason is that (at least for X86_64) the Float and Double registers alternate. The llvm code gen creates function signatures based on the live registers (instead of all). For `q` only the last Float and Double register are `live`. However when calling `q` we pass `f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in the function body, we now have `f2 <- f1` and `d2 <- d1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #15934: Building ghc with dwarf information and profiling libraries fails on windows.
by GHC 07 Dec '18

07 Dec '18

#15934: Building ghc with dwarf information and profiling libraries fails on windows. ----------------------------------------+--------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Seems like we create too many sections in a single file on windows. {{{ C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 bytes to section .rdata$c1w2b_str of C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big' C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big `gcc.exe' failed in phase `Assembler'. (Exit code: 1) make[1]: *** [libraries/template-haskell/ghc.mk:4: libraries/template- haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:128: all] Error 2 }}} build.mk {{{ ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcLibHcOpts += -g1 GhcRtsHcOpts += -g1 # GhcStage2HcOpts += -g3 BUILD_PROF_LIBS=YES # Don't strip debug and other unneeded symbols from libraries and executables. STRIP_CMD = : HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 07 Dec '18

07 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > Annotations should also use the standard binary package for serialisation if it becomes a boot library. binary has been a boot library for a while now. Might be worth revisiting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0