- ghc-tickets - Haskell.org

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

Re: [GHC] #2425: Crash constructing a ClockTime too far into the future
by GHC 28 Jan '13

28 Jan '13

#2425: Crash constructing a ClockTime too far into the future --------------------------+------------------------------------------------- Reporter: wagstaff | Type: bug Status: new | Priority: normal Milestone: _|_ | Component: libraries/old-time Version: 6.8.3 | Keywords: Os: Windows | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Comment(by morabbin): Dang; 64bit overflow. D'oh! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2425#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 28 Jan '13

28 Jan '13

#2439: Missed optimisation with dictionaries and loops ---------------------------------+------------------------------------------ Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): The `-fdicts-strict` flag exists but it has had no love for years, and I doubt it works right. One obstacle is that at the moment we implement a ''single-method'' type class with a newtype rather than a data type. We don't want to make that strict, lest we force the method rather than the dictionary. I rather think we sould remove the special case, so that all dictionaries are data types; then we could be uniformly strict. But we should do some bemchmarking to check that nothing slows down. Just awaiting someone with a bit of time and benchmarking bandwidth... Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2439#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0