June 2013 - ghc-tickets

[GHC] #7999: Support QNXNTO-arm for LLVM backend
by GHC 20 Jun '13

20 Jun '13

#7999: Support QNXNTO-arm for LLVM backend ------------------------------------+--------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: QNX | Architecture: arm Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- I thought I had submitted this before, but I guess not. This patch just adds the configuration needed for the LLVM backend to know about QNXNTO for ARM. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 20 Jun '13

20 Jun '13

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------+-------------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Component: Compiler Version: 7.6.3 | Resolution: duplicate Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Compile-time crash Blockedby: | Blocking: Related: 5550 | -------------------------------+-------------------------------------------- Changes (by amosrobinson): * status: new => closed * resolution: => duplicate * related: => 5550 Comment: Hi, This looks like an instance of #5550: ForceSpecConstr was blowing up when specialising on recursive types (list, in this case). This is fixed in HEAD, but sadly there isn't a good fix until then (without modifying the vector library to remove ForceSpecConstr annotations). Can you change the [Int] to a Vector? Otherwise, you might just need to compile with -fno-spec-constr (or the lower threshhold, as you mentioned) for now. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7944#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #7998: Stage1Only does not work
by GHC 19 Jun '13

19 Jun '13

#7998: Stage1Only does not work -----------------------------+---------------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I have Stage1Only=YES but the build system continues to building stage2 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7997: waitForProcess and getProcessExitCode are unsafe against asynchronous exceptions
by GHC 19 Jun '13

19 Jun '13

#7997: waitForProcess and getProcessExitCode are unsafe against asynchronous exceptions ----------------------------------------+----------------------------------- Reporter: dfranke | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- In this description of the current behavior of ''waitForProcess'', assume for simplicity the following: 1. The process being waited on has already terminated. 2. Neither ''waitForProcess'' nor ''getProcessExitCode'' has previously been called for this ''ProcessHandle''. 3. ''waitpid()'' returns success on the first try; it does not get interrupted by a signal. Under these assumptions, ''waitForProcess'' currently behaves as follows: 1. It is passed a ''ProcessHandle'' named ''ph''. ''ProcessHandle'' is defined like so: {{{ data ProcessHandle__ = OpenHandle PHANDLE | ClosedHandle ExitCode newtype ProcessHandle = ProcessHandle (MVar ProcessHandle__) }}} 2. It allocate a ''CInt'' using ''alloca''; the pointer to it is named ''pret''. 3. It passes ''pret'' to ''c_waitForProcess''. ''c_waitForProcess'' makes a system call to ''waitpid()'', and populates ''pret'' with the result. 4. ''waitForProcess'' peeks into ''pret'' and then mutates ''ph'', changing it from an ''OpenHandle'' to a ''ClosedHandle''. There is already a comment in the source code mentioning that this approach is unsafe: {{{ -- don't hold the MVar while we call c_waitForProcess... -- (XXX but there's a small race window here during which another -- thread could close the handle or call waitForProcess) }}} , which is correct. However, it is also unsafe against asynchronous exceptions, and would remain so even if the ''MVar'' were held during the ''c_waitForProcess'' call. If an asynchronous exception occurs in between steps 3 and 4, then the system will be left in a state in which the child process has been successfully waited on by the OS, but the ''ProcessHandle'' is still in an ''OpenHandle'' state and the exit code has been lost. A subsequent call to ''waitForProcess'' will result in ''waitpid()'' unexpectedly returning ECHILD, or worse, the OS will have recycled the child process's PID and ''waitpid()'' will wait on the wrong process. ''getProcessExitCode'' has the same bug. I propose fixing this by redefining ''ProcessHandle'' like so: {{{ data ProcessHandle = ProcessHandle PHANDLE (Ptr CInt) (MVar (Ptr CInt)) }}} , where the second argument maybe points to the process's return code, and the third argument contains a pointer to a boolean flag indicating whether the second argument points to something meaningful. Extend the signature of ''c_waitForProcess'' to take both pointers. Then, let ''c_waitForProcess'' provide the following contract. If called as ''c_waitForProcess ph pret pflag'': 1. ''*pflag'' is required to be false at the start of the call. 2. If and only if the call to ''waitpid()'' returns successfully, then ''*pflag'' will be set to true and ''*pret'' will be populated with the exit code. Then, ''waitForProcess'' can behave as follows: 1. The entire routine is wrapped in ''withMVar''. Asynchronous exceptions are allowed to occur. 2. If ''*pflag'' is true, then construct an ''ExitCode'' from ''*pret'' and return it. 3. Otherwise, call ''c_waitForProcess'' (with the same retry behavior as presently), and then construct and return an ''ExitCode'' after a successful return. And ''getProcessExitCode'' can: 1. Mask exceptions. 2. ''tryTakeMVar''. If the ''MVar'' is already held, unmask exceptions and return ''Nothing''. 3. Peek at ''*pflag''. 4. Replace the ''MVar''. 5. Unmask exceptions. 6. If ''*pflag'' is true, then construct and return an ''ExitCode'' from ''*pret''. 7. Otherwise, return ''Nothing''. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7997> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7926: eventfd: unsupported operation when doing anything
by GHC 19 Jun '13

