June 2016 - ghc-tickets

[GHC] #12244: Idea: Remove unused symbols in link-time for smaller binaries
by GHC 29 Jun '16

29 Jun '16

#12244: Idea: Remove unused symbols in link-time for smaller binaries -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This caught my attention recently: https://github.com/ocaml/ocaml/pull/608 I think GHC could also benefit from this. I'm currently looking at an 8.0,1-generated executable, generated with -O2. In the code I defined some unused instances, just as an example, and I see code for those in text section in the binary. There is also lots of other unused stuff (I think mostly typeclass instances) imported from libraries and they're all unused because this is a "hello world" program that imports stuff and defines instances for no reason. There should be another ticket around here that reports some numbers on how big GHC-generated executables (and GHC itself) is (when compared with other compilers)... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12185: Can't call rank-2 function with type family constraint
by GHC 29 Jun '16

29 Jun '16

#12185: Can't call rank-2 function with type family constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following code compiles with 7.10.3: {{{ newtype Bar r = Pow r deriving (Eq) instance (Foo r) => Foo (Bar r) type family Ctx a where Ctx t = (Foo (Bar t), Eq (Bar t)) run :: (forall t . (Ctx t) => t -> Int) -> Int run g = undefined foo :: (Foo (Bar t)) => t -> Int foo = undefined main :: IO () main = print $ run foo }}} but fails in 8.0.1 with {{{ • Could not deduce (Foo t) arising from a use of ‘foo’ from the context: Ctx t bound by a type expected by the context: Ctx t => t -> Int at Main.hs:19:16-22 Possible fix: add (Foo t) to the context of a type expected by the context: Ctx t => t -> Int • In the first argument of ‘run’, namely ‘foo’ In the second argument of ‘($)’, namely ‘run foo’ In the expression: print $ run foo }}} This code seems valid to me: when I call `run foo`, `foo` is specialized to `(Foo (Bar t), Eq (Bar t)) => t -> Int)`, which meets the requirement of the argument to `run`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

freelance
by matthew＠wellquite.org 29 Jun '16

29 Jun '16

Hi, I've recently tried working as a freelance journalist and wrote some interesting articles, check it out <http://trequichaxa.samwilk.com/lnfrev> Yours, matthew(a)wellquite.org

1 0

[GHC] #12187: Clarify the scoping of existentials for pattern synonym signatures
by GHC 28 Jun '16

28 Jun '16

#12187: Clarify the scoping of existentials for pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12108 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- What are scoping rules for type variables in pattern synonym signatures? We said that existentials variables are scoped as follows: 1. Existentials scope over only the provided constraints and the arguments, not over the result type. {{{ type Disguised a b = b -> RP a pattern Q :: () => Eq b => Disguised a b }}} However, Simon argues that `Q` should be accepted as if we expand the type synonym then the existentially quantified `b` is no longer in the result type. Richard disagrees, he considers the result type to be `Disguised a b` and so `b` is in the result type and not in-scope. Therefore he wishes to reject this example. The purpose of this ticket is to decide the fate of `Q`. This kind of problem is related to #12108 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12207: CgStaticPointers fails with -O
by GHC 28 Jun '16

28 Jun '16

#12207: CgStaticPointers fails with -O -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple StaticPointers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: codeGen/should_run/CgStaticPointers| Blocking: | Related Tickets: #11656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ make TEST=CgStaticPointers slow }}} {{{ Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: CgStaticPointers: couldn't find StaticPtrInfo {spInfoUnitId = "main", spInfoModuleName = "Main", spInfoSrcLoc = (13,21)} CallStack (from HasCallStack): error, called at CgStaticPointers.hs:25:14 in main:Main *** unexpected failure for CgStaticPointers(optasm) }}} This seems to be caused by the patch for #11656 (36d29f7ce332a2b1fbc36de831b0eef7a6405555). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11471: Note [The kind invariant] in TyCoRep needs to be updated
by GHC 28 Jun '16

28 Jun '16

#11471: Note [The kind invariant] in TyCoRep needs to be updated -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This Note, found in TyCoRep, needs to be updated to reflect `TypeInType`. It should not reference `OpenKind`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #9078: Segfault with makeStableName
by GHC 28 Jun '16

28 Jun '16

#9078: Segfault with makeStableName ------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Calling `makeStableName` on the same object many times causes a segfault. The following triggers this behaviour on both OSX and Linux-x86_64, provided it is compiled (it doesn't seem to occur if the call to `makeStableName` is interpreted). {{{ module Main where import Control.Monad import System.Mem.StableName main :: IO () main = replicateM_ 100000 (makeStableName foo) foo :: Int foo = 1 }}} It seems to happen largely at random. The 100000 calls to `makeStableName` in the above example essentially guarantee its occurrence, but I have observed it happen with far fewer. The reason this bug was discovered is it is causing frequent failures in Accelerate on 7.8.2. See [https://github.com/AccelerateHS/accelerate/issues/162] In that case it seems to be causing more `strange closure type` errors than segfaults, but I assume it is the same root cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 27 Jun '16

27 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): One more small experiment. Before diving into the compiler internals, I thought it might be possible to do standard test case minimization. I.e. can we create some stub definitions for the relevant bits of `GHC.Generics`, while preserving the bad behavior? [https://gist.github.com/rrnewton/df17230b748df4ce1f06b49831348000 The file in this gist] attempts to do so, using the following stub definitions: {{{ class Generic a where from :: a -> M1 a data M1 a where M1 :: b -> M1 a data U1 p = U1 data (:+:) (f :: * -> *) (g :: * -> *) p = L1 (f p) | R1 (g p) }}} This is a lower bound -- it fails to produce the really slow behavior. It is simplified enough that the time for compiling just the "from" case drops from 5.7s all the way down to 0.85s. Getting back to the bad behavior will require putting more of the complexity of "M1" back into play... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 27 Jun '16

27 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): Small addendum. If you split this up and compile the "from" and "to" methods separately, it is clear that most of the work is in the "from". On the small-four constructor examples: Version 1: * 239 coercions with both to/from. * 200 coercions with just "from" * 39 coercions with just "to" Version 2: * 174 coercions with both to/from. * 132 with just from * 42 with just "to" And on the full-sized, 300-way sums, here are the realtime measurements on my personal machine: Version 1: * both: 639K coercions, 7.0s * from-only: 636.9K coercions, 5.7s * to-only: 2K coercions, 1.8s Version 2: * both: 9.9K coercions, 4.4s * from-only: 7.5K coercions, 3.6s * to-only: 2.4K coercions, 1.0s At least in the bigger case, it looks like there is a drop in realtime for both of the from/to methods, with the former being constructor-heavy, and the latter being deep-pattern-match-heavy. Slicing it another way, if we cut down the cases in the 300-way match for "from-only"/v1 -- leaving incomplete pattern matches -- the coercions/time drops as follows: * 300 cases -- 636.9K coercions, 5.7s * 150 cases -- 316K coercions, 4.0s * 100 cases -- 212K coercions, 2.5s * 50 cases -- 106K coercions, 1.3s * 25 cases -- 53K coercions, 0.8s And "from-only"/v2: * 300 cases -- 7.5K coercions, 3.7s * 150 cases -- 5.8K coercions, 2.8s * 50 cases -- 4.8K coercions, 1.1s * 25 cases -- 4.5K coercions, 0.7s Ok, so nothing that unusual in this dimension. As should be expected, the "factored" v2 gets a larger benefit over v1 the more cases the factored bit is amortized over. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES
by GHC 27 Jun '16

27 Jun '16

#7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): See also ticket:12077#comment:7. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0