January 2014 - ghc-tickets

Re: [GHC] #7619: Make worker-wrapper unbox data families
by GHC 16 Jan '14

16 Jan '14

#7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: simonpj => nomeata -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7619#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 16 Jan '14

16 Jan '14

#7679: Regression in -fregs-graph performance --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7192, | #8657 --------------------------------------------+------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:"f0a7261a39bd1a8c5217fecba56c593c353f198c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0a7261a39bd1a8c5217fecba56c593c353f198c" Disable -fregs-graph (#7679, #8657) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 15 Jan '14

15 Jan '14

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): alternatively, if the free version of visual studio, visual studio express, http://www.visualstudio.com/en-us/products/visual-studio-express- vs.aspx comes with the Visual Studio linker, doesn't that have some support for dealing with cyclic deps in linking? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 15 Jan '14

15 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): That did help a lot, thanks ! So, I (think) have implemented `IrredPred`. I have also fixed `DsMeta.lhs`, deleted `classP`, `equalP` and added `equalityT` Sadly, I have a failing test `testsuite/tests/perf/compiler/T4801.hs` and I don't know how to work this out Patches can be found [https://gist.github.com/YoEight/8370987 here] Regards, Yorick -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 15 Jan '14

15 Jan '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by thoughtpolice): I investigated Mavericks and talked with Simon about this. 10.9 is problematic. It still emits indirect jumps via a call through `%rdi` when using `__thread`, so it can't perform a simple direct load/store to a 'fast' location. You can also use `pthread_{get,set}specific`, but these are indirect dynamic calls too (and probably performs even worse.) Furthermore I can't find the source code for `pthread_getspecific` & co, so it's impossible to check if my 10.8 fix still works OK. We decided to: * Make the runtime use `__thread` on OS X for now. This cleans up the code, and in the future could be optimized by the compiler/runtime handling of TLS variables in future versions. * Document the fact OS X will suffer a performance regression with the `-threaded` garbage collector. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 15 Jan '14

15 Jan '14

#7428: GHC compile times are seriously non-linear in program size ---------------------------------------+---------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by carter): I just tested this issue with a copy of HEAD I built today, ghc -O2 still blows up on the cleaned up file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 15 Jan '14

15 Jan '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by carter): Whats the current status? do I or someone else with a mac need to run a benchmark of ghc head built with clang vs ghc head built with gcc? Mind you, i only have a 2 core machine, so idk if thats enough to exercise the issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 15 Jan '14

15 Jan '14

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): is there some way we could do a hack to do split DLLs and allow cycles? (would probably mean some sort of indirect jump penalty in one direction of the cycle). One extreme would be to use some sort of graph clustering software tool like METIS http://glaros.dtc.umn.edu/gkhome/metis/metis/overview do .hi files have enough information to sort out the directed graph of imports exports? I'd be happy to help do some graph clustering experimentation on the object files (that piece isn't windows specific, so i could hack it out on my current machine) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8669: Closed TypeFamilies regression
by GHC 14 Jan '14

14 Jan '14

#8669: Closed TypeFamilies regression --------------------------+------------------------------------------------ Reporter: merijn | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.7 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I first played around with closed typefamilies early 2013 and wrote up the following simple example {{{ {-# LANGUAGE ConstraintKinds, DataKinds, PolyKinds, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) type family Restrict (a :: k) (as :: [k]) :: Constraint type instance where Restrict a (a ': as) = (a ~ "Oops! Tried to apply a restricted type!") Restrict x (a ': as) = Restrict x as Restrict x '[] = () foo :: Restrict a '[(), Int] => a -> a foo = id }}} This worked fine, functioning like `id` for types other than `()` and `Int` and returning a type error for `()` and `Int`. After hearing comments that my example broke when the closed type families syntax changed I decided to update my version of 7.7 and change the code for that. The new code is: {{{ {-# LANGUAGE ConstraintKinds, DataKinds, PolyKinds, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) type family Restrict (a :: k) (as :: [k]) :: Constraint where Restrict a (a ': as) = (a ~ "Oops! Tried to apply a restricted type!") Restrict x (a ': as) = Restrict x as Restrict x '[] = () foo :: Restrict a '[(), Int] => a -> a foo = id }}} This code is accepted by the compiler just fine, but the `Constraint` gets thrown out. When querying ghci for the type of `foo` the following is returned: {{{ λ :t foo foo :: a -> a λ :i foo foo :: (Restrict a '[(), Int]) => a -> a }}} Additionally, in the recent 7.7 `foo ()` returns `()` rather than a type error. After some playing around this seems to be caused by the "(a ~ "Oops! Tried to apply a restricted type!")" equality constraint. It seems GHC decides that it doesn't like the fact that types with a polymorphic kind and `Symbol` kind are compared. Leading it to silently discard the `Constraint`. This raises two issues: 1) This should probably produce an error, rather than silently discarding the `Constraint` 2) A better way to produce errors in type families is needed, personally I would love an "error" `Constraint` that takes a `String`/`Symbol` and never holds, producing it's argument `String` as type error (This would remove the need for the hacky unification with `Symbol` to get a somewhat relevant type error). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 14 Jan '14

14 Jan '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Bummer. While finding out what happened to `wave4main`, I noticed that I introduced a bug (well, imprecision) where `Converges` information was lost. This prevented nested CPR in `wave4main`, and everything looked good. Fixing that bug gives us back the +11.3% for `wave4main`, and also a +0.2% for `scs`. So it remains all very heuristical... The change in `scs` is hard to pin-point, as there is quite a bit of CPR’ing going on which moves allocations between different ticky-ticky- counters. But in the summary, we see an increase in `ALLOC_FUN_gds` again, and there are `$wgo` popping up where there were none, so this indicates lost join points. (Also interesting: `ALLOC_CON_ctr` goes up, but `ALLOC_CON_gds` goes down.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0