June 2013 - ghc-tickets

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 09 Jun '13

09 Jun '13

#5687: Friendly Interface for auto-completion of GHCi ---------------------------------+------------------------------------------ Reporter: linsumang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): Is there any sort of standard for what the output should look like? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5687#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #5996: fix for CSE
by GHC 08 Jun '13

08 Jun '13

#5996: fix for CSE ---------------------------------+------------------------------------------ Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): I get very different nofib (mode=slow) results to you, using recent HEAD: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- [...] ansi -1.1% +9.4% +10.1% +10.1% +0.0% [...] compress -0.5% -0.0% 0.10 0.10 -33.3% [...] Min -2.2% -1.3% -6.6% -7.1% -33.3% Max -0.4% +9.4% +10.1% +10.1% +1.7% Geometric Mean -0.6% +0.1% +0.5% +0.5% -0.4% }}} I took a look at the ansi test. `Main.hs` is a boiled down version of it. Compiling with {{{ ghc -O2 -rtsopts --make Main -fforce-recomp }}} and running with {{{ time ./Main 1400 +RTS -t < /dev/null > out }}} I get {{{ <<ghc: 15797996408 bytes, 24864 GCs, 512598/945104 avg/max bytes residency (70 samples), 3M in use, 0.00 INIT (0.00 elapsed), 1.82 MUT (1.82 elapsed), 2.08 GC (2.08 elapsed) :ghc>> ./Main 1400 +RTS -t < /dev/null > out 3.88s user 0.03s system 99% cpu 3.907 total }}} for HEAD, and {{{ <<ghc: 16996446952 bytes, 27034 GCs, 536827/955856 avg/max bytes residency (75 samples), 3M in use, 0.00 INIT (0.00 elapsed), 1.95 MUT (1.95 elapsed), 2.64 GC (2.64 elapsed) :ghc>> ./Main 1400 +RTS -t < /dev/null > out 4.56s user 0.03s system 99% cpu 4.594 total }}} with this patch. I believe the difference is ultimately caused by the expression {{{ loop 0 "" }}} which appears in the program twice. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5996#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

08 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] #7968: fft2 benchmark sometimes fails (nofib)
by GHC 07 Jun '13

07 Jun '13

#7968: fft2 benchmark sometimes fails (nofib) ----------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Component: NoFib benchmark suite Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- I noticed that sometimes `fft2` program in nofib benchmark suite returns values that are slightly different from expected (see error message at the end of this report). The most worrying for me is that it sometimes works properly and sometimes fails, as if the correctness of result depended on some random factor. {{{ ././fft2 512 < /dev/null expected stdout not matched by reality --- fft2.stdout7 2013-05-15 08:01:24.014049002 +0200 +++ /tmp/runtest10927.1 2013-06-04 18:06:08.401977002 +0200 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.6712796173433053e-12 +result2 = 2.6712796173433053e-12 +result3 = 4.827444399779779e-8 real 0m0.055s user 0m0.049s sys 0m0.005s ././fft2 512 < /dev/null expected stdout not matched by reality --- fft2.stdout7 2013-05-15 08:01:24.014049002 +0200 +++ /tmp/runtest10963.1 2013-06-04 18:06:08.507977002 +0200 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.6712796173433053e-12 +result2 = 2.6712796173433053e-12 +result3 = 4.827444399779779e-8 real 0m0.054s user 0m0.047s sys 0m0.005s ././fft2 512 < /dev/null expected stdout not matched by reality --- fft2.stdout7 2013-05-15 08:01:24.014049002 +0200 +++ /tmp/runtest10999.1 2013-06-04 18:06:08.602977002 +0200 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.6712796173433053e-12 +result2 = 2.6712796173433053e-12 +result3 = 4.827444399779779e-8 real 0m0.052s user 0m0.044s sys 0m0.007s ././fft2 512 < /dev/null expected stdout not matched by reality --- fft2.stdout7 2013-05-15 08:01:24.014049002 +0200 +++ /tmp/runtest11035.1 2013-06-04 18:06:08.712977002 +0200 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.6712796173433053e-12 +result2 = 2.6712796173433053e-12 +result3 = 4.827444399779779e-8 real 0m0.052s user 0m0.046s sys 0m0.006s ././fft2 512 < /dev/null expected stdout not matched by reality --- fft2.stdout7 2013-05-15 08:01:24.014049002 +0200 +++ /tmp/runtest11071.1 2013-06-04 18:06:08.816977002 +0200 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.6712796173433053e-12 +result2 = 2.6712796173433053e-12 +result3 = 4.827444399779779e-8 make[2]: *** [runtests] Błąd 1 Failed making all in fft2: 1 make[1]: *** [all] Błąd 1 Failed making all in spectral: 1 make: *** [all] Błąd 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

07 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch 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 spent some time on figuring out why my patch works. Here's what I come up with (hopefully I got things right). Previously the !PrimOps of type `Compare` used to return `Bool` (`prelude/PrimOp.lhs`): {{{ getPrimOpResultInfo :: PrimOp -> PrimOpResultInfo getPrimOpResultInfo op = case (primOpInfo op) of Compare _ _ -> ReturnsAlg boolTyCon }}} I changed them to return `Int#`: {{{ getPrimOpResultInfo :: PrimOp -> PrimOpResultInfo getPrimOpResultInfo op = case (primOpInfo op) of Compare _ _ -> ReturnsPrim (tyConPrimRep intPrimTyCon) }}} This is how primops are converted from Core to STG (`CoreToStg.lhs`, `coreToStgApp` function): {{{ res_ty = exprType (mkApps (Var f) args) app = case idDetails f of -- Some primitive operator that might be implemented as a library call. PrimOpId op -> ASSERT( saturated ) StgOpApp (StgPrimOp op) args' res_ty }}} Previously `res_ty` was set to `Bool`, now it is `Int#`. STG representation of a primop is converted to Cmm (`StgCmmExpr.hs`) by `cgExpr` function: {{{ cgExpr (StgOpApp op args ty) = cgOpApp op args ty }}} So previously `cgOpApp` function matched this guard: {{{ | ReturnsAlg tycon <- result_info , isEnumerationTyCon tycon -- c.f. cgExpr (...TagToEnumOp...) = do dflags <- getDynFlags tag_reg <- newTemp (bWord dflags) cgPrimOp [tag_reg] primop args emitReturn [tagToClosure dflags tycon (CmmReg (CmmLocal tag_reg))] }}} and now it matches this one: {{{ | ReturnsPrim rep <- result_info = do dflags <- getDynFlags res <- newTemp (primRepCmmType dflags rep) cgPrimOp [res] primop args emitReturn [CmmReg (CmmLocal res)] }}} The main difference being that there is no call to `tagToClosure`, which was the goal of this ticket - to return an unboxed unlifted value instead of a closure that needs to be entered or have its tag examined. This leads me to a conclusion: since `tagToClosure` is an implementation of `tagToEnum#` primop, there should be no performance difference between the previous version of code, where call to `tagToEnum#` was generated implicitly by the code generator, and the new primop wrappers, which make the call to `tagToEnum#` explicit. In theory at least, because kahan for some reason is slower. I'm investigating this but so far I found nothing that would be obvious. And I'm also working on identifying code that is no longer necessary. One thing that keeps me puzzled is that there are still primops that return `Bool`, e.g. {{{ primop SameMutVarOp "sameMutVar#" GenPrimOp MutVar# s a -> MutVar# s a -> Bool }}} I'm not sure if this allows me to remove special case that Simon M. mentioned. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0