April 2018 - ghc-tickets

[GHC] #14698: Cut STM release
by GHC 20 Apr '18

20 Apr '18

#14698: Cut STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14706: T11489 fails if run as root
by GHC 20 Apr '18

20 Apr '18

#14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.5 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: -------------------------------------+------------------------------------- The testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file for writing. However, when run as `root` the test succeeds. "What madman would compile GHC as `root`?" you ask? Well, CircleCI runs builds as `root` by default. It seems like running builds under Docker is one way around this, although this seems like a pretty large hammer just to eliminate a single test failure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14704: Spurious cost-centre test failures
by GHC 20 Apr '18

20 Apr '18

#14704: Spurious cost-centre test failures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- CircleCI seems to routinely turn up spurious differences in cost-center profiler tests, {{{patch --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:35.961616901 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:35.961616901 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:37.321632723 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:37.321632723 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:46.241736499 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:46.241736499 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:47.209747760 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:47.209747760 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15070: postInlineUnconditionally is too eager
by GHC 20 Apr '18

20 Apr '18

#15070: postInlineUnconditionally is too eager -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- In `nofib/spectal/mate`, look at `Move.moveDetailsFor`. In this function we inline a local definition {{{ bd = Board.rmPieceAt c_a25I sq_a2np bd_a25J }}} into two branches of a case (to hopefully avoid allocating it). I think this is `postInlineUnconditionally`. But then it is floated out and has to be laboriously CSE'd again! Maybe `postInlineUnconditionally` should be less aggressive. To quote the comment: {{{ -- So the main target is things like -- let x = f y in -- case v of -- True -> case x of ... -- False -> case x of ... -- This is very important in practice; e.g. wheel-seive1 doubles -- in allocation if you miss this out }}} and {{{ -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot-spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} At least for the second of these cases, we could do the float-in/inlining very late in the compilation pipeline, not all the time. For the first, it's not so clear, but worth experimenting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15069: Missed SpecConstr opportunity
by GHC 20 Apr '18

20 Apr '18

#15069: Missed SpecConstr opportunity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you look at the final Core for `Csg.calc` in `nofib/real/fulsom` you'll see missed opportunities for `SpecConstr`. It has nested join points which look like this: {{{ join j (x :: Double) = Board (case x of { D# y -> ... }) ... in ....(j (D# v)).... }}} So the call to $j$ ends up with an explicit `(D# v)` argument, and `SpecConstr` should catch it. But alas it does not because this happends nestedly, and `SpecConstr` is worried about exponential blowup. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11735: Optimize coercionKind
by GHC 20 Apr '18

20 Apr '18

#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Currently, the `ForAllCo` case of `coercionKind` does an inefficient one- variable substitution. This could be improved by looking for nested `ForAllCo`s. Furthermore, perhaps we don't need an in-scope set and the full substitution machinery here. The subst is simply propagating the update of a tyvar's kind. No structural changes at all. No need for smart coercion constructors or other processing. So if we're going to optimize this, it might be worth making a specialized version of `subst_ty` and `subst_co` that operate over a `VarEnv Var` instead of a full substitution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 87

[GHC] #13380: raiseIO# result looks wrong
by GHC 20 Apr '18

20 Apr '18

#13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13276: Unboxed sums are not Typeable
by GHC 20 Apr '18

20 Apr '18

#13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13261: Consider moving Typeable evidence generation wholly back to solver
by GHC 20 Apr '18

20 Apr '18

#13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15012: "Iface type variable out of scope" when compiling with -c
by GHC 20 Apr '18

20 Apr '18

#15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | 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: -------------------------------------+------------------------------------- Take these two files: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Generics type FakeOut a = Int data family TyFamily y z data instance TyFamily a b = TyFamily Int (FakeOut b) deriving Generic1 }}} {{{#!hs module Bar where import Foo import GHC.Generics main :: IO () main = print $ from1 $ TyFamily 1 2 }}} And compile them like so: {{{ $ ghc -c Foo.hs $ ghc -c Bar.hs ./Foo.hi Declaration for Rep1_R:TyFamilyab Axiom branches Rep1_R:TyFamilyab: Iface type variable out of scope: b Cannot continue after interface file error }}} I can reproduce this with every version of GHC from 7.8.4 onward, so this is quite an old bug! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6