September 2018 - ghc-tickets

[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] #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] #14672: Make likelyhood of branches/conditions available throughout the compiler.
by GHC 28 Dec '18

28 Dec '18

#14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- For simple code such as `if a > 10 then foo else bar` it can make a big difference if we jump on `a > 10` or `a <= 10`. We already tracked the likelyhood of such conditionals for stack/heap checks in Cmm. I recently updated the native codegen on X86 to take this information into account where available and in one edge case this improved execution time from 1.7s to 1.5s! Having this info available for other cases like bound checking (assume valid) or partial pattern matches (assume no match failure) should be a small win for most programs and hopefully a big one for a few of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14375: Implement with# primop
by GHC 27 Dec '18

27 Dec '18

#14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | 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): Phab:D4110 | Wiki Page: -------------------------------------+------------------------------------- In Trac #14346 we proposed the new `with#` primop {{{ with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See Phab:D4110. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files
by GHC 26 Dec '18

26 Dec '18

#15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- Piyush has graciously volunteered to fix this. Relevant commit c5609577fab8a214c50561bea861c70d4bfd47c7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer
by GHC 26 Dec '18

26 Dec '18

#12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: backpack | 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 don't think this is a very harmful bug but it definitely is a bug. Consider: {{{ -- A.hs-boot module A where data T -- B.hs module B (module A) where import {-# SOURCE #-} A -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where import qualified B import Language.Haskell.TH f :: B.T -> B.T f x = x $( return [] ) data T = T B.T }}} The point of the splice is to convince GHC to typecheck `f :: B.T -> B.T` before it typechecks the type declaration. But this is not going to work, because `tcLookupGlobal` is going to bail if (1) T is not in the `tcg_type_env` and (2) T comes from this module. It would be a simple matter to improve the error message but from a user's perspective, there is no good reason for this to not typecheck. On the implementation side, I am sympathetic to not letting this typecheck: if it does typecheck, then some `TyCon`s will incorrectly refer to the definition from the hs-boot file, rather than our local definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc)
by GHC 24 Dec '18

24 Dec '18

#11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: perf/space_leaks/space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{ import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14758: Retainer profiler can overflow the C stack
by GHC 24 Dec '18

24 Dec '18

#14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 8.4.1-alpha1 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'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing instruction is a `mov _, ($rsp)`, I'm reasonable certain that the issue is a C stack overflow. The top of the stack looks like, {{{ #0 0x000000000249212c in retainClosure (c0=0x42af3459b8, cp0=cp0@entry=0x42af347000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1488 #1 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347000, bitmap=<optimized out>, size=<optimized out>, p=0x42af347260) at rts/RetainerProfile.c:1209 #2 retainStack (c=c@entry=0x42af347000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347370) at rts/RetainerProfile.c:1350 #3 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #4 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3473e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #5 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3473e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347690) at rts/RetainerProfile.c:1209 #6 retainStack (c=c@entry=0x42af3473e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347750) at rts/RetainerProfile.c:1350 #7 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345d88, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #8 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3477c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #9 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3477c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347a70) at rts/RetainerProfile.c:1209 #10 retainStack (c=c@entry=0x42af3477c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347b30) at rts/RetainerProfile.c:1350 #11 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3481a8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #12 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af347ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #13 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347ba0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347e50) at rts/RetainerProfile.c:1209 #14 retainStack (c=c@entry=0x42af347ba0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347f10) at rts/RetainerProfile.c:1350 #15 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348408, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #16 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #17 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af349000, bitmap=<optimized out>, size=<optimized out>, p=0x42af3492b0) at rts/RetainerProfile.c:1209 #18 retainStack (c=c@entry=0x42af349000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349370) at rts/RetainerProfile.c:1350 #19 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348668, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #20 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3493e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #21 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3493e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349690) at rts/RetainerProfile.c:1209 #22 retainStack (c=c@entry=0x42af3493e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349750) at rts/RetainerProfile.c:1350 #23 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3488c8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #24 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3497c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #25 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3497c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349a70) at rts/RetainerProfile.c:1209 #26 retainStack (c=c@entry=0x42af3497c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349b30) at rts/RetainerProfile.c:1350 #27 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #28 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 ... }}} and this goes on for at least 30000 frames. It looks very much like this is a bug in the retainer profiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9627: Type error with functional dependencies
by GHC 24 Dec '18

24 Dec '18

#9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached file should compile. The types T1, T2, and T3 are all equivalent types (T1 and T2 normalize to T3), but with foo::T1 and bar::T2 there is a type error. Rewriting the example using type families instead of FD makes it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4