- ghc-tickets - Haskell.org

[GHC] #7753: Profiling report broken with foreign exported functions
by GHC 13 Apr '13

13 Apr '13

#7753: Profiling report broken with foreign exported functions -------------------------+-------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 7.6.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Save the following Haskell source as wrapper.hs: {{{ import Foreign.Ptr import Control.Monad main = do fptr <- wrap wrapped replicateM 100 $ (return$!) =<< dyn fptr 4 wrapped :: Double -> IO Double wrapped x = return $ f 10000 x f :: Int -> Double -> Double f 0 u = u f n u = (u / fromIntegral n) * f (n-1) u foreign import ccall "wrapper" wrap :: (Double -> IO Double) -> IO (FunPtr (Double -> IO Double)) foreign import ccall "dynamic" dyn :: FunPtr (Double -> IO Double) -> Double -> IO Double }}} Then compile and run it with: {{{ $ ghc -O2 wrapper.hs -fprof-auto -prof $ ./wrapper +RTS -p }}} It generates wrapper.prof (attached). The file contains the following lines: {{{ CAF GHC.IO.Encoding.Iconv 58 0 0.0 0.2 0.0 0.2 wrapped Main 80 100 0.0 1.1 0.0 0.0 f Main 81 1000100 100.0 0.0 0.0 0.0 }}} I see two problems here, (1) the inherited column is 0 for 'wrapped' and 'f' but this is incorrect, and (2) 'wrapped' and 'f' belongs to the wrong cost center, 'GHC.IO.Encoding.Iconv'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7752: GHC as a library documentation out of sync
by GHC 13 Apr '13

13 Apr '13

#7752: GHC as a library documentation out of sync -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The example program(s) at http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc- as-a-library.html no longer compile. The docs probably just need a bit of tweaking. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7751: Incremental heap census
by GHC 13 Apr '13

13 Apr '13

#7751: Incremental heap census -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- At the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out heap census on portions of the heap which were *immediately* GC'd; i.e. an incremental census. The question, then, is how do we reconstruct full heap state from only a partial census? In particular, how do we know if an object that was previously present got collected or got promoted? If we always assume that it got collected (the naive implementation), a promoted object will disappear from the census, and only mysteriously reappear when we do a full census. The trick we want to employ is to save the starting pointer of all of the generations: while the entire generation is not slop free, the remainder of the first block and all of the later blocks are. I believe this is sufficient to reconstruct full heap state. #4225 has related discussion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7746: Support loading/unloading profiled objects from a profiled executable
by GHC 13 Apr '13

13 Apr '13

#7746: Support loading/unloading profiled objects from a profiled executable -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This is closely related to #3360, but it is a bit less ambitious and should be possible to implement without too many extra changes to the byte code compiler and interpreter (e.g. we just have to teach the linker how to handle things). Here is a simple test program off of 'plugins' to get working: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Plugins.Make import System.Plugins.Load import Data.List boot :: FilePath -> IO () boot path = do r <- make path ["-prof"] case r of MakeSuccess _ p -> do r' <- load p [] [] "result" case r' of LoadSuccess _ (v :: Int) -> print v LoadFailure msg -> print msg MakeFailure es -> putStrLn ("Failed: " ++ intercalate " " es) main = do boot "Foo.hs" }}} where Foo.hs is {{{ module Foo where result = 2 :: Int }}} Here are the things that, as far as I can tell, need to be handled: * We should ensure consistency between the host and the object file being uploaded. For example, if you load an un-profiled object file into a profiled binary, GHC will eat all your puppies. A simple way to do this is look for a symbol (e.g. CC_LIST) which is only ever exported when something is profiled and barf it is encountered. * This current code fails with {{{test: Foo.o: unknown symbol `CC_LIST'}}}, much the same way GHCi used to fail. This particular problem is (I think) that we don’t store CC_LIST and other externsymbols in our global hash table, so the linker thinks that they don’t exist, when they do. CC_LIST and friends should be special-cased or added to the table. * We don’t run ctors which setup CC_LIST with all of the cost-centres from the loaded module; we need to teach the linker to do that (that's the {{{/* ignore constructor section for now */}}}) * We need to come up with some sensible way of unloading cost-centres from CC_LIST and friends; we could make CC_LIST doubly-linked and then just excise the cost-centre in a destructor, but freeing the actual allocated CostCentre is more difficult. For now, we might just live with the memory leak, but see wiki:"Commentary/ResourceLimits#Memoryleaks" for a possible better implementation strategy. But that’s it; everything else should work normally. Something similar should apply to ticky builds. Something we will have to think about is how to handle these special-cases as we move from static objects to dynamic objects and push more of the runtime linking burden to the standard libraries. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 13 Apr '13

