June 2016 - ghc-tickets

[GHC] #12028: Large let bindings are 6x slower (since 6.12.x to 7.10.x)
by GHC 14 Jun '16

14 Jun '16

#12028: Large let bindings are 6x slower (since 6.12.x to 7.10.x) -------------------------------------+------------------------------------- Reporter: tommd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- See the attached somewhat reduced version of the main (manually unrolled) portion of an MD5 implementation taken from PureMD5. It used to compile in about 200ms, which is already bad enough, but now takes 1200 ms (ghc 6.12.3 to ghc 7.10.3 using -O2). I'd like to note that in my light testing the UNPACK pragma accounts for 400ms of this delta. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12032: Performance regression with large numbers of equation-style decls
by GHC 14 Jun '16

14 Jun '16

#12032: Performance regression with large numbers of equation-style decls -------------------------------------+------------------------------------- Reporter: tommd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- See the attached for a slice of code taken from Crypto-API that demonstrates a 2x regression in GHC compile times using -O2 (from 6.12.x to 7.10.x). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12190: Generalize irrefutable patterns (static semantics like let-bindings)
by GHC 14 Jun '16

14 Jun '16

#12190: Generalize irrefutable patterns (static semantics like let-bindings) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- tl;dr It is not let-bindings that should be generalized, it is **irrefutable** patterns that should be generalized. I know GHC's trend has been to reduce the amount of let-generalization we do (since it interacts poorly with GADTs). However, I was recently working with some useful rank-2 definitions, and found that I would have really appreciated let-style generalization for irrefutable pattern matches. Here is the motivating example: {{{ {-# LANGUAGE Rank2Types #-} {-# OPTIONS_GHC -fdefer-type-errors #-} module X where data IntStreamK k = Cons { hd :: Int, tl :: IntStreamK k } data IntStream = IntStream { unIntStream :: forall k. IntStreamK k } f1, f2, f3, f4 :: IntStream -> IntStream -- Does not work, type variable escapes f1 (IntStream (Cons x xs)) = IntStream (Cons (x + 1) xs) -- OK f2 (IntStream s) = IntStream (Cons (hd s + 1) (tl s)) -- Works UNLESS GADTs are enabled (uses let generalization) f3 (IntStream s) = let Cons x xs = s in IntStream (Cons (x + 1) xs) -- Does not work, type variable escapes f4 (IntStream ~(Cons x xs)) = IntStream (Cons (x + 1) xs) }}} `IntStreamK` is modeled off of a clock-indexed stream representation ala "Productive Coprogramming with Guarded Recursion" (c.f., http://bentnib.org/productive.pdf) although I've simplified the type a bit for this example. The important thing in this example `IntStream` takes a `IntStreamK` which is universally quantified over the clock index. I want to define a simple function: take a stream and increment its head (without using a record update). There are a number of very similar looking definitions, but only some of them typecheck; in the rest, `xs` fails to be sufficiently generalized. 1. `f1` is the most obvious code to write, but actually we can't elaborate this into Core: {{{ f1 = \ (x :: IntStream) -> case x of { IntStream s -> case s @ ??? of { Cons x xs -> IntStream (\ (@ k) -> Cons @ k (x+1) xs ) }} }}} The problem arises when we consider what type we will apply to `s` (which has type `forall k. IntStreamK k`): we want to use `k` bound by the type lambda inside `IntStream`, but it is not yet in scope! 2. `f2` works. Here is its Core elaboration: {{{ f2 = \ (x :: IntStream) -> case x of { IntStream s -> IntStream (\ (@ k) -> Cons @ k (hd (s @ k) + 1) (tl (s @ k))) } }}} 3. `f3` works, because the let-binding gets generalized. We end up with this Core elaboration: {{{ f3 = \ (x :: IntStream) -> case x of { IntStream s -> let { y :: forall k. (Int, IntStreamK k) y = \ (@ k) -> case s @ k of { Cons x xs -> (x, xs) } in IntStream (\ (@ k) -> Cons @ k ((case y of {(x, _) -> x}) + 1) (case y of {(_, xs) -> xs})) } }}} (GHC's actual desugaring for `y` is a bit more complex so I shortened it.) Note that this core is effectively the same as `f2`, except that (1) the type application has been commoned up, and (2) the `hd`/`tl` functions are inlined. If we turn on GADTs (without NoMonoLocalBinds) GHC stops generalizing this let binding and thus fails to typecheck. If you make this a strict let-binding this fails to typecheck (since we can't generalize strict let bindings; they're just like case.) 4. The important one: this does not work, because when we bind `x` and `xs`, we immediately apply the type application, but do not generalize so no suitable type is in scope. However, operationally, the core elaboration should be exactly the same as in (3). So it would be fine to generalize here: the static semantics are validated by elaborating irrefutable pattern matches into let bindings. So, it would be convenient for this application of irrefutable patterns were generalized; then I could write almost the obvious code and have GHC accept it. The same caveat with GADTs and let-bindings would apply: with GADTs enabled irrefutable patterns would not be generalized. Unfortunately, if we add another constructor to `Cons` there is NO total System FC program that works (e.g. http://stackoverflow.com/questions/7720108/total-function-of-type- forall-n-maybe-f-n-maybe-forall-n-f-n)... but that's a story for another day. #11700 seems a bit related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11700: pattern match bug
by GHC 14 Jun '16

