March 2017 - ghc-tickets

[GHC] #12599: Add Hadrian build artifacts to gitignore
by GHC 26 Jan '19

26 Jan '19

#12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Andrey wrote requesting the following, > For top-level `.gitignore`: > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, **/stageN/ folders will be relocated to _build/ after > # resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > _build/ > hadrian/ > **/stage?/ > }}} > > For `.gitignore` in affected submodules (array, deepseq, directory, filepath, > hoopl, hpc, process, utils/hsc2hs): > > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, stageN/ folders will be relocated to top-level _build/ > # after resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > stage?/ > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9476: Implement late lambda-lifting
by GHC 25 Jan '19

25 Jan '19

#9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02`
by GHC 24 Jan '19

24 Jan '19

#13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | 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: -------------------------------------+------------------------------------- See the attached file. The compilation time grows exponentially with additional fields in `HuteStruct`. Tried with GHC-8.0.1 and quite recent HEAD (8.2) adding a field doubles the compilation time with `-O2`. - 9: 17s - 10: 34s - 11: 83s on my machine. With `-01` around 3sec, independently of the struct size. The original issue: https://github.com/yesodweb/yesod/issues/1348 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #12920: Overzealous unused-top-binds
by GHC 24 Jan '19

24 Jan '19

#12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example produces three warnings: {{{ module Foo () where type A = Int type B = A foo :: IO () foo = print (bar 3 :: B) bar :: a -> a bar = id }}} `ghci Foo -Wall` produces {{{ GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘B’ Foo.hs:8:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ Foo.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ Ok, modules loaded: Foo. }}} The three errors reported are inconsistent because GHC reports that `B` is unused, but somehow feels that `A` *is* used. It seems to me that two possibilities could work: 1. GHC reports 1 error: GHC should only report that `foo` is unused, since `A` is used in `B`, `B` is used in `foo`, and `bar` is used in `foo`. This seems like the best approach to me. 2. GHC reports 4 errors: One might choose to apply the definition of "unused" transitively so that, since `foo` is unused, everything used in `foo` is considered unused (unless "used" elsewhere). In this case, `A` should also be reported as unused, but it currently isn't. This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12953: Use computed gotos in the interpreter when the compiler supports it
by GHC 23 Jan '19

23 Jan '19

#12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: interpreter | 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: -------------------------------------+------------------------------------- We can use computed gotos to speed up the interpreter on systems that support them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 22 Jan '19

22 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13452: Lock .tix file
by GHC 19 Jan '19

19 Jan '19

#13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | 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: -------------------------------------+------------------------------------- The HPC documentation [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… #caveats-and-shortcomings-of-haskell-program-coverage warns] that > HPC does not attempt to lock the `.tix` file, so multiple concurrently running binaries in the same directory will exhibit a race condition. This sounds like something that shouldn't be too terribly hard to fix, once we determine exactly how we want to deal with contention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9279: Optimisation bug
by GHC 18 Jan '19

18 Jan '19

#9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11126: Entered absent arg in a Repa program
by GHC 18 Jan '19

18 Jan '19

#11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs module Main where import Data.Array.Repa data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show through :: Maybe Double -> Stuff -> Stuff m `through` (a `With` _) = let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a)) c = maybe b (const (negate `smap` a)) m in computeUnboxedS c `With` sumAllS b main :: IO () main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1) }}} It should produce the following result once run. {{{#!hs AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0 }}} However, when built using `repa-3.4.0.1` and compiled with the options `-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`, it crashes as follows. {{{#!hs Main: Oops! Entered absent arg arr2 Array D DIM1 Double }}} Adding `-fno-strictness` to the compiler options or removing strictness annotations from the code makes the problem disappear, so this looks like a strictness analyzer problem. The libraries used were * `QuickCheck-2.8.1`, * `array-0.5.1.0`, * `base-4.8.1.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `pretty-1.1.2.0`, * `primitive-0.6`, * `random-1.1`, * `repa-3.4.0.1`, * `template-haskell-2.10.0.0`, * `tf-random-0.5`, * `time-1.5.0.1`, * `transformers-0.4.2.0` and * `vector-0.10.12.3`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10918: Float once-used let binding into a recursive function
by GHC 18 Jan '19

18 Jan '19

#10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Consider this code {{{#!hs let x = f x0 in let go 10 = x go i = go (i+1) in go (0::Int) }}} Currently, this is pretty much the core that comes out at the end. But what we want to see instead is {{{#!hs let go 10 = let x = f x 0 in x go i = go (i+1) in go (0::Int) }}} In general, we do not want to float a binding into a recursive function, because we would risk doing the allocation and/or evaluation of it multiple times. But in this case, we can see that it is going to be used at most once, so it is safe to do so. Even more: In the slightly less contrived examples that I was looking at, the call to `x` was happening in the a less likely code path, so this way we’d avoid doing the allocation in most cases, a clear win. It might be enough to simply make `CallArity` (or rather the cardinality analysis done by call arity) tell the rest of the compiler that it found that `x` is called at most once, and hopefully the simplifier knows what to make of that information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14