April 2013 - ghc-tickets

[GHC] #7678: GHC should compile cleanly with clang
by GHC 20 Jun '13

20 Jun '13

#7678: GHC should compile cleanly with clang --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: clang Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: 7602 | Related: --------------------------------+------------------------------------------- I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like: {{{ {-# RULES "thing" ... #-} }}} becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot. This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly. As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something. This currently blocks #7602 since I can't test my fix otherwise. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 8

[GHC] #7661: GHC build system does not detect opt-3.0 and friends
by GHC 19 Jun '13

19 Jun '13

#7661: GHC build system does not detect opt-3.0 and friends --------------------------------+------------------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- It is common to install LLVM tools with a version suffix (such as opt-3.0, llc-3.0, etc) so that multiple versions may co-exist. For example, the Debian package llvm-3.0 does this. It would be nice if the build system could detect such tools without needing `--with-opt`, etc, specifically. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7694: LLVM: bootstrapping with LLVM 3.2 does not work
by GHC 17 Jun '13

17 Jun '13

#7694: LLVM: bootstrapping with LLVM 3.2 does not work --------------------------------+------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 14

[GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 17 Jun '13

17 Jun '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Component: Template Haskell Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to be able to have something like this in the Q monad: type MessageName = String -- or something better, I don't know writeIface :: (Quasi q, Serializable a) => MessageName -> a -> q () readIfaces :: (Quasi q, Serializable a) => MessageName -> q [a] Or instead of returning [a], I'm of course fine with a Monoid, I just need the gathered results for every occurrance of the MessageName. This has to be in the interface file, because I'd like this to work through compilation units, like class instances, I'd like to get every result in the readIfaces call that is ever imported from the current module (transitive closure). Please note, that in a very hacky way this is already possible to do by abusing classes. Namely, I create an empty class for my message type. When I want to send a message, I create a new empty datatype named for the message and I make this an instance of the class. Then on the receiving side I just have to reify the class and I will receive all my instance names/messages. This came up while implementing the HFlags library: http://hackage.haskell.org/package/hflags Maybe I shouldn't be proud of this, but we currently do the hacky way explained above. I would love to have a clean approach. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[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

[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

[GHC] #7811: intermittent 'unexpected' results of test ghcpkg01
by GHC 16 Jun '13

16 Jun '13

#7811: intermittent 'unexpected' results of test ghcpkg01 -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Component: ghc-pkg Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I get this unexpected error from ghcpkg01 {{{ Actual stderr output differs from expected: ... +WARNING: cache is out of date: localXXX/package.cache + use 'ghc-pkg recache' to fix. }}} when running the full suite, but cannot reproduce it when running just that test; it passes when run individually. (This was also reported in #5503.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7836: Runtime failure profiling with +RTS -hc -hbdrag,void
by GHC 16 Jun '13

16 Jun '13

#7836: Runtime failure profiling with +RTS -hc -hbdrag,void -------------------------+-------------------------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 7.4.2 | Keywords: profiling osx Os: MacOS X | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Running the attached program, compiled with "-threaded -Wall -auto-all -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls" - with the following flags: +RTS -hc -hbdrag,void -RTS The output is as follows: leaks: internal error: Invalid object in processHeapClosureForDead(): 60 (GHC version 7.4.2 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7744: Can't install conduit via cabal-install
by GHC 16 Jun '13

16 Jun '13

#7744: Can't install conduit via cabal-install -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output: {{{ Downloading conduit-1.0.2... Configuring conduit-1.0.2... Building conduit-1.0.2... Preprocessing library conduit-1.0.2... [1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o ) [2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o ) [3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o ) [4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o ) [5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o ) ghc: internal error: evacuate: strange closure type 8 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install conduit-1.0.2 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7847: Maintain per-generation lists of weak pointers
by GHC 15 Jun '13

15 Jun '13

#7847: Maintain per-generation lists of weak pointers -----------------------------------------+---------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- Currently the runtime system keeps a list of all live weak pointers, and traverses it once every (major or minor) GC. This is very slow if the program keeps many weak pointers alive. Some comments in the rts source suggest that it should be using one weak pointer list per generation, so these patches implement that. The attached test program tries to imitate the memory behavior of code that uses a particular FRP library. The patches make the program 3x faster on my machine. One problem I can see with the patches is that it creates a race condition between finalizeForeignPtr and addForeignPtrFinalizer. I'm not even sure what the correct behavior is when addForeignPtrFinalizer is called after finalizerForeinPtr. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 13