- ghc-tickets - Haskell.org

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 30 Aug '13

30 Aug '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | 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 thoughtpolice): Yes, the patch unfortunately can't go in for now when it will totally break bootstrapping. We'll have to see if we can get a fix into Happy. FWIW, I created the 7.10 ticket because I like keeping tickets for things that we eventually remove. It normally happens when people glance over the code, but I find having a ticket is an easier trail to follow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

30 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: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8110: Off-by-one error in FastString.getFastStringTable
by GHC 30 Aug '13

30 Aug '13

#8110: Off-by-one error in FastString.getFastStringTable ---------------------------------------+----------------------------------- Reporter: parcs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by parcs): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8110#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8110: Off-by-one error in FastString.getFastStringTable
by GHC 30 Aug '13

30 Aug '13

#8110: Off-by-one error in FastString.getFastStringTable ---------------------------------------+----------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Patrick Palka <patrick@…>): In [changeset:85c1715d086bf2d35bc05133398f462919f2aa7b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85c1715d086bf2d35bc05133398f462919f2aa7b" Fix off-by-one error in FastString.getFastStringTable (#8110) The function was reading past the end of the FastString table, causing the -dfaststring-stats option to behave unpredictably. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8110#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8200: Export languageExtensions from DynFlags
by GHC 30 Aug '13

30 Aug '13

#8200: Export languageExtensions from DynFlags ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As stated in the summary. I don't see any harm in it and I would personally find it useful for some extension manipulation as part of Haddock. This patch also clobbers trailing whitespace in the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7958: 'Cannot continue after interface file error' during compilation
by GHC 30 Aug '13

30 Aug '13

#7958: 'Cannot continue after interface file error' during compilation ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: I'm closing the report then, since neither of us can reproduce the problem anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7958#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3915: GHC panic; possibly related to mutually recursive modules
by GHC 30 Aug '13

30 Aug '13

#3915: GHC panic; possibly related to mutually recursive modules -------------------------------------+------------------------------------- Reporter: bob | Owner: jstolarek Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: GHC panic Operating System: Linux | mutually recursive modules Type of failure: Compile-time | Architecture: x86 crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3915#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8201: Haddockifying the documentation in HsSyn
by GHC 30 Aug '13

30 Aug '13

#8201: Haddockifying the documentation in HsSyn ------------------------------------+------------------------------------- Reporter: DaniilFrumin | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I took the liberty of making some cosmetic changes to the comments in HsBinds.lhs and HsExpr.lhs. Particularly I've made most of the relevants comments appear as Haddock annotations for datatypes and constructors. This way a user of GHC API (or a GHC dev) can refer to the haddocks in order to find out what does the given datatype/constructor represent/do instead of digging too deep in the source code. You can see the output here: <http://co-dan.github.io/ghc- docs/HsExpr.html>, <http://co-dan.github.io/ghc-docs/HsBinds.html> This patch on github: https://github.com/co-dan/ghc/compare/hssyn-docs Related wiki pages: Commentary/Compiler/HsSynType If this proves useful I may update documentation in other files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

30 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 carter): Let me preface that I'm very likely not following this thread. So please view my following remarks as also being questions for clarification. I'm trying to follow this thread: 1. the issue initially was that theres overally agressive let floating? I believe the way Manuel addresses this in his Repa Code is by using the touch function to prevent let floating, right? 2. currently: its now a question about having a more systematic way of soundly handling the cost model of let floatings and when to do them? @Hans / Wurmli As a haskell programmer, you can absolutely write great performant low level code in haskell (or cheaply ffi out if need be). It does require really understanding how GHC works, and how it compiles code. Really performant haskell does not treat the compiler as a black box, but rather as a partner to in a conversation. I have some fun examples of bit fiddling haskell code that turns into exactly the straight line register manipulations I"d hope any language to generate. But to really write HPC grade code, you have to really understand your tools! The "standard" way to systematically write very very performant code in haskell, is to first design a library with the "right" abstractions, and in tandem, have a "dialogue" where you figure out how to give the library internals a representation that GHC can aggressively fuse / simplfify away to make things fast. The Vector Library does this with stream fusion, and the GPU lib Accelerate and the CPU libs Repa 3 / Repa 4 libs all have very nice views on some parts of this methodology (I have my own, different take in progress that adds some interest twists too). In some respects, its also an ongoing exploratory engineering effort and research effort to make it better and better. point being: there is no magical compiler, merely compilers that can "collaborate" with the library author. GHC does an great (and getting even better over time) job of this. If you have specific optimizations you'd want, please illustrate what the "input" and "result" codes from the optimization would be! Humans, given enough time, often are the best optimizers, so the best a compiler can do is support library authors writing easy to optimize libraries! Importantly: currently GHC doesn't pass much aliasing information to code generators, though for numerical / bit fiddling codes, LLVM can do some tremendously amazing optimziations. There will also be great support for some basic simd code writing in 7.8. That said, after 7.8 release, and before 7.10 lands, I think its pretty fair to say that a lot of great work will be happening to better support GHC having a good numerical story. If nothing else, its something that I (time permitting), want to improve/help with. That said: in the mean time, its ok to have "fat primops" written in C that you ffi out to, and having all your application / numerical logic, and memory management be on the haskell side. I'm actually doing that quite a bit in my own codes, and while theres plenty of room for even better performance, even with that naive approach I'm able to get temptingly close to Ye Olde ancient but really really fast Fortran Grade performance with fairly little effort on my part. I hope i'm contributing to this thread with these questions and remarks :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

30 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 wurmli): Replying to [comment:14 simonpj]: > wurmli, no I don't think it's reasonable. (Unless I'm missing something.) I have not looked very carefully, but I think this program does a lot of read/write of an imperatively-mutable `(STRef (Int,Int))`. If we could eliminate those read/write pairs altogether, that would indeed be a good thing, but that is pretty hard to do, because in principle any computation of type `(ST s a)` might mutate that reference. GHC simply doesn't have any serious optimisations for imperative code; it focuses on optimising functional code. > > To put it another way, what program would you expect GHC to transform your code into? > > Simon > I am sorry for not choosing my words carefully enough. As a Haskell programmer I have only limited ways to influence how the compiled program utilises the resources on a given computer architecture. Most of the time this is a great blessing as it lets me concentrate on the logic of my task. But for some tasks, e.g. numerics or simulation, raw speed often results from optimal use of the resources. So I should probably not say it is a reasonable expectation but a hope that the code generator and optimiser can do that job for me. In the same way that I might manage to write a recursive function as a tail recursive one, I would have hoped that by giving a hint with an imperative style Haskell program that the code generator / optimiser could generate what you would get from, say, an analoguous C-program. If not you and your top colleagues working on ghc, who should be able to find a solution, if one even exists? Let me look stupid: in one of the optimisation phases an analyses of dead and live variables takes place (which looks like the action of a garbage collector to me). My naive expectation would be that an optimisation is possible if and only if an analyses of dead and live variables is doable (based on the syntactic structure at that stage). Hans Peter -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0