January 2013 - ghc-tickets

[GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 05 Jul '13

05 Jul '13

#7574: Register allocator chokes on certain branches with literals -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 7571, 7573 -----------------------------+---------------------------------------------- While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend: {{{ =====> T7571(normal) 6 of 6 [0, 0, 0] cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130113 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c7 }}} The test in question is: {{{ #include "Cmm.h" testLiteralBranch (W_ dst, W_ src) { if (1) { prim %memcpy(dst, src, 1024, 4); } else { prim %memcpy(dst, src, 512, 8); } return (); } }}} If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)``` I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 28 Jun '13

28 Jun '13

#7602: Threaded RTS performing badly on recent OS X (10.8?) ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime). Some results here: [http://www.haskell.org/pipermail/cvs- ghc/2011-July/063552.html] This is because the GC code relies on having fast access to thread-local state. It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X). To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly. I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details. We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it. A workaround is to install a real gcc (using homebrew?) and use that to compile GHC. Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 25

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

08 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] #7636: threadStackUnderflow: not enough space for return values
by GHC 06 Jun '13

06 Jun '13

#7636: threadStackUnderflow: not enough space for return values -------------------------+-------------------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- While filling a {{{Control.Concurrent.STM.TBQueue}}} (stm-2.4) with values the system crashes with the following message: {{{ internal error: threadStackUnderflow: not enough space for return values (GHC version 7.4.2 for x86_64_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/7636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 15

[GHC] #7592: Building the latest master branch on FreeBSD 9.1 fails
by GHC 19 May '13

19 May '13

#7592: Building the latest master branch on FreeBSD 9.1 fails -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following sequence fails on FreeBSD 9.1: {{{ % perl boot % ./configure --prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp- includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with- gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47 % gmake -j10 -d MAKE=gmake ... Putting child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 on the chain. Recipe of `ghc/stage1/package-data.mk' is being run. Pruning file `compiler/stage1/package-data.mk'. Live child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 Configuring ghc-bin-7.7.20130111... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Reaping winning child 0x801e5fd80 PID 36063 Removing child 0x801e5fd80 PID 36063 from chain. Considering target file `ghc/stage1/package-data.mk'. File `ghc/stage1/package-data.mk' was considered already. Re-executing[2]: gmake -r --no-print-directory -f ghc.mk phase=0 phase_0_builds GNU Make 3.82 Built for amd64-portbld-freebsd9.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `ghc.mk'... ghc.mk:84: *** Make has restarted itself 2 times; is there a makefile bug?. Sto p. Reaping losing child 0x80156e290 PID 34605 gmake: *** [all] Error 2 Removing child 0x80156e290 PID 34605 from chain. }}} If I type "gmake -j10 MAKE=gmake" gain, the building completes. I believe this is relating to http://www.haskell.org/pipermail/glasgow- haskell-users/2012-March/022150.html Actually if I remove "error" on line 84, this does not happen and the building completes without any problems. GHC for bootstrapping: 7.4.1, GCC 4.7.3, gmake: 3.82 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 23 Apr '13

23 Apr '13

#7606: Stride scheduling for Haskell threads with priorities -----------------------------+---------------------------------------------- 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: -----------------------------+---------------------------------------------- Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #7626: Add common utility variants of trace to Debug.Trace
by GHC 21 Apr '13

21 Apr '13

#7626: Add common utility variants of trace to Debug.Trace -----------------------------+---------------------------------------------- Reporter: chrisseaton | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: trace Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- As discussed on the libraries list. http://www.haskell.org/pipermail/libraries/2013-January/019319.html 'traceId' traces a value, and then returns that same value. This avoids the common case of 'trace a a'. {{{ traceId :: String -> String traceId a = trace a a }}} 'traceM' runs 'trace' and returns unit in an arbitrary monad. This is useful for writing traces in do-notation, as each can sit on their own line. {{{ traceM :: (Monad m) => String -> m () traceM string = trace string $ return () }}} For example: {{{ ... = do x <- ... traceM $ "x: " ++ show x y <- ... ... }}} That application of 'traceM' there can be temporarily commented out with a simple line comment. Finally, equivalents of 'traceShow' for those two functions. {{{ traceShowId :: (Show a) => a -> a traceShowId a = trace (show a) a }}} {{{ traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} Advantages: I use these functions in my code all the time. When I discussed it on the libraries list there were several enthusiastic +1s of people doing the same. Disadvantages: The documentation in the patch makes it clear that traceM does not actually add a trace action to the monad you're using, which is a potential point of confusion (http://www.haskell.org/pipermail/libraries/2013-January/019322.html) I had originally suggested that 'traceIO == traceM', but it turns out this is not so. Henning Thielemann suggested that 'traceM' was better achieved with directly using 'trace' and 'printf' (http://www.haskell.org/pipermail/libraries/2013-January/019320.html) Of course, any function can be replaced with its RHS, and whether or not the user uses 'show' or 'printf' or whatever is orthogonal. I haven't written any tests, as it's all output generating code, so I'm really not sure how that's tested in GHC - sorry. Status of patch: Applies against base 3b51b741f45d4d85e79b2128d00479ce230f72f2 and compiles with GHC 388e1e825f79f2d16536fc583a48e5ce9c191b06. I've run a full GHC compile cycle with it without problem. Includes documentation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7638: bindist refers to libgmp.so.3 which is missing on Fedora 17
by GHC 20 Apr '13

20 Apr '13

#7638: bindist refers to libgmp.so.3 which is missing on Fedora 17 ----------------------------+----------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- binary distribution ghc-7.6.2-x86_64-unknown-linux.tar.bz2 contains executable(s) that expect libgmp.so.3 but recent systems (Fedora 17) have libgmp.so.10 instead, and I don't see how I could roll back. No big deal, but each fix requires a recompile (of gmp, of ghc). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7586: :kind command cannot show kind of type synonyms
by GHC 16 Apr '13

16 Apr '13

#7586: :kind command cannot show kind of type synonyms -----------------------------+---------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following illustrates the problem: {{{ Prelude> type T a = Int Prelude> :k T <interactive>:1:1: Type synonym `T' should have 1 argument, but has been given none In a type in a GHCi command: T }}} Undoubtedly, T has a kind, and there's no reason to insist that the type given to the :kind command should be fully applied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range)
by GHC 14 Apr '13

14 Apr '13

#7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) --------------------------------+------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Hello, an attempt to compile today GHC HEAD on linux powerpc fails with this message {{{ "inplace/bin/ghc-stage1" -static -H32m -O -package-name ghc-7.7.20130115 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.17.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.0.2 -package transformers-0.3.0.0 -package unix-2.6.1.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/codeGen/StgCmmPrim.hs -o compiler/stage2/build/StgCmmPrim.o /tmp/ghc20445_0/ghc20445_0.s: Assembler messages: /tmp/ghc20445_0/ghc20445_0.s:98896:0: Error: operand out of range (0x00000000000081ac is not between 0xffffffffffff8000 and 0x0000000000007ffc) make[1]: *** [compiler/stage2/build/StgCmmPrim.o] Error 1 make: *** [all] Error 2 }}} The platform is 32bit PowerPC running debian wheezy which provides GHC 7.4.1 used for bootstrapping GHC HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6