13 Apr '13

#7741: Add SIMD support to x86/x86_64 NCG -----------------------------+---------------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #3557 -----------------------------+---------------------------------------------- ghc-7.7.20130301 has SIMD support. But only LLVM backend supports SIMD currently. If we want to use SIMD, we should use LLVM backend. I request to add SIMD support to x86/x86_64 NCG. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP)
by GHC 13 Apr '13

13 Apr '13

#7736: Parallel array enumeration causes compiler panic (enumFromToP) -------------------------------+-------------------------------------------- Reporter: amosrobinson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Enumeration doesn't work in parallel array comprehensions: {{{ nums = [: 0 .. 100 :] }}} causes a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense: {{{ other = 5 / "bad" nums = [: 0 .. 100 :] }}} it still panics. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7735: -fext-core doesn't generate .hcr when .o and .hi files are present
by GHC 13 Apr '13

13 Apr '13

#7735: -fext-core doesn't generate .hcr when .o and .hi files are present ------------------------------------+--------------------------------------- Reporter: kmels | Owner: Type: bug | Status: new Priority: normal | Component: External Core Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Create a file inside a directory and compile it using -fext-core: {{{ cd /tmp/ mkdir dir echo "module Main where main = return ()" > dir/Main.hs ghc --make -fext-core dir/Main.hs [1 of 1] Compiling Main ( dir/Main.hs, dir/Main.o ) Linking dir/Main ... kmels@kmels-workstelle /tmp $ ls dir/ Main Main.hcr Main.hi Main.hs Main.o }}} If the .hcr file is deleted and our program is compiled again with -fext- core, no .hcr file will be generated: {{{ rm dir/Main.hcr ghc --make -fext-core dir/Main.hs ls dir/ Main Main.hi Main.hs Main.o }}} The file is generated if you 1. cd to dir/ and 2. ghc --make -fext-core Main.hs -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7732: Allow killing of processes which are known by a System.Process.ProcessHandle
by GHC 13 Apr '13

13 Apr '13

#7732: Allow killing of processes which are known by a System.Process.ProcessHandle ----------------------------+----------------------------------------------- Reporter: timthelion | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/process Version: 7.4.2-rc1 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- There is no way to kill a process that is known only by it's ProcessHandle. That is, if I use createProcess to create a process, there is no way to kill it again. I can terminate it with terminateProcess but this is not the same. I would like to be able to kill processes as well. I think that something like this(completely untested change) would be good: https://github.com/timthelion/packages- process/commit/10ecc56682b9b71d3c196e47297b0f496cdc2bd7 https://github.com/timthelion/packages- process/commit/c4cdd064d7c154f41a5b2b7f73c6b0ac0b2dccb9 https://github.com/timthelion/packages- process/commit/1588100655f18bc2811edc0a5911e2b14a1ee411 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7725: Operators without colons
by GHC 13 Apr '13

13 Apr '13

#7725: Operators without colons ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This code is accepted: {{{ data A x y = (&) x y }}} but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact {{{a = (&)}}} reports "Not in scope: (&)".) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7724: cross-compile to iOS
by GHC 13 Apr '13

13 Apr '13

#7724: cross-compile to iOS ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: 7700, 7705, 7707, 7709, 7718, 7720, 7721, 7722 Blocking: | Related: ------------------------------+--------------------------------------------- A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4