January 2017 - ghc-tickets

[GHC] #13048: Splitter is O(n^2)
by GHC 07 Jan '17

07 Jan '17

#13048: Splitter is O(n^2) -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: split-objs | 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: -------------------------------------+------------------------------------- The splitter is O(local constants * total size of code), which is O(n^2^). This can be dealt with by not looping over each local constant, and instead scraping the local constants used from the assembler code and then looking them up in the hashtable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell
by GHC 07 Jan '17

07 Jan '17

#12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12976 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noticed in #12976. First, fire up GHCi 8.0.2 (or HEAD) and enable some options: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} Next, try looking at the kind of a regular unboxed tuple: {{{ λ> :k (#,#) (#,#) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} But when you splice in the unboxed tuple type constructor via Template Haskell, `:k` misbehaves: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep }}} This kind is totally wrong, since you //can// in fact apply this type constructor to types with kinds other than `*`: {{{ λ> :k $(unboxedTupleT 2) Int# Int# $(unboxedTupleT 2) Int# Int# :: TYPE 'UnboxedTupleRep }}} Moreover, this appears to be a regression since GHC 8.0.1, since if you try this in GHCi 8.0.1: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12896: Consider using compact regions in GHC itself to reduce GC overhead
by GHC 07 Jan '17

07 Jan '17

#12896: Consider using compact regions in GHC itself to reduce GC overhead -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 make mode, GHC keeps a lot of in-memory data structures about modules it has built and interface files it has read. These data structures are long-lived and immutable (at least, per module/mutually recursive module group/package), so they may be candidates for storing in compact regions to reduce the work done by the GC. Potential problem: if we rely heavily on lazy evaluation in these structures for the purpose of avoiding work that will never be needed, then we can't store them in a compact region (since the contents of a compact region must be fully evaluated). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9748: Disambiguate IO actions in GHCi with :set +t
by GHC 07 Jan '17

07 Jan '17

#9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently GHCi's `:set +t` displays the same type for the following: {{{#!hs % ghci -ignore-dot-ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char Prelude> return 'a' :: IO Char 'a' it :: Char }}} A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even <$> pure 5`), `:set +t` was suggested but ended up showing the incorrect type: {{{#!hs ghci> Id . even <$> pure 5 Id False it :: Id Bool }}} This is bad for pedagogical reasons, it would be an improvement to display the following: {{{#!hs Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char <- return 'a' :: IO Char Prelude> return 'a' :: IO Char 'a' it :: Char <- return 'a' :: IO Char }}} mirroring existing syntax: {{{#!hs Prelude> :set -XScopedTypeVariables Prelude> a :: Char <- return 'a' :: IO Char a :: Char }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #5654: Profiling semantics bug
by GHC 06 Jan '17

06 Jan '17

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"3a18baff06abc193569b1b76358da26375b3c8d6/ghc" 3a18baf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a18baff06abc193569b1b76358da26375b3c8d6" More fixes for #5654 * In stg_ap_0_fast, if we're evaluating a thunk, the thunk might evaluate to a function in which case we may have to adjust its CCS. * The interpreter has its own implementation of stg_ap_0_fast, so we have to do the same shenanigans with creating empty PAPs and copying PAPs there. * GHCi creates Cost Centres as children of CCS_MAIN, which enterFunCCS() wrongly assumed to imply that they were CAFs. Now we use the is_caf flag for this, which we have to correctly initialise when we create a Cost Centre in GHCi. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6166: Performance regression in mwc-random since 7.0.x
by GHC 06 Jan '17

06 Jan '17

#6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Ah, good to know, but mwc-random isn't a nofib program, even though it sounds like it could be. It's a package on hackage for generating random numbers. (You may be thinking of the k-nucleotide issue, which is a nofib program.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6166#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13074: Printing ~
by GHC 06 Jan '17

06 Jan '17