19 Jun '13

#7926: eventfd: unsupported operation when doing anything --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I'm using Debian jessie; sources.list is thus: {{{deb http://ftp.us.debian.org/debian jessie main contrib non-free}}} Ran apt-get upgrade 10 minutes ago. The contents of /var/log/apt/history.log (sorry for the massive list, not sure how to narrow it down): https://gist.github.com/joelteon/07c912a3e7e49be820cc ghc/ghci output (exit 1): {{{eventfd: unsupported operation (Function not implemented)}}} When launching a precompiled executable, the first time it executes an I/O action (exit 1): {{{hClose: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:84:3-10}}} `strace ghci` output is in this gist: https://gist.github.com/anonymous/dcc02c8b29a65ec49be6 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7994: Make foldl into a good consumer
by GHC 19 Jun '13

19 Jun '13

#7994: Make foldl into a good consumer ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ I really want `foldl` to be a good consumer, but our arity/cardinality analysis still isn't up to it. Here's a test case, derived from nofib's `x2n1`: {{{ module Foo( foo ) where import Data.Complex foo x = sum [f n | n <- [1 .. x]] f :: Int -> Complex Double {-# NOINLINE f #-} f n = mkPolar 1 ((2*pi)/fromIntegral n) ^ n }}} With the patch below (which is what I'd like to use), we get very obviously bad code: {{{ Foo.foo :: GHC.Types.Int -> Data.Complex.Complex GHC.Types.Double Foo.foo = \ (x_aia :: GHC.Types.Int) -> case x_aia of _ { GHC.Types.I# y_aye -> case GHC.Prim.># 1 y_aye of _ { GHC.Types.False -> letrec { go_aD8 [Occ=LoopBreaker] :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double go_aD8 = \ (x_aD9 :: GHC.Prim.Int#) -> let { ds_doR [Lbv=OneShot] :: Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double ds_doR = case GHC.Prim.==# x_aD9 y_aye of _ { GHC.Types.False -> go_aD8 (GHC.Prim.+# x_aD9 1); GHC.Types.True -> GHC.Base.id @ (Data.Complex.Complex GHC.Types.Double) } } in let { ds_aCs :: Data.Complex.Complex GHC.Types.Double ds_aCs = Foo.f (GHC.Types.I# x_aD9) } in \ (ds2_aCu :: Data.Complex.Complex GHC.Types.Double) -> ds_doR (Data.Complex.$fFloatingComplex_$s$c+ ds2_aCu ds_aCs); } in go_aD8 1 (Data.Complex.:+ @ GHC.Types.Double (GHC.Types.D# 0.0) Data.Complex.$fFloatingComplex1); GHC.Types.True -> Data.Complex.:+ @ GHC.Types.Double (GHC.Types.D# 0.0) Data.Complex.$fFloatingComplex1 } } }}} The local `go` function should have arity 2. The patch below is the one I'd like to apply to `base`: {{{ simonpj@cam-05-unx:~/code/HEAD/libraries/base$ git diff diff --git a/Data/List.hs b/Data/List.hs index e7e8602..a2e7ac0 100644 --- a/Data/List.hs +++ b/Data/List.hs @@ -1,5 +1,5 @@ {-# LANGUAGE Trustworthy #-} -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} ----------------------------------------------------------------------------- -- | @@ -995,11 +995,15 @@ unfoldr f b = -- ----------------------------------------------------------------------------- -- | A strict version of 'foldl'. -foldl' :: (b -> a -> b) -> b -> [a] -> b +foldl' :: forall a b. (b -> a -> b) -> b -> [a] -> b #ifdef __GLASGOW_HASKELL__ +{-# INLINE foldl' #-} +foldl' k z xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) (id :: b -> b) xs z +{- foldl' f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs +-} #else foldl' f a [] = a foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs @@ -1022,6 +1026,17 @@ foldl1' _ [] = errorEmptyList "foldl1'" -- ----------------------------------------------------------------------------- -- List sum and product +-- | The 'sum' function computes the sum of a finite list of numbers. +sum :: (Num a) => [a] -> a +-- | The 'product' function computes the product of a finite list of numbers. +product :: (Num a) => [a] -> a + +{-# INLINE sum #-} +sum = foldl (+) 0 +{-# INLINE product #-} +product = foldl (*) 1 + +{- {-# SPECIALISE sum :: [Int] -> Int #-} {-# SPECIALISE sum :: [Integer] -> Integer #-} {-# INLINABLE sum #-} @@ -1048,6 +1063,7 @@ product l = prod l 1 prod [] a = a prod (x:xs) a = prod xs (a*x) #endif +-} -- ----------------------------------------------------------------------------- -- Functions on strings diff --git a/GHC/List.lhs b/GHC/List.lhs index 049aa2a..87c93ae 100644 --- a/GHC/List.lhs +++ b/GHC/List.lhs @@ -1,6 +1,6 @@ \begin{code} {-# LANGUAGE Trustworthy #-} -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} {-# OPTIONS_HADDOCK hide #-} ----------------------------------------------------------------------------- @@ -179,11 +179,17 @@ filterFB c p x r | p x = x `c` r -- can be inlined, and then (often) strictness-analysed, -- and hence the classic space leak on foldl (+) 0 xs +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b +{-# INLINE foldl #-} +foldl k z xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z + +{- foldl :: (b -> a -> b) -> b -> [a] -> b foldl f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs +-} -- | 'scanl' is similar to 'foldl', but returns a list of successive -- reduced values from the left: }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7991: stm: add mkWeakTVar
by GHC 19 Jun '13

