September 2017 - ghc-tickets

[GHC] #9198: large performance regression in type checker speed in 7.8
by GHC 02 Oct '17

02 Oct '17

#9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{ begin cont = cont (return ()) a m =cont (m >> putstrn "a") end m = m main = begin a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{ main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{ main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13397: Optimise calls to tagToEnum#
by GHC 02 Oct '17

02 Oct '17

#13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Ever since we started using `Int#` to represent booleans unboxed (see [wiki:PrimBool]) we have had lots of code looking like {{{ case tagToEnum# (a ># b) of False -> e1 True -> e2 }}} It would be better (less code to optimise, more straightforward, more direct) to optimise this to {{{ case a ># b of DEFAULT -> e1 1# -> e2 }}} Happily, we already have a nice spot to do so: the `caseRules` function in `SimplUtils`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation
by GHC 02 Oct '17

02 Oct '17

#11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation ----------------------------------------+------------------------------- Reporter: YoYoYonnY | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Here's a "fun" one: {{{#!hs *Main> main Interrupted. *Main> *Main> !cl ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} Don't mind the {{{!cl}}}, GHC crashed as soon as the interupt was registered, I usually {{{:!cls}}} after I execute main. I will backup the code in case someone wants to see if it's a bug in my program, but I didn't use multithreading myself, and I don't think the vector, unordered-containers, bytestring and parsec packages use threading either (all heavily at work, though)... The interupt was nececairy because my code was generating a infinite (oops) collection of these bad boys, using all sorts of folds, maps, etc.: {{{#!hs newtype ParserData = ParserData { unpackParserData :: HashMap ByteString (ParserData -> Either ByteString (Parser ())) } }}} I am wondering if this could be a problem with Windows, because the system was running slow at the time of the interupt; The {{{Alt+Tab}}} screen didn't appear until after the interupt. I don't think I can manage to reproduce this bug, which is unfortunate aswell (low priority because of that :c). Either way, it crashed, that's all I can tell you for sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function?
by GHC 02 Oct '17

02 Oct '17

#14299: GHCi for GHC 8.2.1 crashed with simple function? --------------------------------------+------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I'm a newbie here, but I'm following your instructions! I started GHCi, defined a simple factorial function and then called it and... it crashed. {{{#!hs let f 0 = 0 f n = n * f (n-1) f 0 }}} That is what I introduced in the console... After that computer hanged and gave me the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11963: GHC introduces kind equality without TypeInType
by GHC 02 Oct '17

02 Oct '17

#11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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 following program is accepted by GHC 8.0 rc2 {{{ {-# LANGUAGE GADTs, PolyKinds, RankNTypes #-} data Typ k t where Typ :: (forall (a :: k -> *). a t -> a t) -> Typ k t }}} This probably shouldn't be accepted, because this is a circuitous way of saying: {{{ {-# LANGUAGE TypeInType #-} data Typ k (t :: k) = Typ }}} which does not work without `TypeInType`. Or perhaps both should be accepted without `TypeInType`? Printing with explicit kinds makes it clear why the obvious check didn't fire: {{{ ezyang@sabre:~$ ghc-8.0 --interactive B.hs -fprint-explicit-kinds GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( B.hs, interpreted ) Ok, modules loaded: Main. *Main> :info Typ type role Typ nominal nominal nominal data Typ k k1 (t :: k) where Typ :: forall k (t :: k). (forall (a :: k -> *). a t -> a t) -> Typ k k t -- Defined at B.hs:2:1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout
by GHC 01 Oct '17

01 Oct '17

#10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{RTS -qa}}} option that can set thread affinity was implemented in https://git.haskell.org/ghc.git/commitdiff/31caec794c3978d55d79f715f21fb729… {{{ // Schedules the thread to run on CPU n of m. m may be less than the // number of physical CPUs, in which case, the thread will be allowed // to run on CPU n, n+m, n+2m etc. void setThreadAffinity (nat n, nat m) }}} Today I discovered that on some machines, this option helps parallel performance (e.g. {{{+RTS -N4}}}) a lot, while on others it doesn't. Together with thomie on #ghc, I found out the reason: Lets assume I have 4 real cores with hyperthreading, so 8 virtual cores. The mapping of hyperthreading cores to physical cores is different across machines. On my one machine (Intel i5), the layout is 11223344, meaning that the first two vCPUs (hyperthreads) that the OS announces (visible e.g. in HTOP) map to the first physical core in the system, and so on. On my other machine (Intel Xeon), the layout is 12341234; here the 1st and the 5th vCPU map to the same physical core. This layout can be (on Linux) observed by running: {{{ cat /proc/cpuinfo|egrep "processor|physical id|core id" |sed 's/^processor/\nprocessor/g' }}} I do not know whether this layout is dictated by the processor, chosen by the OS, or even changing across reboots; what is clear is that the layout can vary across machines. Now, as explained by thomie: {{{ -qa will set your 4 capabilities to cores [(1,5), (2,6), (3,7), (4,8)], and then the os randomly chooses out of those tuples }}} This strategy is optimal for the 12341234 layout; for example, when running with -N4, it ensures that two threads are not scheduled onto vCPUs that are on the same physical core. The possible {{{+RTS -aq}}} choice {{{1__4_23_}}} is a great assignment in this case, as is {{{1234____}}} ({{{_}}} means the vCPU is not chosen). But for the 11223344, the choice {{{1234____}}} isn't good, because it uses only 2 of our 4 physical cores; our program now takes twice as long to run. ---- It seems likely to me that {{{setThreadAffinity}}} was written on a machine with 12341234 layout, and with the assumption that all machines have this layout. It would be great if we could change it to take the actual layout into account. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14284: -Weverything is undocumented
by GHC 30 Sep '17

