May 2013 - ghc-tickets

[GHC] #7860: Add more bit fiddling functions to 'integer-gmp'
by GHC 10 Jun '13

10 Jun '13

#7860: Add more bit fiddling functions to 'integer-gmp' -----------------------------+---------------------------------------------- Reporter: lebedev | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: gmp Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 3489 -----------------------------+---------------------------------------------- Current implementation of 'integer-gmp' uses only a subset of "bit fiddling" features, [http://gmplib.org/manual/Integer-Logic-and-Bit- Fiddling.html provided] by the GMP library. The ones missing are: {{{ * mpz_popcount * mpz_setbit * mpz_clrbit }}} I think it would be nice to add these functions in addition to 'testBitInteger'. Would you accept a patch? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 10

[GHC] #7718: ios patch no 8: adjustor pools
by GHC 09 Jun '13

09 Jun '13

#7718: ios patch no 8: adjustor pools ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- "Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime. However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that. It consists of three parts: 1. A POOLSIZE pragma, that is used like this: foreign import ccall safe "wrapper" {-# POOLSIZE 100 #-} mkDelegate :: IO () -> IO (FunPtr (IO ())) This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS. I am not sure what the procedure is for additions of pragmas. Do pragmas require {-# LANGUAGE xx #-} ? Anyway, please review whether the approach taken here is acceptable. 2. The Haskell code in the compiler to generate the stubs for the pooled adjustors. 3. The runtime system's implementation of pooled adjustors in C. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 24

[GHC] #7850: Strangely high memory usage on optimized Ackermann function
by GHC 09 Jun '13

09 Jun '13

#7850: Strangely high memory usage on optimized Ackermann function ------------------------------------+--------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Greetings. The following post on stack overflow demonstrates some strange behavior in, at least, recent GHC versions (7.4.2 on): [http://stackoverflow.com/questions/16115815/ackermann-very-inefficient- with-haskell-ghc] The program in question is simple: {{{ main = print $ ack 4 1 ack :: Int -> Int -> Int ack 0 !n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) $ ack m (n-1) }}} Here are the properties I've been able to deduce so far: 1) When compiled without optimizations, the program uses almost no memory, but of course takes a while. 2) When compiled with optimizations (-O and above), the program eats memory at a staggering rate. It easily freezes my machine in a matter of seconds. 3) -ddump-simpl reveals that the loop is completely unboxed, operating only on Int#. -ddump-prep also shows no lets where allocation would presumably happen. 4) Setting a maximum heap size typically seems to have no effect. When I set it to the minimum heap size with -M4096, even the optimized program seems to run in constant space most of the time. However, using something like -M1000000 seems to result in the outrageous memory usage, and the RTS never catches that far more than 1 megabyte of memory is being used. I had to convince myself that the flag actually does something with another test program. 5) The standard bounded stack also does nothing. So, we seem to have a program that is allocating vast amounts of (ostensibly) non-heap, non-stack memory; but only when optimized. I believe I once set the maximum heap to 40960B, and killed the program before it killed my machine. On exiting, I got a heap overflow error. So, my initial stab would be that the completely unboxed loop somehow ''is'' allocating in the heap, but somehow not in a way that ever allows the garbage collector or heap overflow check to run (similar to how a non- allocating loop can block any thread preemption). That's a wild guess, though. I'm unable to easily investigate the behavior on older GHC versions, unfortunately. So I'm unsure how far back this behavior goes. If I've missed something obvious, I apologize, but this seems like very odd behavior to me. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 30

[GHC] #7653: incorrect handling of StackOverflow exception in the event manager
by GHC 09 Jun '13

09 Jun '13

#7653: incorrect handling of StackOverflow exception in the event manager --------------------------+------------------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Under high pressure of `registerTimeout`s the event manager thread's stack overflows. Testcases: Shachaf initially reported this testcase on #ghc, which is irreproducible locally: {{{ import Control.Monad; import Control.Concurrent main = replicateM_ 1000000 (forkIO (threadDelay 1)) }}} to be compiled and run as follows: {{{ $ ghc -O2 -threaded Main.hs && time ./Main +RTS -N }}} Limiting the stack to the minimum helped to reproduce this locally, both on x86 and x64: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 502 (forkIO (threadDelay 1)) -- 504 on x64 }}} {{{ $ ghc -O2 -threaded -with-rtsopts="-N8 -K4" rplfrk.hs && ./rplfrk # -K8 on x64 }}} and this, though less deterministically: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 340 ( forkIO (threadDelay 1)) }}} {{{ $ ghc -O2 -threaded -rtsopts repl2-x86.hs && ./repl2-x86 +RTS -N1 -K4 }}} Error messages look like: {{{ Stack space overflow: current size 4 bytes. Use `+RTS -Ksize -RTS' to increase it. repl2-x86: sendWakeup: invalid argument (Bad file descriptor) [...repeated...] repl2-x86: ioManagerDie: write: Bad file descriptor }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #7633: Checkable "minimal complete definitions"
by GHC 09 Jun '13

09 Jun '13