14 Jun '16

#11700: pattern match bug -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: https://github.com/TobyGoodwin | /odd-ghc-pattern-bug | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With some types built by persistent-template, I'm running into very odd behaviour. Attempting to pull apart a tuple in one go... {{{#!hs let (Entity museKey muse, Entity msgKey msg, Entity fldrKey fldr) = cluster }}} fails (or rather, attempting to use msg or fldr fails) with errors like {{{ Couldn't match expected type ‘Folder’ with actual type ‘Folder’ }}} But splitting the pattern up: {{{#!hs let (a, b, c) = cluster Entity museKey muse = a Entity msgKey msg = b Entity fldrKey fldr = c }}} everything works normally Complete test case here: https://github.com/TobyGoodwin/odd-ghc-pattern- bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Jun '16

14 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"0497ee504cc9ac5d6babee9b98bf779b3fc50b98/ghc" 0497ee5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0497ee504cc9ac5d6babee9b98bf779b3fc50b98" Make the Ord Module independent of Unique order The `Ord Module` instance currently uses `Unique`s for comparison. We don't want to use the `Unique` order because it can introduce nondeterminism. This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering making `Ord Module` deterministic transitively. I've run `nofib` and it doesn't make a measurable difference. See also Note [ModuleEnv determinism and performance]. Test Plan: ./validate run nofib: P112 Reviewers: simonpj, simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2030 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 13 Jun '16

13 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"586d55815401c54f4687d053fb033e53865e0bf1/ghc" 586d558/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="586d55815401c54f4687d053fb033e53865e0bf1" Use UniqFM for SigOf Summary: The Ord instance for ModuleName is currently implemented in terms of Uniques causing potential determinism problems. I plan to change it to use the actual FastStrings and in preparation for that I'm switching to UniqFM where it's possible (you need *one* Unique per key, and you can't get the keys back), so that the performance doesn't suffer. Test Plan: ./validate Reviewers: simonmar, austin, ezyang, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2320 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11788: Enable Thin Library support for the Runtime linker on Windows.
by GHC 13 Jun '16

13 Jun '16

#11788: Enable Thin Library support for the Runtime linker on Windows. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The runtime linker currently has an `#ifdef` that removes support for AR's thin archives for Windows. This because all the code is based on `char*` and Windows would require `wchar_t`. Using the abstraction of `pathchar` this can be enabled for Windows and remove another `#ifdef` from the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12069: Possible type inference regression: "Expected a type, but 'a' has kind 'k0'"
by GHC 13 Jun '16

13 Jun '16

#12069: Possible type inference regression: "Expected a type, but 'a' has kind 'k0'" -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 program causes GHC HEAD to give an error: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Foo where foo (_ :: p a) = [] :: [a] }}} {{{ [1 of 1] Compiling Foo ( kind.hs, kind.o ) kind.hs:4:25: error: • Expected a type, but ‘a’ has kind ‘k0’ • In an expression type signature: [a] In the expression: [] :: [a] In an equation for ‘foo’: foo (_ :: p a) = [] :: [a] }}} GHC 7.10.1 compiles it fine, and infers the type `foo :: p a -> [a]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12033: [TypeApplications] GHC internal error
by GHC 13 Jun '16

13 Jun '16

#12033: [TypeApplications] GHC internal error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Toying around, got {{{ GHCi, version 8.1.20160503: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/CatFail.hs, interpreted ) /tmp/CatFail.hs:55:26: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1Ej :-> Type variable ‘i’ = i, a1Ek :-> Type variable ‘p’ = p, a1Et :-> Type variable ‘a’ = a, a1Eu :-> Type variable ‘b’ = b] • In the first argument of ‘Vacuous’, namely ‘a’ In the type ‘Vacuous a’ In the expression: Dict @(Vacuous a) /tmp/CatFail.hs:66:10: error: • Couldn't match type ‘Fun p q’ with ‘Vacuous’ arising from a use of ‘Main.$dmsrc’ • In the expression: Main.$dmsrc In an equation for ‘src’: src = Main.$dmsrc In the instance declaration for ‘Category (Nat p q)’ • Relevant bindings include src :: Nat p q a b -> Dict (Ob (Nat p q) a) (bound at /tmp/CatFail.hs:66:10) Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11670: Can't infer type
by GHC 13 Jun '16

13 Jun '16

#11670: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ _ mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} Fails with {{{ baldur@Loki:~$ ghci -ignore-dot-ghci /tmp/tLcV.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tLcV.hs, interpreted ) /tmp/tLcV.hs:11:10: error: • No instance for (Storable t) Possible fix: add (Storable t) to the context of an expression type signature: IO t • In a stmt of a 'do' block: s <- peekElemOff (castPtr ptr) 0 :: _ _ In the expression: do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } In an equation for ‘peek’: peek ptr = do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } Failed, modules loaded: none. }}} while {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ CLong mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} succeeds. Is this expected? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5