30 Sep '17

#14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since version 8.0.1, GHC apparently has a `-Weverything` flag (see https://phabricator.haskell.org/D1850) but it doesn't seem to be documented either on the flag reference page or anywhere in the manual: * https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html * https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#options-sanity -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14287: Early inlining causes potential join points to be missed
by GHC 30 Sep '17

30 Sep '17

#14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While trying to make stream fusion work with recursive step functions I noticed that the following filter implementation did not fuse nicely. {{{#!haskell data Stream s a = Stream (s -> Step s a) s data Step s a = Done | Yield a s sfilter :: (a -> Bool) -> Stream s a -> Stream s a sfilter pred (Stream step s0) = Stream filterStep s0 where filterStep s = case step s of Done -> Done Yield x ns | pred x -> Yield x ns | otherwise -> filterStep ns fromTo :: Int -> Int -> Stream Int Int {-# INLINE fromTo #-} fromTo from to = Stream step from where step i | i > to = Done | otherwise = Yield i (i + 1) sfoldl :: (b -> a -> b) -> b -> Stream s a -> b {-# INLINE sfoldl #-} sfoldl acc z (Stream !step s0) = oneShot go z s0 where go !y s = case step s of Done -> y Yield x ns -> go (acc y x) ns ssum :: (Num a) => Stream s a -> a ssum = sfoldl (+) 0 filterTest :: Int filterTest = ssum $ sfilter even (fromTo 1 101) }}} For this code to work nicely, GHC should detect that filterStep is a join point. However, in the definition of sfilter it is not because not all references are tail-called & saturated. After inlining of sfilter and some trivial case-of-case transformations filterStep should become a join point. But it seems like the simplifier never gets the change to do this because float-out optimization makes filterStep a top level binding. With -fno-full-laziness filterStep does become a join point at the call site, but of course this is not really a solution. Then I found that the following also works: {{{#!haskell sfilter :: (a -> Bool) -> Stream s a -> Stream s a sfilter pred (Stream step s0) = Stream filterStep s0 where {-# INLINE [2] filterStep #-} filterStep s = case step s of Done -> Done Yield x ns | pred x -> Yield x ns | otherwise -> filterStep ns }}} Simply adding an INLINE [2] pragma disables the inlining in the early run of the simplifier. Therefore, the float out pass does not get the change to float-out before the filterStep is recognized as a joint point. Or at least that is my interpretation of what is going on. What surprises me about this issue is that the gentle run seems to perform inlining while the wiki mentions that inlining is not performed in this stage: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline Intuitively, I would think that floating-out is sub-optimal when the simplifier did not use all its tricks yet, because inlining typically opens up possibilities for simplification while floating-out typically reducing these possibilities. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax`
by GHC 30 Sep '17

30 Sep '17

#14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Being open-minded, I played around with TH quotations and encountered a strange error message: TyFamWitnesses.hs:106:40-71: error: • No instance for (Lift Exp) arising from a use of ‘lift’ • In the expression: lift eqTypeRep In the expression: {{{ [| eqTypeRep (typeRep @Maybe) |] pending(rn) [<eqTypeRep, lift eqTypeRep>] In an equation for ‘fun'’: fun' = [| eqTypeRep (typeRep @Maybe) |] pending(rn) [<eqTypeRep, lift eqTypeRep>] | 106 | fun' = [e|eqTypeRep (typeRep @ Maybe)|] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Failed, 0 modules loaded. Adding an orphan instance locally helped (of course). {{{#!hs instance Lift Exp where lift = pure }}} It appears to be the right thing to do... Why isn't this in `Language.Haskell.TH.Syntax`? Just forgotten? If so, and somebody gives me a thumbs up, I'll add it tomorrow to HEAD (with a corresponding @since annotation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10941: Large heap address space breaks valgrind
by GHC 29 Sep '17

29 Sep '17

#10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | -------------------------------------+------------------------------------- It seems that programs compiled with a GHC `--enable-large-address-space` (see #9706) no longer run under valgrind, which is a pitty, as that is useful to get more reliable numbers out of nofib. It fails with `internal error: getMBlock: mmap: Invalid argument` This bug is a general “Can we do anything about this”. In particular, is there a possibility to make this a RTS option instead of a compile time option? Or maybe it is possible to talk to the valgrind authors if they can support such large allocations? If neither, can we maybe extend the error message to say “If you are using a tool like valgrind, you might want to recompile the compiler with `--disable-large-address-space.” -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3