December 2018 - ghc-tickets

[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] #15842: Exponentiation needs PrelRules
by GHC 26 Dec '18

26 Dec '18

#15842: Exponentiation needs PrelRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When a user writes `a ^ lb`, where `lb` is an integer literal, the type of `lb` defaults to `Integer` unless it's annotated. If `lb` is very small, then `RULES` will expand the whole expression into a few multiplications. If not, the computation will pay the price of `Integer` arithmetic. If we want, we should be able to improve this with a special compilation rule. When `lb :: Integer`, and `0 <= lb <= maxBound :: Word`, we should be able to replace `lb` by the equivalent `Word`. The same problem appears with `^^` and `stimes`. Perhaps those can be fixed up as well, somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16095: Infinite loop during error reporting (unkillable, OOM)
by GHC 26 Dec '18

26 Dec '18

#16095: Infinite loop during error reporting (unkillable, OOM) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the repro snippet produces the following incomplete output and hangs GHC: {{{ $ ghc repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) repro.hs:16:22: error: }}} The GHC process then ignores Ctrl-C -- so it must be killed with SIGKILL. This minimal snippet depends on `generics-sop` (tested with version `0.4.0.0`). Sadly I didn't find a constraint in `base` to cause this behavior.. {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Generics.SOP (HasDatatypeInfo) data family TF i a :: * data instance TF i a = R class C i a where method :: TF i a instance C i () where instance HasDatatypeInfo a => C i a where method = undefined function function :: C i a => TF i a function = method main = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #15915: Add CI for integer-simple
by GHC 25 Dec '18

25 Dec '18

#15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Continuous | Version: 8.6.2 Integration | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16038: Simplifier incorrectly breaks recursive groups
by GHC 25 Dec '18

25 Dec '18

#16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I found this while looking at compile time panic in my code for #9718. The test that triggers the panic is `T4003`, but here's a simpler version of the test: {{{ -- T4003B.hs module T4003B where import {-# SOURCE #-} T4003A (HsExpr) data HsOverLit id = OverLit (HsExpr id) deriving Eq ----------------------------------- -- T4003A.hs-boot module T4003A where data HsExpr i instance Eq i => Eq (HsExpr i) ----------------------------------- -- T4003A.hs module T4003A where import T4003B data HsExpr id = HsOverLit (HsOverLit id) | HsBracketOut (HsExpr id) deriving Eq }}} Compile in this order: T4003A.hs-boot, T4003B.hs, T4003A.hs {{{ $ ghc-stage1 -O -c T4003A.hs-boot $ ghc-stage1 -O -c T4003B.hs $ ghc-stage1 -O -c T4003A.hs }}} The last step fails with a panic because in the new STG pass I implemented for #9718 I assume that all recursive groups are already in a `Rec`, but this program has a set of bindings that are actually recursive but not in a `Rec`. If I dump ds and simpl outputs of the last step I see that this recursive group: (in the ds output) {{{ Rec { -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V) -- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0} $c/=_a287 $c/=_a287 = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 -> $dm/= ($fEqHsExpr $dEq_a27V) eta_B2 eta_B1 -- RHS size: {terms: 37, types: 37, coercions: 0, joins: 1/3} $c==_a27X $c==_a27X = \ @ id_a27U $dEq_a27V -> let { $dEq_a283 $dEq_a283 = $fEqHsExpr $dEq_a27V } in let { $dEq_a281 $dEq_a281 = $fEqHsOverLit $dEq_a27V } in \ ds_d2jB ds_d2jC -> join { fail_d2jD fail_d2jD _ = False } in case ds_d2jB of { HsOverLit a1_a27Q -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsOverLit b1_a27R -> == $dEq_a281 a1_a27Q b1_a27R }; HsBracketOut a1_a27S -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsBracketOut b1_a27T -> == $dEq_a283 a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Becomes non-recursive in simplifier output: {{{ Rec { -- RHS size: {terms: 34, types: 45, coercions: 0, joins: 0/0} $fEqHsExpr_$c== $fEqHsExpr_$c== = \ @ id_a27U $dEq_a27V ds_d2jB ds1_d2jC -> case ds_d2jB of { HsOverLit a1_a27Q -> case ds1_d2jC of { HsOverLit b1_a27R -> case a1_a27Q of { OverLit a2_a2k8 -> case b1_a27R of { OverLit b2_a2kc -> == (noinline $fxEqHsExpr $dEq_a27V) a2_a2k8 b2_a2kc } }; HsBracketOut ipv_s2kg -> False }; HsBracketOut a1_a27S -> case ds1_d2jC of { HsOverLit ipv_s2kj -> False; HsBracketOut b1_a27T -> $fEqHsExpr_$c== $dEq_a27V a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 13, types: 10, coercions: 0, joins: 0/0} $fEqHsExpr_$c/= $fEqHsExpr_$c/= = \ @ id_a27U $dEq_a27V eta_B2 eta1_B1 -> case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of { False -> True; True -> False } -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($fEqHsExpr_$c== $dEq_a27V) ($fEqHsExpr_$c/= $dEq_a27V) -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Notice that `c==` refers to `fxEqHsExpr`, which refers to `fEqHsExpr`, which refers to `c==`, forming a recursive group. (Confirmed with GHC 8.6.3 and GHC HEAD) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

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

25 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 25 Dec '18

25 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