August 2016 - ghc-tickets

[GHC] #12208: double free or corruption (TEST=T5644 WAY=threaded1)
by GHC 25 Aug '16

25 Aug '16

#12208: double free or corruption (TEST=T5644 WAY=threaded1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- {{{ $ make test TEST=T5644 WAY=threaded1 ... =====> T5644(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T5644/T5644.run" && "/opt/ghc/head/bin/ghchead" --make -o T5644 heap-overflow.hs -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history -threaded -debug -O > T5644.comp.stderr 2>&1 cd "./rts/T5644/T5644.run" && ./T5644 +RTS -M20m -RTS </dev/null > T5644.run.stdout 2> T5644.run.stderr *** Error in `./T5644': double free or corruption (fasttop): 0x00007f1e34000910 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f1e495b7725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f1e495bff4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f1e495c3abc] ./T5644[0x48d2dd] ./T5644[0x492d4b] ./T5644[0x490ffe] ./T5644[0x493ca7] ./T5644[0x48cde1] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f1e499106fa] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1e49646b5d] ======= Memory map: ======== 00400000-00518000 r-xp 00000000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 00718000-0071b000 r--p 00118000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 0071b000-00727000 rw-p 0011b000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 00727000-0072a000 rw-p 00000000 00:00 0 026cd000-0270f000 rw-p 00000000 00:00 0 [heap] 200000000-200200000 rw-p 00000000 00:00 0 200200000-201400000 ---p 00000000 00:00 0 201400000-201600000 rw-p 00000000 00:00 0 201600000-10200100000 ---p 00000000 00:00 0 7f1e34000000-7f1e34021000 rw-p 00000000 00:00 0 7f1e34021000-7f1e38000000 ---p 00000000 00:00 0 7f1e38000000-7f1e38021000 rw-p 00000000 00:00 0 7f1e38021000-7f1e3c000000 ---p 00000000 00:00 0 7f1e3c000000-7f1e3c021000 rw-p 00000000 00:00 0 7f1e3c021000-7f1e40000000 ---p 00000000 00:00 0 7f1e42ffe000-7f1e42fff000 ---p 00000000 00:00 0 7f1e42fff000-7f1e437ff000 rw-p 00000000 00:00 0 [stack:5323] 7f1e437ff000-7f1e43800000 ---p 00000000 00:00 0 7f1e43800000-7f1e44000000 rw-p 00000000 00:00 0 [stack:5322] 7f1e44000000-7f1e44021000 rw-p 00000000 00:00 0 7f1e44021000-7f1e48000000 ---p 00000000 00:00 0 7f1e48328000-7f1e4833e000 r-xp 00000000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4833e000-7f1e4853d000 ---p 00016000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4853d000-7f1e4853e000 rw-p 00015000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4853e000-7f1e4853f000 ---p 00000000 00:00 0 7f1e4853f000-7f1e48d3f000 rw-p 00000000 00:00 0 [stack:5321] 7f1e48d3f000-7f1e48d40000 ---p 00000000 00:00 0 7f1e48d40000-7f1e49540000 rw-p 00000000 00:00 0 [stack:5320] 7f1e49540000-7f1e49700000 r-xp 00000000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49700000-7f1e498ff000 ---p 001c0000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e498ff000-7f1e49903000 r--p 001bf000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49903000-7f1e49905000 rw-p 001c3000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49905000-7f1e49909000 rw-p 00000000 00:00 0 7f1e49909000-7f1e49921000 r-xp 00000000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49921000-7f1e49b20000 ---p 00018000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b20000-7f1e49b21000 r--p 00017000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b21000-7f1e49b22000 rw-p 00018000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b22000-7f1e49b26000 rw-p 00000000 00:00 0 7f1e49b26000-7f1e49b29000 r-xp 00000000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49b29000-7f1e49d28000 ---p 00003000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d28000-7f1e49d29000 r--p 00002000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d29000-7f1e49d2a000 rw-p 00003000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d2a000-7f1e49d31000 r-xp 00000000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49d31000-7f1e49f30000 ---p 00007000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f30000-7f1e49f31000 r--p 00006000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f31000-7f1e49f32000 rw-p 00007000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f32000-7f1e4a03a000 r-xp 00000000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a03a000-7f1e4a239000 ---p 00108000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a239000-7f1e4a23a000 r--p 00107000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a23a000-7f1e4a23b000 rw-p 00108000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a23b000-7f1e4a2ba000 r-xp 00000000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a2ba000-7f1e4a4b9000 ---p 0007f000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4b9000-7f1e4a4ba000 r--p 0007e000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4ba000-7f1e4a4bb000 rw-p 0007f000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4bb000-7f1e4a4e1000 r-xp 00000000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a521000-7f1e4a6b9000 r--p 00000000 b3:01 934811 /usr/lib/locale/locale-archive 7f1e4a6b9000-7f1e4a6be000 rw-p 00000000 00:00 0 7f1e4a6dd000-7f1e4a6e0000 rw-p 00000000 00:00 0 7f1e4a6e0000-7f1e4a6e1000 r--p 00025000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a6e1000-7f1e4a6e2000 rw-p 00026000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a6e2000-7f1e4a6e3000 rw-p 00000000 00:00 0 7ffc3afc6000-7ffc3afe7000 rw-p 00000000 00:00 0 [stack] 7ffc3aff2000-7ffc3aff4000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Wrong exit code (expected 251 , actual 134 ) Stdout: Stderr: T5644: Heap exhausted; T5644: Current maximum heap size is 20971520 bytes (20 MB). T5644: Use `+RTS -M<size>' to increase it. Aborted (core dumped) *** unexpected failure for T5644(threaded1) }}} Similar result for `WAY=threaded2`. No problems with ghc-8.0.1. I'm using ghc-8.1.20160610 (c88f31a08943764217b69adb1085ba423c9bcf91). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12424: RTS stats show wrong productivity.
by GHC 25 Aug '16

