August 2013 - ghc-tickets

[GHC] #8161: Associated type parameters that are more specific than the instance header
by GHC 23 Aug '13

23 Aug '13

#8161: Associated type parameters that are more specific than the instance header -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- It would be nice if type parameters of associated types could be more specific than those in the instance header. This is currently rejected with the message "Type indexes must match class instance head", but could be accepted: {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a instance C [a] where type T [Bool] = Int type T [Int] = Int }}} More typically, this is useful where we want to use an equality constraint to make type inference easier, but need to match on the actual type in an associated type: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} class C a where type T a instance a ~ [b] => C a where type T [b] = Int }}} This showed up in the implementation of [wiki:Records/OverloadedRecordFields/Plan OverloadedRecordFields]. Of course, one can always work around it using a normal (non-associated) type family. Note that we already allow type families to specialise variables that do not occur in the instance header: {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a b instance C [a] where type T [a] [Bool] = Bool type T [a] [Int] = Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 23 Aug '13

23 Aug '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 23 Aug '13

23 Aug '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * milestone: 7.6.2 => 7.8.1 Comment: Perhaps then we should simply upgrade the GCC release included in ghc- tarballs. I'm not sure if I will get to this before 7.8.1 (there's some cleanup on top of the fix for this that's needed,) although tenatively we can try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8036: Demand analyser is unpacking too deeply
by GHC 23 Aug '13

23 Aug '13

#8036: Demand analyser is unpacking too deeply -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7520 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: => simonpj * version: 7.6.3 => 7.7 * related: => #7520 * milestone: => 7.8.1 Comment: Simon, it sounds like this should be addressed for 7.8.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8036#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7520: Implement cardinality analysis
by GHC 23 Aug '13

23 Aug '13

#7520: Implement cardinality analysis -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This was merged back in May. {{{ commit 99d4e5b4a0bd32813ff8c74e91d2dcf6b3555176 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri May 3 14:50:58 2013 +0100 Implement cardinality analysis This major patch implements the cardinality analysis described in our paper "Higher order cardinality analysis". It is joint work with Ilya Sergey and Dimitrios Vytiniotis. The basic is augment the absence-analysis part of the demand analyser so that it can tell when something is used never at most once some other way The "at most once" information is used a) to enable transformations, and in particular to identify one-shot lambdas b) to allow updates on thunks to be omitted. There are two new flags, mainly there so you can do performance comparisons: -fkill-absence stops GHC doing absence analysis at all -fkill-one-shot stops GHC spotting one-shot lambdas and single-entry thunks The big changes are: * The Demand type is substantially refactored. In particular the UseDmd is factored as follows data UseDmd = UCall Count UseDmd | UProd [MaybeUsed] | UHead | Used data MaybeUsed = Abs | Use Count UseDmd data Count = One | Many Notice that UCall recurses straight to UseDmd, whereas UProd goes via MaybeUsed. The "Count" embodies the "at most once" or "many" idea. * The demand analyser itself was refactored a lot * The previously ad-hoc stuff in the occurrence analyser for foldr and build goes away entirely. Before if we had build (\cn -> ...x... ) then the "\cn" was hackily made one-shot (by spotting 'build' as special. That's essential to allow x to be inlined. Now the occurrence analyser propagates info gotten from 'build's stricness signature (so build isn't special); and that strictness sig is in turn derived entirely automatically. Much nicer! * The ticky stuff is improved to count single-entry thunks separately. One shortcoming is that there is no DEBUG way to spot if an allegedly-single-entry thunk is acually entered more than once. It would not be hard to generate a bit of code to check for this, and it would be reassuring. But it's fiddly and I have not done it. Despite all this fuss, the performance numbers are rather under- whelming. See the paper for more discussion. nucleic2 -0.8% -10.9% 0.10 0.10 +0.0% sphere -0.7% -1.5% 0.08 0.08 +0.0% -------------------------------------------------------------------------------- Min -4.7% -10.9% -9.3% -9.3% -50.0% Max -0.4% +0.5% +2.2% +2.3% +7.4% Geometric Mean -0.8% -0.2% -1.3% -1.3% -1.8% I don't quite know how much credence to place in the runtime changes, but movement seems generally in the right direction. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7520#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8113: Cannot override ghci builtin commands with :def[!]
by GHC 23 Aug '13

23 Aug '13

#8113: Cannot override ghci builtin commands with :def[!] -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Fyi, while looking into implementing a `:builtin <cmd> [args]`-like facility I noticed it's already there, by using `::<cmd>`: {{{ :def <cmd> <expr> define command :<cmd> (later defined command has precedence, ::<cmd> is always a builtin command) }}} So this leaves the issue of `:def!` not doing what it's expected to do (and probably to add documentation about the `::<cmd>` feature to the GHC user guide, as I didn't see it mentioned there). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8113#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 23 Aug '13

23 Aug '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Comment (by msieradzki): In my case I manually modified GHC directory layout so that "mingw" points to recent mingw installation. It contained GCC 4.7. It's important if one wants to use C++ libraries built with more recent GCC. As far as I know one can't mix code built with different GCC major versions so forcing use of GCC 4.5 isn't exactly the solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 23 Aug '13

23 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I'm impressed, it looks like you've done a great job. Well done. The parallel upsweep itself would look much nicer written using ParIO from monad-par, but that's something for the future. Take a careful look at `reTypecheckLoop`, I'm not sure it's correct (see my inline comment). The `FastString` changes need some more commentary, as pointed out by others. There are good comments in the parallel upsweep patch though. You've obviously been careful to minimize the impact on sequential compilation performance, which is great. The parallel IO manager bug needs to be fixed before we can merge the patch though. We can't ship it with a bug that causes random compilation failure. Aside from the issues above, I'm happy with the patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 23 Aug '13

23 Aug '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): Wait! The `ghc-tarballs` repo contains `gcc` for exactly this reason. The build system is supposed to use that, not any random `gcc` that comes with `mingw`. So why is it using the mingw one? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nh2): This is great! It is probably out of the scope for the Gsoc, but I'd like to mention: When you have modules in your project that take a very long time to compile with many modules depending on them, it is useful to re-use information about how long each module took to compile the last time. This way we can build dependencies leading towards these "blocker modules" as early as possible. See our small discussion at: https://github.com/ndmitchell/ghc- make/issues/2#issuecomment-19467708 parcs, you probably have a good overview on how GHC builds things now. Do you think the current state would make it possible to save and re-use such timing information? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0