January 2013 - ghc-tickets

Re: [GHC] #7524: Erroneous repeated kind variable in conflicting type family instance error message
by GHC 28 Jan '13

28 Jan '13

#7524: Erroneous repeated kind variable in conflicting type family instance error message ------------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: polykinds/T7524 | Blockedby: Blocking: | Related: #7587 ------------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => polykinds/T7524 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7524#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7524: Erroneous repeated kind variable in conflicting type family instance error message
by GHC 28 Jan '13

28 Jan '13

#7524: Erroneous repeated kind variable in conflicting type family instance error message ----------------------------------------------+----------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: #7587 ----------------------------------------------+----------------------------- Comment(by simonpj@…): commit a98e51ecf51d1a93d48a8a10d35827edfd9d8c28 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Jan 28 08:18:28 2013 +0000 More refactoring of FamInst/FamInstEnv; finally fixes Trac #7524 Quite a bit of tidying up here; the fix to #7524 is actually only a small part. * Be fully clear that the cab_tvs in a CoAxBranch are not fresh. See Note [CoAxBranch type variables] in CoAxiom. * Use CoAxBranch to replace the ATDfeault type in Class. CoAxBranch is perfect here. This change allowed me to delete quite a bit of boilerplate code, including the corresponding IfaceSynType. * Tidy up the construction of CoAxBranches, and when FamIntBranch is freshened. The latter onw happens only in FamInst.newFamInst. * Tidy the tyvars of a CoAxBranch when we build them, done in FamInst.mkCoAxBranch. See Note [Tidy axioms when we build them] in that module. This is what fixes #7524. Much niceer now. compiler/iface/BinIface.hs | 7 - compiler/iface/IfaceSyn.lhs | 31 ++--- compiler/iface/MkIface.lhs | 21 +-- compiler/iface/TcIface.lhs | 29 ++--- compiler/typecheck/FamInst.lhs | 142 ++++++++++++++------- compiler/typecheck/TcGenGenerics.lhs | 9 +- compiler/typecheck/TcInstDcls.lhs | 50 +++----- compiler/typecheck/TcRnDriver.lhs | 4 +- compiler/typecheck/TcTyClsDecls.lhs | 21 ++-- compiler/types/Class.lhs | 20 +--- compiler/types/CoAxiom.lhs | 31 ++++- compiler/types/Coercion.lhs | 1 - compiler/types/FamInstEnv.lhs | 106 +--------------- compiler/vectorise/Vectorise/Generic/PAMethods.hs | 4 +- compiler/vectorise/Vectorise/Generic/PData.hs | 10 +- 15 files changed, 204 insertions(+), 282 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7524#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 28 Jan '13

28 Jan '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by PHO): Sure. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 28 Jan '13

28 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by tibbe): One possible use of unboxed booleans is branchless search. There are some algorithms where you can replace branches (e.g. case statements) with bit twiddling operators. I believe Gregory Collins used one such trick in the hashtables package. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 28 Jan '13

28 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): I linked the wrong page in my comment. [http://hackage.haskell.org/trac/ghc/wiki/PrimBool Here's the correct one]. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 28 Jan '13

28 Jan '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by simonmar): Ok yes, thanks for pointing that out. Would you mind rebasing your patches and I'll get them committed? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 28 Jan '13

28 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): I read paper about pointer tagging and things seem to be clearer now. I rewrote wiki page about [http://hackage.haskell.org/trac/ghc/ticket/6135 PrimBool] from scratch. I think that now it defines the goal very clearly by giving code examples. There are also workarounds for the problem. If you guys could take a look and tell me if this makes sense it would be great. I failed to figure out a code example that would actually go faster using my workarounds. The ones I created have about 0,4% increase in performance, which is a negligible difference. I will be working on this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 28 Jan '13

28 Jan '13

#1853: hpc mix files for Main modules overwrite each other -------------------------------+-------------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Code Coverage | Version: 6.8.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by andygill): This one is tricky to fix, because of a baked in assumption. If anyone wants to help, or if I can find a willing student, I can give guidance about how to fix it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1853#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1904: Strictness analyser should be smarter
by GHC 28 Jan '13

28 Jan '13

#1904: Strictness analyser should be smarter -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: The code now looks good. Here is Case A, with `-ddump-simpl -O` output: {{{ foo :: String -> [String] -> Bool foo x _ | x `seq` x == "." = True foo x xs = x `seq` any (x ==) xs ===== T1904.foo = \ (x_aeG :: GHC.Base.String) (ds_dl8 :: [GHC.Base.String]) -> case x_aeG of x1_XeK { __DEFAULT -> case GHC.Base.eqString x1_XeK T1904.foo1 of _ { GHC.Types.False -> GHC.List.any @ GHC.Base.String (GHC.Base.eqString x1_XeK) ds_dl8; GHC.Types.True -> GHC.Types.True } } }}} Now without the first `seq`, Case B: {{{ foo :: String -> [String] -> Bool foo x _ | x == "." = True foo x xs = x `seq` any (x ==) xs ==== T1904.foo = \ (x_aeG :: GHC.Base.String) (ds_dl7 :: [GHC.Base.String]) -> case GHC.Base.eqString x_aeG T1904.foo1 of _ { GHC.Types.False -> case x_aeG of x1_akh { __DEFAULT -> GHC.List.any @ GHC.Base.String (GHC.Base.eqString x1_akh) ds_dl7 }; GHC.Types.True -> GHC.Types.True } }}} Notice that both have one remaining `seq` on `x`, but in one case it's before the call to `eqString`, and in the other case after it, which is as it should be. So I'm happy here, and am closing. Re-open if you disagree. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1904#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2216: Better error message for unboxed types with no -fglasgow-exts flag
by GHC 28 Jan '13

28 Jan '13

#2216: Better error message for unboxed types with no -fglasgow-exts flag ---------------------------------+------------------------------------------ Reporter: tim | Type: feature request Status: closed | Priority: normal Milestone: _|_ | Component: Compiler (Parser) Version: 6.8.2 | Resolution: wontfix Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Agreed, let's close. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2216#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0