25 Aug '16

#12424: RTS stats show wrong productivity. --------------------------------------+--------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I have this report after runnig my program: {{{ INIT time 0.000s ( 0.001s elapsed) MUT time 29.344s ( 56.484s elapsed) GC time 4.306s ( 1.589s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 33.649s ( 58.075s elapsed) Alloc rate 1,530,969,741 bytes per MUT second Productivity 87.2% of total user, 50.5% of total elapsed }}} Elapsed productivity is wrong. It should be `MUT elapsed / Total elapsed = 56.484 / 58.075 = 0.972` but it looks like `MUT user / Total elapsed = 29.344 / 58.075 = 0.505` Looks like the code at https://github.com/ghc/ghc/blob/a88bb1b1518389817583290acaebfd6454aa3cec/rt… uses wrong numerator for elapsed value. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12365: Update documentation for partial type signatures
by GHC 25 Aug '16

25 Aug '16

#12365: Update documentation for partial type signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.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: -------------------------------------+------------------------------------- In the [https://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#partial-type-signatures documentation] for partial type signatures, I found several bits that are out of date: - There are several sample error messages given. These have been substantively reworded ({{{Found hole `_` with type: ...}}} to {{{Found type wildcard `_` standing for ...}}}) where I find the new wording much clearer. - In the "Where can they occur?" section, there's no mention of `TypeApplications`, which is a new context where they can appear. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12128: ghci cause panic on 8.0.1
by GHC 25 Aug '16

25 Aug '16

#12128: ghci cause panic on 8.0.1 -------------------------------------+------------------------------------- Reporter: zxtx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The following code panics when called with ghci: {{{#!hs module Foo where import GHC.TypeLits (Symbol) import Unsafe.Coerce instance Read Symbol where readsPrec = unsafeCoerce (readsPrec :: Int -> ReadS String) data Bar = TyCon !Symbol deriving (Read) }}} {{{ % ghci foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/zv/.ghc/ghci.conf [1 of 1] Compiling Foo ( foo.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): atomPrimRep case a1_s2AG of _ [Occ=Dead] { } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11632: Data.Char repeated readLitChar barfs on output from show "ó1"
by GHC 25 Aug '16

25 Aug '16

#11632: Data.Char repeated readLitChar barfs on output from show "ó1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- "ó1" is "\243\&1" and when shown that's "\"\\243\\&1\"" {{{#!hs readLitChar "\"\\243\\&1\"" = [("\"", "\243\\&1")] readLitChar "\243\\&1" = [("\243", "\\&1")] --should have consumed "\\&" readLitChar "\\&1" = [] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11632> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function
by GHC 25 Aug '16

25 Aug '16

