September 2013 - ghc-tickets

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

02 Sep '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: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Ryan: Thanks for testing. Most of the time each thread will be either blocked on an MVar or compiling (or figuring out what to block on next), so I'm not sure where the excessive system time is coming from but I assume it's either from the RTS or the IO manager. I haven't tested `cabal` with my branch but I don't think my changes are causing the errors you're experiencing. I'm willing to bet that it's due to recent changes pushed to master. (Or maybe you forgot to do `git submodule update` after checking out my branch?) ---- akio: #8209 is most likely what's being triggered, although I'm not positive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
by GHC 02 Sep '13

02 Sep '13

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Difficult (2-5 warning at compile-time | days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/595#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 02 Sep '13

02 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -------------------------------------+------------------------------------ Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------ Comment (by edsko): So here's what's happening: we have {{{ runQuasiQuoteExpr :: HsQuasiQuote RdrName -> RnM (LHsExpr RdrName) }}} which executes a quasi-quote. Note that `runQuasiQuoteExpr` returns a ''located'' expression; it makes an attempt to set the location of the expanded quasi-quote to something sensible. However, `runQuasiQuoteExpr` gets called by `rnExpr`, which ''ignores'' the outermost location returned by `runQuasiQuoteExpr`: {{{ rnExpr (HsQuasiQuoteE qq) = runQuasiQuoteExpr qq `thenM` \ (L _ expr') -> rnExpr expr' }}} The result is that the outermost location is whatever location of the quasi-quote was, while all inner locations have been set by `runQuasiQuoteExpr`. That's why in the test case the case of a single `True` or `False` is different from a compound expression; in all cases the `runQuasiQuoteExpr` sets the location of all identifiers to the same thing, but in the case of a non-compound expression (a single `True` or `False`) this is then overwritten by `rnExpr`; for the compound expression it's the location of the compound expression (`HsApp` or `HsPar`) which gets overwritten instead. Now, we can fix this by adding a special case to `rnLExpr` instead: {{{ rnLExpr :: LHsExpr RdrName -> RnM (LHsExpr Name, FreeVars) -- Don't ignore the new location set by runQuasiQuoteExpr (#7918) #ifndef GHCI rnLExpr (L _ e@(HsQuasiQuoteE _)) = pprPanic "Cant do quasiquotation without GHCi" (ppr e) #else rnLExpr (L loc (HsQuasiQuoteE qq)) = setSrcSpan loc $ runQuasiQuoteExpr qq `thenM` rnLExpr #endif /* GHCI */ rnLExpr e = wrapLocFstM rnExpr e }}} I have done this and it works and it fixes the problem for the case of expressions. I've done it too for the case of types but there seems to be another location override in that case; still looking for that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 02 Sep '13

02 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * owner: => leroux -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 02 Sep '13

02 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * owner: leroux => * status: patch => new -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 02 Sep '13

02 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * cc: leroux@… (added) Comment: Ignore the [http://ghc.haskell.org/trac/ghc/attachment/ticket/7684/0001-Fix-7684 .-Mask-words-with-bit-size-for-the-fast-popu.patch patch] where it just masks the word that is being passed to the appropriate fast popCount functions. I figured that it'd be getting rid of the point of the test since it "defines" how the functions should behave.I'm now digging into how/what instructions are emitted by the popCount PrimOps. Also, it'd be nice if someone to clear up why this [https://github.com/ghc/testsuite/commit/14619423995f69a76061b5f84025188ca2f… patch] was needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 01 Sep '13

01 Sep '13

#5550: GHC infinite loop when compiling vector -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: low | closed Component: Compiler | Milestone: 7.6.2 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple simplCore/should_compile/T5550 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: There's not going to be a 7.6.4, so this is now closed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5550#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8211: ghc -c recompiles TH every time while --make doesn't
by GHC 01 Sep '13

01 Sep '13

#8211: ghc -c recompiles TH every time while --make doesn't -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- https://github.com/nh2/ghc-bug-recompiles-th-on-c {{{ ghc -c Test.hs # compiles ghc -c Test.hs # compiles (and loads TH) again }}} I would expect ghc to print {{{ compilation IS NOT requried }}} since ghc --make does not recompile either, and the created .hi and .o files are identical. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
by GHC 01 Sep '13

01 Sep '13

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Difficult (2-5 warning at compile-time | days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by carter): * cc: carter.schonwald@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/595#comment:21> 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 01 Sep '13

01 Sep '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: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Replying to [comment:41 rrnewton]: > Have you tested `cabal -j` on this branch? They *should* compose fine, and I'd love to see what kind of speedup one can get installing the Haskell Platform packages. Right now this may result in more processes being created than desired. We're working on solving this issue (though the patches won't be ready for 1.18). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0