November 2014 - ghc-tickets

Re: [GHC] #4463: CORE notes break optimisation
by GHC 30 Nov '14

30 Nov '14

#4463: CORE notes break optimisation -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.1 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Support for `Core Notes` was added in 56b5a8b862d4eaeeaa941dd53e3d1009bdeadc0d, and seems to have gotten removed in 7bb0447df9a783c222c2a077e35e5013c7c68d91. I might be mistaken, but I think this ticket is no longer relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4463#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 30 Nov '14

30 Nov '14

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): This morning I was thinking about how this might work. Would unpacking be restricted only to single-constructor polymorphic types? For instance, if I had, {{{ data Poly a = MkP !Bool {-# UNPACK #-} !a | MkP2 data Mango = MkMango {-# UNPACK #-} !(Poly Int) }}} Would I want to produce a representation that is the product of all of the unpacked variants? e.g.. {{{ data MangoRep = MangoRep1 !Bool !a | MangoRep2 }}} Or would we want to simply not unpack multi-constructor types? This seems to be how monomorphic types are currently handled, if I understand the code correctly. Moreover, how would a pattern match against an unpacked polymorphic type be lowered? Would we want to re-box `Poly` when pattern matching on `Mango`? Alternatively, we could somehow specialize functions on `Poly` to take the unboxed representation. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4470: Loop optimization: identical counters
by GHC 30 Nov '14

30 Nov '14

#4470: Loop optimization: identical counters -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: loop optimization Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4470#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 30 Nov '14

30 Nov '14

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bitonic): * cc: f@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 30 Nov '14

30 Nov '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang <ezyang@…>): In [changeset:"4c834fdddf4d44d12039da4d6a2c63a660975b95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4c834fdddf4d44d12039da4d6a2c63a660975b95" Filter instance visibility based on set of visible orphans, fixes #2182. Summary: Amazingly, the fix for this very old bug is quite simple: when type- checking, maintain a set of "visible orphan modules" based on the orphans list of modules which we explicitly imported. When we import an instance and it is an orphan, we check if it is in the visible modules set, and if not, ignore it. A little bit of refactoring for when orphan-hood is calculated happens so that we always know if an instance is an orphan or not. For GHCi, we preinitialize the visible modules set based on the list of interactive imports which are active. Future work: Cache the visible orphan modules set for GHCi, rather than recomputing it every type-checking round. (But it's tricky what to do when you /remove/ a module: you need a data structure a little more complicated than just a set of modules.) Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> Test Plan: new tests and validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D488 GHC Trac Issues: #2182 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4896: Deriving Data does not work for attached code
by GHC 29 Nov '14

29 Nov '14

#4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mitar): I don't think that the question is what error message says, but that there should not be any errors and that GHC should know how to handle/compile this in the first place, no? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4896#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 29 Nov '14

29 Nov '14

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mitar): See [https://stackoverflow.com/questions/13794168/haskell-cant-find- package here an example] of exactly what I am talking about here and how it confuses users. So user here has issues using Haskell program and module is said to not exist: `Could not find module 'Data.Vector'`. But then you can see such error: {{{ package vector-0.10.0.1-3450daae3d9f2092020075d05481123c is unusable due to missing or recursive dependencies: base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd primitive-0.5.0.1-15cdc8c11a54a78809b647af0c2975b3 }}} So instead of saying that that module is not found which make one think you just have to install it, something else should be said. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4520: startup code on Windows should use SetDllDirectory("")
by GHC 28 Nov '14

28 Nov '14

#4520: startup code on Windows should use SetDllDirectory("") -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * difficulty: => Unknown * os: Unknown/Multiple => Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4520#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 28 Nov '14

28 Nov '14

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown Comment: mitar: please add an example to show the problem. What do you mean with "package is unusable?". Thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4823: Loop strength reduction for array indexing
by GHC 28 Nov '14

28 Nov '14

#4823: Loop strength reduction for array indexing -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #7116 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * related: => #7116 * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4823#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0