- ghc-tickets - Haskell.org

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Sadly the situation with Cost Centre Stacks is that it's still work in progress and I didn't manage to document it (beyond comments in the code) before I left MSR. Simon is right that you can't statically determine which CCS a particular allocation will be attributed to. However, if the `let` is within the scope of a particular SCC, then the allocation should be attributed to Cost Centre Stacks that have that SCC label on the top. There might be many such stacks in the profile, if the current function was called from multiple different places. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7763: Resource limits for Haskell
by GHC 17 Jun '13

17 Jun '13

#7763: Resource limits for Haskell -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Profiling Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ commit 1f5eb79cc278fd64ee3f1f4249ea3b7404f62ba1 Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Thu Mar 7 13:53:31 2013 -0800 Primops and runtime support for space resource limits. This patch adds support for resource limits in Haskell, especially for monitoring and triggering events when portions of Haskell code exceed memory usage and/or allocation. The system is described in more detail at. http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits This patch adds the following types: CostCentre# - non-GCd pointer to CostCentre struct CostCentreStack# - non-GCd pointer to CostCentreStack struct Listener# - GC'd object for listening to pointer events and the following primops: ccToAddr addrToCC ccsToAddr addrToCCS newCC# setCCSOf# withCCS# pushCC# queryCCS# listenCCS# unlistenCCS# These previously existing primops have had their types changed, mainly for better type safety (replacing Addr# with CostCentreStack#) getCCSOf# getCurrentCCS# We add the following new RTS options: -hl equivalent to -hc but also keeps census information in- memory for access and does not write out a *.hp file -xf modified cost-centre stack semantics, where function entries never modify the stack (so only CAFs and explicit set CCCS affect cost-centres). To utilize these new features, compile with -prof and run with +RTS -hl -xf }}} See also http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 10

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: simonmar (added) * difficulty: => Unknown Comment: I'm not terribly up to speed with the state of cost-centre profiling. In general, the cost centre (or cost-centre stack) to which a `let` allocation is attributed is a ''dyanamic'' property; it depends on the caller of the current function. (Eg to which cost centre are the thunks allocated by `map` attributed? Answer: the caller.) So it's not clear that your question has a meaningful answer. Simon Marlow will know the current state of affairs, and embarrassingly I can't even point to a document that I am sure reflects the current state of affairs. Maybe Simon can. The whole area is in need of love and attention from someone who (a) has excellent operational intuitions, and (b) takes a strongly principled approach. Norman Ramsey comes to mind. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7990: ghc-pkg warning shows the wrong command
by GHC 17 Jun '13

17 Jun '13

#7990: ghc-pkg warning shows the wrong command -----------------------------+---------------------------------------------- Reporter: mcandre | Owner: Type: bug | Status: new Priority: normal | Component: Package system Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache. For out of date global caches, "ghc-pkg --global recache" successfully clears the warning. For out of date user caches, "ghc-pkg --user recache" clears the warning. In the future, could ghc-pkg display the command more specific to the problem? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 17 Jun '13

17 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): I'm running some benchmarks and analysing produced assembly and I just realized that removing case-on-bool in the codegen causes a performance regression. It seems to me that this special case is necessary, even after removing primops that return Bool. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:77> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 17 Jun '13

17 Jun '13

#6063: GHC's build-time ld-flag checks are problematic --------------------------------------+------------------------------------- Reporter: parcs | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #4862 --------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 17 Jun '13

17 Jun '13