19 Jun '13

#7991: stm: add mkWeakTVar -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Component: libraries (other) Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The motivation is to get rid of an unsafeIOToSTM from pipes-concurrency. https://github.com/errge/Haskell-Pipes-Concurrency- Library/commit/356a295f2b8da3bcc89ffe8e121647237f472d0f -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 19 Jun '13

19 Jun '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by edsko): For the benefit of people who find this ticket: the SomeAsyncException class and corresponding functions are now in HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5902#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7996: building GHC HEAD with llvm-3.4(HEAD) fails
by GHC 19 Jun '13

19 Jun '13

#7996: building GHC HEAD with llvm-3.4(HEAD) fails -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- using the GHC head (commit 5dc74f385f1bbc9248ed950af255b946677c2ff9) and current LLVM head (3.4svn), i get the following error when i start a "quick-llvm" build {{{ "/usr/bin/ghc" -H64m -O0 -fllvm --make utils/ghc-cabal/Main.hs -o utils /ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings- deprecations \ -DCABAL_VERSION=1,17,0 \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ [ 1 of 70] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... wrong initalizer for intrinsic global variable [0 x i8*] undef Broken module found, compilation aborted! 0 libLLVM-3.4svn.dylib 0x0000000104f8301e llvm::sys::PrintStackTrace(__sFILE*) + 40 1 libLLVM-3.4svn.dylib 0x0000000104f83427 SignalHandler(int) + 243 2 libsystem_c.dylib 0x00007fff87ca294a _sigtramp + 26 3 libsystem_c.dylib 0x00007fff5b562a40 _sigtramp + 3549167888 4 libLLVM-3.4svn.dylib 0x0000000104f8329d abort + 22 5 libLLVM-3.4svn.dylib 0x0000000104b0c292 (anonymous namespace)::Verifier::abortIfBroken() + 236 6 libLLVM-3.4svn.dylib 0x0000000104b0ba92 (anonymous namespace)::Verifier::doFinalization(llvm::Module&) + 3490 7 libLLVM-3.4svn.dylib 0x0000000104afa548 llvm::FPPassManager::doFinalization(llvm::Module&) + 56 8 libLLVM-3.4svn.dylib 0x0000000104afa77a llvm::MPPassManager::runOnModule(llvm::Module&) + 538 9 libLLVM-3.4svn.dylib 0x0000000104afaa75 llvm::PassManagerImpl::run(llvm::Module&) + 155 10 libLLVM-3.4svn.dylib 0x0000000104afabb9 llvm::PassManager::run(llvm::Module&) + 13 11 opt 0x00000001046a1580 std::vector<std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> >, std::allocator<std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> > > >::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> >*, std::vector<std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> >, std::allocator<std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> > > > >, std::pair<llvm::BasicBlock*, llvm::SuccIterator<llvm::TerminatorInst*, llvm::BasicBlock> > const&) + 6910 12 libdyld.dylib 0x00007fff8f2227e1 start + 0 Stack dump: 0. Program arguments: opt /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc56116_0/ghc56116_0.ll -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc56116_0/ghc56116_0.bc -mem2reg --enable-tbaa=true llc: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc56116_0/ghc56116_0.bc: error: Could not open input file: No such file or directory make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 }}} i'm not sure whats going on here. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3