#7633: Checkable "minimal complete definitions" -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 6028 -----------------------------+---------------------------------------------- #6028 suggested warning on cyclic unimplemented defaults. This doesn't work for the reasons mentioned there, among others (also e.g. [http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html /Control-Applicative.html#g:2 `Alternative`] has mutually recursive `some` and `many` methods, which shouldn't be warned about). Figuring out when to warn automatically seems hard. But Haskell already has an ad-hoc mechanism for specifying which methods need to be implemented: A "minimal complete definition" specified in the comments of almost every class definition that has optional methods. Unfortunately comments are aren't compiler-checked. It seems that the simplest solution would be to specify these in a way that the compiler can understand. The obvious approach is to add a pragma for it in the class definition. In particular, one could write a pragma for each "minimal set" of definitions, and the compiler could warn if none of them are implemented (and suggest which methods to implement). This lets us keep the convenience of default method implementations without losing safety. Without any pragmas, the compiler could fall back to the set "all methods without defaults", which is what it uses now. It might look something like this: {{{ class Functor m => Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b m >>= f = join (fmap f m) join :: m (m a) -> m a join m = m >>= id {-# MINIMAL return, join #-} {-# MINIMAL return, (>>=) #-} class Eq a where (==), (/=) :: a -> a -> Bool x == y = not (x /= y) x /= y = not (x == y) {-# MINIMAL (==) #-} {-# MINIMAL (/=) #-} }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 12

[GHC] #7738: Testsuite failures for ghci tests normalising stderr output for .exe
by GHC 08 Jun '13

08 Jun '13

#7738: Testsuite failures for ghci tests normalising stderr output for .exe -------------------------+-------------------------------------------------- Reporter: rassilon | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- On GHC-Head: Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr. Here's an example of what happens currently: {{{ --- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500 +++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500 @@ -1 +1 @@ -getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.) +getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.) *** unexpected failure for getDirContents002(ghci) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7942: aarch64 support in ghc
by GHC 08 Jun '13

08 Jun '13

#7942: aarch64 support in ghc ------------------------------------+--------------------------------------- Reporter: jcapik | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Hello. Please, introduce the aarch64 support in ghc. The latest LLVM seems to support the aarch64 already. Thanks in advance. Regards, Jaromir. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 5

[GHC] #7739: Testsuite failures for HPC way tests on Windows
by GHC 08 Jun '13

08 Jun '13

#7739: Testsuite failures for HPC way tests on Windows -------------------------+-------------------------------------------------- Reporter: rassilon | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Here's what happens on GHC-HEAD: {{{ =====> annrun01(hpc) 15 of 3566 [0, 0, 6] cd ./annotations/should_run && $MAKE -s --no-print-directory config Creating Config.hs ... cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1 cd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: in module 'Config' Hpc failure: module mismatch with .tix/.mix file hash number (perhaps remove annrun01.exe.tix file?) *** unexpected failure for annrun01(hpc) }}} The cause appears to be due to not cleaning up .exe.tix files. After deleting the files the tests pass again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

[GHC] #7898: Compiler diverges when compiling module BSP of frag-1.1.2
by GHC 07 Jun '13

07 Jun '13

#7898: Compiler diverges when compiling module BSP of frag-1.1.2 -------------------------------+-------------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- GHC will get stuck when trying to compile [http://www.haskell.org/haskellwiki/Frag Frag]. Steps to reproduce: 1. Get Frag 1.1.2 from the Darcs repository (`darcs get http://code.haskell.org/frag`) or from snowmantw's !GitHub fork (`git clone https://github.com/snowmantw/Frag.git`) 1. Fix the code so it'll actually compile: {{{ diff --git a/src/Textures.hs b/src/Textures.hs index 7383fd8..b5516a5 100644 --- a/src/Textures.hs +++ b/src/Textures.hs @@ -10,6 +10,7 @@ import Graphics.UI.GLUT import TGA (readTga) import Data.Word (Word8) import Foreign.Marshal.Alloc (free) +import Control.Exception (catch, SomeException) -- read a list of images and returns a list of textures @@ -32,7 +33,8 @@ getAndCreateTexture fileName = do -- read the image data readImageC :: String -> IO (Maybe (Size, PixelData Word8)) -readImageC path = catch (readTga path) (\_ -> do print ("missing texture: "++path) +readImageC path = catch (readTga path) (\e -> do print (e :: SomeException) + print ("missing texture: "++path) return Nothing) }}} 1. `cabal configure` 1. `cabal build` GHC will get stuck on the module `BSP` and consume memory until it crashes. According to [https://github.com/snowmantw/Frag/issues/1 this ticket on the GitHub fork mentioned earlier], this problem only occurs with `-O2`. When I split the reading part of the module (`readBSP` and all functions it depends on), it crashed on that part. Will investigate further. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #7894: Crash on :i M.->
by GHC 07 Jun '13

07 Jun '13

#7894: Crash on :i M.-> -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ Prelude> :i M.-> ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130427 for x86_64-unknown-linux): isDataOcc: check me -> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2