#13074: Printing ~ -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- {{{#! class Relation (r :: x -> x -> Type) instance Relation (~) }}} /home/samuel/Work/research/program/relations/src/Hmm.hs:35:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): print_equality ~ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This clearly isn't a terribly important bug, but I figured I'd leave it here as that was the request given by the error message. It's not code that should compile, but it shouldn't panic!. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 06 Jan '17

06 Jan '17

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => closed * resolution: => fixed Comment: I think we've done all we could here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1)
by GHC 06 Jan '17

06 Jan '17

#13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies | 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: -------------------------------------+------------------------------------- I was recently made aware that [http://hackage.haskell.org/package/vinyl vinyl]'s performance dramatically deteriorated with GHC 8.0.1 when compared to GHC 7.x. Vinyl is an extensible records library that's been around for about four years; the aspect of its design relevant here is the basic HList-style indexed GADT. Care was taken in the past so that working with, say, a `Storable` `Vector` of records would suffer no overhead from `vinyl` when compared with standard records, and we have a benchmark suite to spot check this. In the move to GHC-8.0.1, it turns out that we do introduce overhead. Inspecting the Core reveals that the benchmark inner loop includes a `case` match on an `HEq_sc` value whose presence I would not expect, and that is not present when compiling with GHC-7.10.3: {{{ case HEq_sc @ Nat @ Nat @ ('S 'Z) @ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)]) ($s$fRElemar:S_$s$fRElemar:S_$cp1RElem `cast` (N:~[0] <Nat>_N <'S 'Z>_N <RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)]>_N :: (('S 'Z :: Nat) ~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint) ~R# (('S 'Z :: Nat) ~~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint))) of cobox0 { __DEFAULT -> }}} I have since made an effort to reproduce the issue, and discovered more fragility than I expected. I am attaching two modules: `Rec.hs` defines a kind of record type, `Main.hs` is a test program that I will reproduce here, {{{ {-# LANGUAGE DataKinds #-} module Main where import Rec type MyRec = Rec '[ '("A",Int), '("B",Int), '("C",Int) ] getC :: MyRec -> Int getC = getField (Proxy::Proxy '("C",Int)) doubleC :: MyRec -> MyRec doubleC r = setC (2 * (getC r)) r where setC = set . (Field :: Int -> Field '("C",Int)) main :: IO () main = print (getC (Field 1 :& Field 2 :& Field 3 :& Nil :: MyRec)) }}} If the `doubleC` definition is present, the Core emitted (with `-O2`) includes an `HEq_sc` case in the RHS of `getC`. If `doubleC` is commented out, that `case HEq_sc ...` is no longer present. In this example, the offending piece of Core is, {{{ case HEq_sc @ Nat @ Nat @ (Index '("C", Int) '['("B", Int), '("C", Int)]) @ ('S 'Z) ($s$fHasFieldkr:S_$s$fHasFieldkr:S_$cp1HasField `cast` (N:~[0] <Nat>_N <Index '("C", Int) '['("B", Int), '("C", Int)]>_N <'S 'Z>_N :: ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~ ('S 'Z :: Nat) :: Constraint) ~R# ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~~ ('S 'Z :: Nat) :: Constraint))) of cobox1 { __DEFAULT -> }}} If the contents of `Rec.hs` are included in `Main.hs`, the `case HEq_sc ...` is not present in the resulting Core. The result of what looks like a failure to normalize the `Index` type family (or `RIndex` in `vinyl`) manifests as a 2x slowdown in the benchmark available in the `vinyl` repository. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault
by GHC 06 Jan '17

06 Jan '17

#13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- We should be able to use {{{#!hs fmapDefault :: Traversable t => (a -> b) -> t a -> t b fmapDefault = (getId .) #. traverse .# (Id .) foldMapDefault :: (Traversable t, Monoid m) => (a -> m) -> t a -> m foldMapDefault = (getConst .) #. traverse .# (Const .) }}} where `.#` and `#.` are coercion operators found in `Data.Profunctor.Unsafe`. This should help when the function passed in doesn't inline. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7