August 2013 - ghc-tickets

[GHC] #8183: Parse error with let inside of do with { }
by GHC 27 Aug '13

27 Aug '13

#8183: Parse error with let inside of do with { } ----------------------------+---------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- This line causes the error: {{{ err = do { let x = 1 ; Just x } }}} Breaking the line before the `;` fixes the error. This was tested on today's (27 Aug) HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 27 Aug '13

27 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 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 Herbert Valerio Riedel <hvr@…>): In [changeset:728bd07065425519e74bae2fc464e6c0d23f6952/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="728bd07065425519e74bae2fc464e6c0d23f6952" Update `-ddump-minimal-imports` entry in user's guide The entry is updated to mention explicitly the feature implemented for #7957, as well as rewording and improving the docbook markup. Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 27 Aug '13

27 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 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 Herbert Valerio Riedel <hvr@…>): In [changeset:a499ff73cdb27117f68f49c57c602febd09f9582/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a499ff73cdb27117f68f49c57c602febd09f9582" Make `-ddump-minimal-imports` honour `-dumpdir` flag The `-dumpdir` flag was added via 668c860b361f16 but failed to take care of `-ddump-minimal-imports`'s output. This commit makes up for that omission. This addresses #7957 Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:6> 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 27 Aug '13

27 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: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 27 Aug '13

27 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by rwbarton): Actually, `flopS` uses its "continuation" `f` linearly, like the CPS translation of an ordinary imperative function. Teaching GHC to recognize this sounds like quite an undertaking, though. This seems like a typical instance of how it is hard to decide whether to float out a let. The trouble with let-floating from the user's perspective is that when GHC wrongly decides to float out a let, it is virtually impossible to stop it from doing so. One way out is `-fno-full-laziness`, but GHC probably was correctly floating out a lot of other things, and it's difficult and tedious to locate and transform all those parts of the code. One suggestion is to identify situations in which let-floating can never be harmful, and allow `-fno-full-laziness` (or perhaps a new flag, `-fsome-full-laziness`?) to perform those floatings. For example, I don't think it can ever cost to float a binding whose RHS is a lambda to the top level. That rule would float out `flopp` and `swap` from `flop` here, and compiling with `-fno-full-laziness` would then eliminate all allocations. It would also be very useful to be able to control let-floating locally with some kind of pragma or magic built-in function. I'm sure this idea has been explored before and I also have some ideas of how to go about it, but I want to get a little more familiar with the structure of GHC before proposing anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 27 Aug '13

27 Aug '13

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Runtime System | Version: 6.10.4 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 scpmw): Hi Tarrasch (1) Thanks - the good thing with using DWARF is that it doesn't really matter how you use it. My primary use case was actually to feed it to ThreadScope for profiling. Other people have talked about using Linux "perf" tools - this kind of openness is a good thing. From my point of view, going over the RTS will probably be the most fruitful approach most of the time, simply because it can account for more of the generated code's quirkiness (see the "IP-1" trouble with GDB). (2) The LLVM backend was actually what we started with, and at this point we still support line-number information. Walking the stack is more problematic - we can declare values as being visible in DWARF using `llvm.dbg.declare` and friends, but (as far as I know) have no way to communicate unwind rules to LLVM. Dwarf 4 isn't really the issue here though, Dwarf 3 is sufficient - even DW_CFA_def_cfa_expression will probably only be needed for rare variable- sized stack frames. (3) Tthere should actually be little magic involved with building my branch, as everything's on by default. Just make sure you have the dependencies (libdwarf). Also get the stack-trace branch of the "base" library from my GitHub, as otherwise you won't have a top-level exception handler that prints a stack trace. In case you run into any problems, just drop me a mail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7889: Build Error (master branch)
by GHC 27 Aug '13

27 Aug '13

#7889: Build Error (master branch) -------------------------------------+---------------------------------- Reporter: cg31 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: gmp Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Rothiph): I also run into this error when building on Windows 7 64-bit within a MinGW/MSYS environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7889#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7889: Build Error (master branch)
by GHC 27 Aug '13

27 Aug '13

#7889: Build Error (master branch) -------------------------------------+---------------------------------- Reporter: cg31 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: gmp Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by Rothiph): * architecture: x86 => x86_64 (amd64) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7889#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7889: Build Error (master branch)
by GHC 27 Aug '13

27 Aug '13

#7889: Build Error (master branch) -------------------------------------+--------------------------- Reporter: cg31 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: gmp Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by Rothiph): * cc: mikesteele81@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7889#comment:3> 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 27 Aug '13

27 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 rrnewton): By the way, I've had various hard-to-pin-down problems with changing capabilities at runtime myself. Is it possible in this case to just disable the use of that feature for the initial release? That is, you would have to use +RTS -N to get real speedup. But, hey, it's kind of an advanced compilation feature anyway. In this scenario we could get a lot of testing experience with parallel builds without setNumCapabilities and then combine them when there is higher confidence. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0