#6063: GHC's build-time ld-flag checks are problematic --------------------------------------+------------------------------------- Reporter: parcs | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #4862 --------------------------------------+------------------------------------- Comment(by aseipp@…): commit 71a194d8ca2efd075a5c000be0b378c8706ca0b3 {{{ Author: Austin Seipp <aseipp(a)pobox.com> Date: Sat May 4 16:07:22 2013 -0500 Detect linker information at runtime. Fixes Trac #6063 Previously, we did ./configure time checks to see if 'GNU ld' supported certain options. If it does, we bake those options into the link step. See Trac #5240. Unfortunately, the linker we use at runtime can change for several reasons. One is that the user specifies -pgml 'foo'. The other is if /usr/bin/ld or whatnot changes from when GHC was built. Those options mentioned earlier are specific to GNU ld, but many systems support GNU gold too. This is Trac #6063. So we need to check at runtime what linker we're using. This is actually a little bit complicated because we normally use the C compiler as our linker. Windows and OS X are also special here. Finally, this patch also unconditionally gives '--hash-size=31' and '--reduce-memory-overheads' to the system linker if it's GNU ld. These options have been supported for 8+ years from what I can see, and there are probably a lot of other reasons why GHC would not work with such an ancient binutils, all things considered. See Note [Run-time linker info] in SysTools for details. There are plenty of comments as well in the surrounding code. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> aclocal.m4 | 33 ------------ compiler/main/DynFlags.hs | 26 +++++++++- compiler/main/SysTools.lhs | 117 ++++++++++++++++++++++++++++++++++++++++++- configure.ac | 2 - distrib/configure.ac.in | 2 - 5 files changed, 137 insertions(+), 43 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5240: help GNU ld to use less memory when linking libraries compiled with -split-objs.
by GHC 17 Jun '13

17 Jun '13

#5240: help GNU ld to use less memory when linking libraries compiled with -split- objs. -------------------------------+-------------------------------------------- Reporter: int-e | Owner: igloo Type: feature request | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by aseipp@…): commit 71a194d8ca2efd075a5c000be0b378c8706ca0b3 {{{ Author: Austin Seipp <aseipp(a)pobox.com> Date: Sat May 4 16:07:22 2013 -0500 Detect linker information at runtime. Fixes Trac #6063 Previously, we did ./configure time checks to see if 'GNU ld' supported certain options. If it does, we bake those options into the link step. See Trac #5240. Unfortunately, the linker we use at runtime can change for several reasons. One is that the user specifies -pgml 'foo'. The other is if /usr/bin/ld or whatnot changes from when GHC was built. Those options mentioned earlier are specific to GNU ld, but many systems support GNU gold too. This is Trac #6063. So we need to check at runtime what linker we're using. This is actually a little bit complicated because we normally use the C compiler as our linker. Windows and OS X are also special here. Finally, this patch also unconditionally gives '--hash-size=31' and '--reduce-memory-overheads' to the system linker if it's GNU ld. These options have been supported for 8+ years from what I can see, and there are probably a lot of other reasons why GHC would not work with such an ancient binutils, all things considered. See Note [Run-time linker info] in SysTools for details. There are plenty of comments as well in the surrounding code. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> aclocal.m4 | 33 ------------ compiler/main/DynFlags.hs | 26 +++++++++- compiler/main/SysTools.lhs | 117 ++++++++++++++++++++++++++++++++++++++++++- configure.ac | 2 - distrib/configure.ac.in | 2 - 5 files changed, 137 insertions(+), 43 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5240#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set
by GHC 16 Jun '13

16 Jun '13

#7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set -----------------------------+---------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When building GHC, if `GHC_PACKAGE_PATH` is set to a single path, then the build process will register packages in that path instead of in the build tree. Since `GHC_PACKAGE_PATH` points to the host compiler's package database, the build system overwrites the host compiler's package database, rendering the host compiler unusable. To reproduce: 1. Get a binary distribution of GHC 7.4.1 and a source distribution of GHC 7.4.2 2. Configure the binary distribution to install in a temporary directory: `./configure --prefix=$HOME/workspace1` 3. Install the binary distribution 4. Set up the environment to use only the installed compiler: `export PATH=$HOME/workspace1/bin:$PATH; export GHC_PACKAGE_PATH=$HOME/workspace1/lib/ghc-7.4.1/package.conf.d` 5. Configure the source distribution to install in a different directory: `./configure --prefix=$HOME/workspace2` 6. Build the source distribution: `make` Building will eventually run commands that modify the package database in `GHC_PACKAGE_PATH`. One of these commands is `"inplace/bin/ghc-pkg" update --force rts/package.conf.inplace`. I confirmed that the database is being modified by making `ghc-pkg` print the name of the file it's about to update. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

Re: [GHC] #5787: Add instances to ZipList
by GHC 16 Jun '13

16 Jun '13

#5787: Add instances to ZipList -------------------------------+-------------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.2.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5787#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0