October 2018 - ghc-tickets

[GHC] #14037: Fix fusion for GHC's utility functions
by GHC 05 Mar '19

05 Mar '19

#14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a patchset I'm working on, I encountered a smallish "bytes allocated" regression in `perf/compiler/T5631`. After some sleuthing, I discovered that the regression is caused by using a `zipWith3M` where previously there was a `zipWithM`. Interestingly, it was not the zipped function that caused the problem, but the `zipWith3M` itself. Further sleuthing found that `zipWithM` is inlined into a combination of `sequenceA` and `zipWith`, both of which have been taught to work nicely with fusion. I thought of doing the same to GHC's `zipWith3M`, but I discovered that `base`'s `zipWith3` has no rules or inlining pragmas, suggesting that it does not fuse. I was quite surprised to find this, thinking that all functions as basic as `zipWith3` in `base` would play nicely with fusion. (Perhaps it does fuse -- I didn't actually check.) I then checked out GHC's `MonadUtils`, which defines a bunch of functions, some of which must be hammered on, and only one of which has any kind of performance- enhancing pragma. (The one is `zipWithAndUnzipM`, whose `INLINABLE` pragma was added only after much pain suffered by your dear author.) So: this ticket is a request to sweep through `MonadUtils` and `Util` and perhaps `ListSetOps`, looking for performance enhancements via fusion, tighter definitions, and such. Also, get `zipWith3` (and the other `zipWith`s) to fuse in `base`. I figure this is all some fairly low-hanging fruit for performance improvements in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15072: Teach the testsuite driver about response files
by GHC 05 Mar '19

05 Mar '19

#15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Currently `T14697` is disabled on Windows as that test produces a long enough command-line (mostly `-D` flags) that it runs amok of the Windows command-line length limit. It seems like the solution here will be to teach the testsuite driver to invoke GHC with a response file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15508: concprog001 fails with various errors when compiled with -prof
by GHC 05 Mar '19

05 Mar '19

#15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5051 | Wiki Page: -------------------------------------+------------------------------------- I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. Reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet. It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49

[GHC] #14671: Make the Template Haskell class Lift work over typed expressions
by GHC 05 Mar '19

05 Mar '19

#14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment we have the `Lift` class in TH: {{{ class Lift t where lift :: t -> Q Exp }}} But that loses type information. What we want is this: {{{ Lift t where typedLift :: t -> Q (TExp t) lift :: Lift t => t -> Q Exp lift = fmap unType . typedLift }}} Otherwise, when you want the typed version, people resort to unsafe-coerce operations, which are entirely unnecessary. See [https://mail.haskell.org/pipermail/libraries/2018-January/028409.html this thread on the libraries list]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15840: Inline data constructor wrappers very late
by GHC 05 Mar '19

05 Mar '19

#15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach. Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1). I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own. The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor: In {{{#!hs case $WK u of { K x -> e; … } }}} `$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable. Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers. Let's take an unpacking wrapper as an example: {{{#!hs data T = MkT {-# UNPACK #-} !(Int, Bool) $WMkT p = case p of (i,b) -> MkT i b }}} We have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr]) }}} to {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr]) }}} Where `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass). We then need to change case-of-known-constructor to also perform case-of- lets and case-of-cases when such floats are found. In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately. Does anyone sees something which could go wrong with this plan? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8657: -fregs-graph still has a limit on spill slots
by GHC 05 Mar '19

05 Mar '19

#8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15471: Polymorphism, typed splices and type inference don't mix
by GHC 05 Mar '19

05 Mar '19

#15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- Trying to quote and splice a polymorphic function doesn't work unless you have a type signature. {{{ {-# LANGUAGE TemplateHaskell #-} module A where foo1 x = x test_foo = [|| foo1 ||] }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B where import A qux = $$(test_foo) }}} The type of `qux` is `Any -> Any`! Which is clearly wrong. Adding a type signature to `qux` fixes the problem. {{{ qux :: a -> a qux = $$(test_foo) }}} Either there should be a better error or this should just work. It seems that this has always been broken. Ryan tested on GHC 7.8.4 for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12919: Equality not used for substitution
by GHC 05 Mar '19

05 Mar '19

#12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ Op.hs:20:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at Op.hs:19:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15549: Core Lint error with empty closed type family
by GHC 05 Mar '19

05 Mar '19

#15549: Core Lint error with empty closed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program gives a Core Lint error on GHC 8.2.2 and later: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Void data family Sing (a :: k) data V1 :: Type -> Type data instance Sing (z :: V1 p) class Generic a where type Rep a :: Type -> Type to :: Rep a x -> a class PGeneric a where type To (z :: Rep a x) :: a class SGeneric a where sTo :: forall x (r :: Rep a x). Sing r -> Sing (To r :: a) ----- instance Generic Void where type Rep Void = V1 to x = case x of {} type family EmptyCase (a :: j) :: k where instance PGeneric Void where type To x = EmptyCase x instance SGeneric Void where sTo x = case x of }}} {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -dcore-lint -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘(Sing (D:R:RepVoid[0] <x_a12p>_N) <r_a12q>_N)_R’ Function kind = forall k. k -> * Arg kinds = [(V1 x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘D:R:SingV1z0[0] <x_a12p>_N <r_a12q>_N’ Function kind = V1 x_a12p -> * Arg kinds = [(r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘D:R:SingV1z0[0] <x_a12p>_N <r_a12q>_N’ Function kind = V1 x_a12p -> * Arg kinds = [(r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) <no location info>: warning: In the type ‘R:SingV1z x_a12p r_a12q’ Kind application error in type ‘R:SingV1z x_a12p r_a12q’ Function kind = forall p -> V1 p -> * Arg kinds = [(x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) <no location info>: warning: In the type ‘R:SingV1z x_a12p r_a12q’ Kind application error in type ‘R:SingV1z x_a12p r_a12q’ Function kind = forall p -> V1 p -> * Arg kinds = [(x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) *** Offending Program *** <elided> $csTo_a12n :: forall x (r :: Rep Void x). Sing r -> Sing (To r) [LclId, Arity=1, Str=<L,U>x, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] $csTo_a12n = \ (@ x_a12p) (@ (r_a12q :: Rep Void x_a12p)) (x_aZ8 :: Sing r_a12q) -> case x_aZ8 `cast` ((Sing (D:R:RepVoid[0] <x_a12p>_N) <r_a12q>_N)_R ; D:R:SingV1z0[0] <x_a12p>_N <r_a12q>_N :: (Sing r_a12q :: *) ~R# (R:SingV1z x_a12p r_a12q :: *)) of nt_s13T { } }}} GHC 8.0.2 does not appear to suffer from this Core Lint error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14729: normaliseType is not well-kinded
by GHC 05 Mar '19

05 Mar '19

#14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Suppose we have {{{ Proxy :: forall k. k -> Type type family F a type instance F Int = Bool }}} and we're trying to normalise the target {{{ Proxy (F Int) x }}} Clearly, for this target to be well kinded, we need `x :: F Int`. Currently, the output of `normaliseType` is `Proxy Bool x`, which is just plain wrong. I need to implement logic like in `flatten_args` on [https://github.com/goldfirere/ghc my branch] in `normaliseType` to fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15