November 2018 - ghc-tickets

[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

[GHC] #13322: Pattern synonyms in hs-boot files
by GHC 24 Dec '18

24 Dec '18

#13322: Pattern synonyms in hs-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Pattern synonyms are not permitted in hs-boot files: {{{ ezyang@sabre:~/bun$ ghc-head -c A.hs-boot A.hs-boot:3:5: error: Misplaced pattern synonym signature: pattern X :: Bool | 3 | pattern X :: Bool | ^^^^^^^^^^^^^^^^^ A.hs-boot:3:13: error: The pattern synonym signature for ‘X’ lacks an accompanying binding | 3 | pattern X :: Bool | }}} There isn't really any reason why they shouldn't be supported. One thing to check closely: if we bundle a pattern synonym declared in an hs-boot file with another type, in an hs-boot file, what happens? In particular, does an hs file which doesn't bundle the pattern synonym and the type valid? If we add support for them, make sure that Backpack signatures handle it properly. In particular, suppose we have: {{{ signature A(T(X)) where data T pattern X :: T }}} Then, when we instantiate A, we must be careful to NOT blindly reuse the implementing module of T for X (as we do today in `uAvailInfo` in `NameShape`), since T and X may be defined in different modules. I'm not likely to implement this unless someone asks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15298: Support spliced function names in type signatures in TH declaration quotes
by GHC 24 Dec '18

24 Dec '18

#15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature | Status: new request | 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: #11129 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work. According to [https://stackoverflow.com/a/32279198/470844 this StackOverflow answer], the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`. {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH fName :: Name fName = mkName "f" fTy :: TypeQ fTy = [t| Int |] fBody :: ExpQ fBody = [e| 3 |] -- | Not allowed: -- -- @ -- error: -- Invalid type signature: $fName :: ... -- Should be of form <variable> :: <type> -- @ -- -- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous -- error. fDecl1 :: DecsQ fDecl1 = [d| $fName :: $fTy $(varP fName) = $fBody |] -- | Not allowed: -- -- @ -- error: -- Splices within declaration brackets not (yet) handled by Template Haskell -- @ fDecl2 :: DecsQ fDecl2 = [d| $((:[]) <$> sigD fName fTy) $(varP fName) = $fBody |] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15274: Numerous validation failures when building GHC with LLVM
by GHC 23 Dec '18

23 Dec '18

#15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (LLVM) | 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 CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: {{{ TEST="ClosedFam1TH T10508_api T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12478_1 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 prog001 scc001 scc002 scc003 scc005" }}} Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11534: Allow class associated types to reference functional dependencies
by GHC 22 Dec '18

22 Dec '18

#11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs class Foo i j | i -> j where type Bar i :: * type Bar i = j }}} This is rejected as `j` is not an argument to `Bar`, but when we realize any instance `j` will be a known type, determined by `i`, as told to us by the | i -> j functional dependency on the class. This would likely require some sort of extra pass over the instances with class associated types of this form to elaborate them, or a slight modification of the default signature implementation for class associated types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened
by GHC 21 Dec '18

21 Dec '18

#15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: type checker | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following, a plugin will receive a wanted constraint that includes a `fsk` flattening skolem. {{{ -- "Reduced" via the plugin type family F u v where {} type family G a b where {} data D p where DC :: (p ~ F x (G () ())) => D p }}} (Please ignore the apparent ambiguity regarding `x`; the goal is for the plugin to eliminate any ambiguity.) A do-nothing plugin that merely logs its inputs gives the following for the ambiguity check on DC. {{{ given [G] $d~_a4oh {0}:: (p_a4o2[sk:2] :: *) ~ (p_a4o2[sk:2] :: *) (CDictCan) [G] $d~~_a4oi {0}:: (p_a4o2[sk:2] :: *) ~~ (p_a4o2[sk:2] :: *) (CDictCan) [G] co_a4od {0}:: (G () () :: *) ~# (fsk_a4oc[fsk:0] :: *) (CFunEqCan) [G] co_a4of {0}:: (F x_a4o3[sk:2] fsk_a4oc[fsk:0] :: *) ~# (fsk_a4oe[fsk:0] :: *) (CFunEqCan) [G] co_a4og {1}:: (fsk_a4oe[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CTyEqCan) derived wanted [WD] hole{co_a4or} {3}:: (F x_a4o6[tau:2] fsk_a4oc[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CNonCanonical) untouchables [fsk_a4oe[fsk:0], fsk_a4oc[fsk:0], x_a4o3[sk:2], p_a4o2[sk:2]] }}} Note the `fsk_a4oc[fsk:0]` tyvar in the Wanted constraint, which is why I'm opening this ticket. Its presence contradicts the "The wanteds will be unflattened and zonked" claim from https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Callingpluginsfro… section. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8949: switch -msse2 to be on by default
by GHC 21 Dec '18

21 Dec '18

#8949: switch -msse2 to be on by default ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.9 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant. Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways. Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform. GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types
by GHC 21 Dec '18

21 Dec '18

#15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds #-} module A where data family D :: k type family F (a :: k) :: * type instance F (D Int) = Int type instance F (f a b) = Char type instance F (D Int Bool) = Char }}} The last equation, even though a specialization of the middle one, trips up the equality consistency check: {{{#!hs a.hs:9:15: error: Conflicting family instance declarations: F (D Int) = Int -- Defined at a.hs:9:15 F (D Int Bool) = Char -- Defined at a.hs:10:15 | 9 | type instance F (D Int) = Int | ^ }}} So GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11