#12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Summary: Unlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation. Oddly enough, triggering the issue requires using the function argument indirectly through a variable bound by a "where" clause, even though it is obvious to a human reader that the indirection is trivial. (Even after simplifying the original code to work around the out of memory issue, that indirection greatly increases the size of the ".dump-hi" file. It might be that the "out of memory" would not happen if one had sufficient RAM.) Using INLINABLE instead of INLINE seems to result in a much smaller RHS being recorded for the function in question, and does not trigger the problem. (Perhaps INLINABLE records a more optimized RHS than does INLINE, though that is not obvious to me from the GHC User's Guide.) The attached files contain a reduced version of the original code that still triggers the problem. (Of course, the reduced version is rather artificial and pointless, other than to demonstrate the problem.) Probably someone with sufficient understanding could shrink the example further. Please note that I have worked around the issue, and so I am not blocked by this problem, at least not currently. Attachments: - crash.bash - Crash.hs Observed behavior: On 64-bit x86 Ubuntu 16.04 LTS, with the attached files in the current directory, GHC 7.10.2 succeeds: {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 7.10.2 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) }}} whereas GHC 8.0.1 runs out of memory (or wedges my system if I comment out both "ulimit" commands in the script): {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 8.0.1 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) ghc: out of memory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12195: RTS GetTime.c is broken on Darwins that include clock_gettime
by GHC 25 Aug '16

25 Aug '16

#12195: RTS GetTime.c is broken on Darwins that include clock_gettime -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC fails to build on versions of Darwin which include `clock_gettime`. On Darwin versions which include `clock_gettime`, the `#ifdef`s are structured to prefer using `clock_gettime` over the mach-specific time functions and structs; however, a couple of places in GetTime.c use the mach functions unconditionally even though the `mach/mach_time.h` header won't be included if `clock_gettime` is available. The attached patch fixes this by checking `HAVE_CLOCK_GETTIME` first before checking if the OS is Darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12354: Word foldl' isn't optimized as well as Int foldl'
by GHC 25 Aug '16

25 Aug '16

#12354: Word foldl' isn't optimized as well as Int foldl' -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Data.List test :: Int -> Int test n = foldl' (+) 0 [1..n] main :: IO () main = do print $ test $ 10^8 }}} GHC optimizes the above code to the point that the garbage collector doesn't even have to do anything: {{{ $ ghc -rtsopts -O2 testInt && ./testInt +RTS -s [1 of 1] Compiling Main ( testInt.hs, testInt.o ) Linking testInt ... 5000000050000000 51,752 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s INIT time 0.000s ( 0.000s elapsed) MUT time 0.101s ( 0.101s elapsed) GC time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.103s ( 0.102s elapsed) %GC time 0.1% (0.1% elapsed) Alloc rate 511,162 bytes per MUT second Productivity 99.8% of total user, 100.9% of total elapsed }}} However, if I change the type of {{{test}}} to {{{test :: Word -> Word}}}, then a lot of garbage is produced and the code runs 40x slower: {{{ ghc -rtsopts -O2 testWord && ./testWord +RTS -s [1 of 1] Compiling Main ( testWord.hs, testWord.o ) Linking testWord ... 5000000050000000 11,200,051,784 bytes allocated in the heap 1,055,520 bytes copied during GC 44,384 bytes maximum residency (2 sample(s)) 21,152 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 21700 colls, 0 par 0.077s 0.073s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s INIT time 0.000s ( 0.000s elapsed) MUT time 4.551s ( 4.556s elapsed) GC time 0.077s ( 0.073s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 4.630s ( 4.630s elapsed) %GC time 1.7% (1.6% elapsed) Alloc rate 2,460,957,186 bytes per MUT second Productivity 98.3% of total user, 98.3% of total elapsed }}} I expected the performance to be nearly identical. I'm using GHC version 8.0.1 on x86_64 Arch Linux. I asked about this on stackoverflow, and the issue appears to be related to rewrite rules: [http://stackoverflow.com/a/38113639/6531137] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by GHC 25 Aug '16

25 Aug '16

#12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot} -------------------------------------+------------------------------------- Reporter: dudebout | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Keywords: pkgroot | 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: -------------------------------------+------------------------------------- When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash. Default behavior: $ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Correct behavior (no trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Incorrect behavior (with trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}. This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 25 Aug '16

25 Aug '16

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 3ae474d18251d4e9184bf5d6cbce6ac86fdd46c1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0