January 2019 - ghc-tickets

[GHC] #16186: Segfault when embedding data via file-embed.
by GHC 23 Jan '19

23 Jan '19

#16186: Segfault when embedding data via file-embed. ----------------------------------------+--------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I made a minimal reproducible-ish example here: https://github.com/NorfairKing/nix-segfault-haskell and described it at length here: https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 The problem seems to occur (randomly) when literal strings are embedded via TH. By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #16107: Update GCC compiler & friends
by GHC 23 Jan '19

23 Jan '19

#16107: Update GCC compiler & friends ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- gcc used by ghc is now about 1.5 years old. It's going to take some time for a new GHC release as well. Would be good to update gcc too. Probably it's backwards compatible with old gcc so would be easy to patch. https://github.com/ghc/ghc/blob/f11f2521aff16edca150e6eed5102a3da7e4f59a/mk /get-win32-tarballs.sh#L104-L114 source code also points to other tools of which some have newer versions. Packages can be browsed here http://repo.msys2.org/mingw/x86_64/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15876: Function versioning instead of compilation flags...
by GHC 22 Jan '19

22 Jan '19

#15876: Function versioning instead of compilation flags... -------------------------------------+------------------------------------- Reporter: MichalGajda | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Linking) | Keywords: simd, | Operating System: Unknown/Multiple flavors, speed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster). This would require recompiling most of the libraries for new flags. Instead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/ This would allow us to write code like this: {-# target(avx512) #-} c_memchr = ...SIMD code... {-# !target(avx512) #-} c_memchr = ...current code... We currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.) Ideally we could also use it to remove some of _flavoring_ in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16066: internal error: PAP object entered!
by GHC 22 Jan '19

22 Jan '19

#16066: internal error: PAP object entered! ----------------------------------------+---------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: iOS Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- While trying to debug why my test didn't seem to be running, I got an internal error (below). After a clean and rebuild it happened again so it's not a flake. Unfortunately I don't know what's causing it so I can't produce an MWE, but I can link to the project and commit on GitHub: https://github.com/dspies- leapyear/persistwrap/tree/885a079923cb3eefb24db344f5e2fddee9fab425 Just run the test with: {{{ stack test persistwrap:persistwrap-test }}} {{{ Progress 9/10: persistwrap-0.1.0.0test/Driver.hs test_widget_schemas: persistwrap-test: internal error: PAP object entered! (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug persistwrap-test: SignalException 6 persistwrap-0.1.0.0: Test suite persistwrap-test failed Completed 10 action(s). Test suite failure for package persistwrap-0.1.0.0 persistwrap-test: exited with: ExitFailure (-6) Logs printed to console }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16003: Average and maximum residency numbers in nofib broken
by GHC 22 Jan '19

22 Jan '19

#16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: 8.6.2 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 5793 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Measuring average and maximum residency in nofib is currently broken: {{{ <<ghc: 55717832 bytes, 32 GCs (29 + 3), 0/0 avg/max bytes residency (0 samples), 58859672 bytes GC work, ... }}} I think that [https://github.com/ghc/nofib/blob/f87d446b4e361cc82f219cf78917db9681af69b3/… this line] in runstdtest.prl was responsible for matching on `-S` output, but since [https://phabricator.haskell.org/rNOFIB4e12b05c76e98aa8e32c9f867519c8187e69e… this commit], we only do `-s` for performance reasons. There's [https://github.com/ghc/nofib/blob/f87d446b4e361cc82f219cf78917db9681af69b3/… this bit of outcommented code] that probably does what we want. It seems that residency numbers were the only metrics depending on `-S`. I don't think there's a way to recover average residency with `-s` alone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15733: Several links in GHC.Exts.Heap documentation are broken
by GHC 22 Jan '19

22 Jan '19

#15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are some broken links in the GHC.Exts.Heap documentation. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html For example, in `GenClosure`, the first link is wrong and redirects. http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/Closures.h Similarly in the definition of `StgInfoTable`. Those are the two I found. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15662: Line pragmas appear to be slightly broken with Clang's CPP
by GHC 22 Jan '19

22 Jan '19

#15662: Line pragmas appear to be slightly broken with Clang's CPP -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- Two tests fail on OS X due to CPP irregularities, {{{ 7 --- /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail032.run/readFail032.stderr.normalised 2018-09-18 09:07:49.000000000 +0300 8 +++ /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail032.run/readFail032.comp.stderr.normalised 2018-09-18 09:07:49.000000000 +0300 9 @@ -1,5 +1,5 @@ 10 11 -readFail032.hs:25:38: 12 +readFail032.hs:26:38: 13 Couldn't match type ‘Char’ with ‘[Char]’ 14 Expected type: [[Char]] 15 Actual type: [Char] 16 --- /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail048.run/readFail048.stderr.normalised 2018-09-18 09:07:50.000000000 +0300 17 +++ /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail048.run/readFail048.comp.stderr.normalised 2018-09-18 09:07:50.000000000 +0300 18 @@ -1,5 +1,5 @@ 19 20 -readFail048.hs:25:38: 21 +readFail048.hs:26:38: 22 Couldn't match type ‘Char’ with ‘[Char]’ 23 Expected type: [[Char]] 24 Actual type: [Char] }}} This appears to be a CPP bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16046: -fno-stack-protector still necessary?
by GHC 22 Jan '19

22 Jan '19

#16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- aclocal.m4 has a block of code that checks to see if gcc supports -fno- stack-protector and adds that flag if so. That ends up in /usr/lib/ghc/settings, gets passed in whenever C bits get built, etc. I see that block was moved into place in 2010, but is even older than that. What I'm wondering is: is that still necessary to do, or do ghc and stack protection play nicely together now? I've searched around but can't find much information about it (searching for ghc and stack is a lot harder since that program appeared). The one thing I've found is: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev- lang/ghc?id=8cee49e4a6c8d9ec80faa4054b621467450d3ebb I'm in charge of building Haskell-related stuff for a semi-private Linux distribution and just want to make sure I'm getting things right. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13586: ghc --make seems to leak memory
by GHC 22 Jan '19

22 Jan '19

#13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13379 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is probably not reproducible with a small example.) When I build this project with `cabal build` https://github.com/LambdaHack/LambdaHack/commit/138123ab13edd4db6c8143720af… the peek memory, as observed with `top`, is 10G*. When I instead interrupt the compilation with `^C` at the following point (compilation of this file take a couple of minutes, so it's easy to interrupt): {{{ [123 of 123] Compiling Game.LambdaHack.SampleImplementation.SampleMonadServer ( Game/LambdaHack/SampleImplementation/SampleMonadServer.hs, dist/build/Game/LambdaHack/SampleImplementation/SampleMonadServer.o ) }}} and then restart and continue to the end, peek memory usage in either of the two compilation parts is 5G*. So it seems `ghc --make` keeps some data that is either eventually not used or could as well be read on demand instead of kept in memory. Confirmed with 8.2.1-rc1 as well, but it's not trivial to compile due to restrictive upper bounds of many packages. *exact numerical values are made up -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16108: GHC --version doesn't show arch
by GHC 22 Jan '19

22 Jan '19

#16108: GHC --version doesn't show arch ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On windows type ghc --version displays The Glorious Glasgow Haskell Compilation System, version 8.6.3 Right now it's difficult to determine if it's a 32 bits or 64 bits binary. The Glorious Glasgow Haskell Compilation System, version 8.6.3 (64-bits) Or something like this would be better. Also makes me wonder if there are any other characteristics that make up a difference in ghc binary that is worth mentioning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1