January 2014 - ghc-tickets

Re: [GHC] #551: "No threads to run" ignores finalizers
by GHC 08 Jan '14

08 Jan '14

#551: "No threads to run" ignores finalizers -------------------------------------+------------------------------------ Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.0 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: We shouldn't consider this a bug, since we deliberately decided to go with the alternative behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/551#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 08 Jan '14

08 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): adding LLVM AARCH64 support would be great for GHC-IOS too. please reach out on ghc-devs / #ghc if you hit any problems or need any help -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 08 Jan '14

08 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): kgardas, its kinda gated on first doing some NCG cleanup, (because theres a lot of copy pasta logic across the current NCG backends, and improving the engineering niceness of NCG will make such easier). please feel welcome to hack out a prototype if you have the time, but please keep in mind that it may be easier after first cleaning up and refactoring NCG. I *hope* to have the time to start hacking on that refactoring end of january onwards, though i hope other people collab on it too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #551: "No threads to run" ignores finalizers
by GHC 08 Jan '14

08 Jan '14

#551: "No threads to run" ignores finalizers -------------------------------------+------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 5.0 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: closed => new * failure: => None/Unknown * cc: simonmar (added) * resolution: Fixed => * difficulty: => Unknown * architecture: => Unknown/Multiple * owner: simonmar => * os: => Unknown/Multiple Old description: > {{{ > This is re my posting under the subject "Weak pointers, > garbage collection & deadlocks" on > glasgow-haskell-users. > > Basically, the problem is that finaliser threads that > the next GC would generate aren't taken into account > when determining whether there are any more threads to > run. > > I attach a program reproducing the error. > }}} New description: {{{ This is re my posting under the subject "Weak pointers, garbage collection & deadlocks" on glasgow-haskell-users. Basically, the problem is that finaliser threads that the next GC would generate aren't taken into account when determining whether there are any more threads to run. I attach a program reproducing the error. }}} -- Comment: Reopening as per previous commit message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/551#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 07 Jan '14

07 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by kgardas): * owner: => kgardas Comment: Nobody stepped forward so far on this, so I'd like to give it a try myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 07 Jan '14

07 Jan '14

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8601: runghc from standard input and --ghc-args
by GHC 07 Jan '14

07 Jan '14

#8601: runghc from standard input and --ghc-args ------------------------------------+------------------------------------- Reporter: wuzzeb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am trying to use runghc with a cabal sandbox, and it works when the haskell code is in a file like follows: {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d somefile.hs }}} But if I try and load the script from standard input (actually I am trying to run a GHC script from a bash script using "runghc << EOF" but it is easier to see if you just run from the console) {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} you get an error {{{ .cabal-sandbox/i386-linux-ghc-7.6.3-packages.conf.d/:1:57: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) }}} Looking at the utils/runghc/runghc.hs source file, what happens is inside the doIt function. The first thing the doIt function does is call getGhcArgs which strips the --ghc-args. Then it checks the args and sees there is no file, so falls into the case where it reads standard input, creates a temp file, and then recalls doIt. Here is the problem, because the "--ghc-arg" string has already been stripped so the second call to doIt is where the error occurs. With that, I can actually get it to work with the following :) {{{ runghc -- -package-db --ghc-arg=--ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} By passing --ghc-arg= twice, it is stripped once the first time doIt is called and once the second time and GHC gets the correct args :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 07 Jan '14

07 Jan '14

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Ben! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF)
by GHC 07 Jan '14

07 Jan '14

#8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) -----------------------------------+--------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- So far, and that is what is documented > Additional arguments to the pre-processor can be passed in using the {{{-optF}}} option. These are fed to cmd on the command line after the three standard input and output arguments. However, {{{GHC 7.7.20131026}}} passes additional arguments (specified with {{{-optF}}}) before the three standard arguments. Steps to reproduce: {{{ $ echo '{-# OPTIONS_GHC -F -pgmF ./foo.sh -optF bar #-}' > Foo.hs $ echo 'echo $*' > foo.sh $ chmod +x foo.sh $ ghci Foo.hs }}} Expected result: {{{Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp bar}}} is printed to stdout Actual result: {{{bar Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp}}} is printed to stdout -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation.
by GHC 07 Jan '14

07 Jan '14

#8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- We just discussed the following code on #ghc. {{{ import System.IO.Unsafe import Control.Concurrent.MVar import Control.Concurrent import GHC.Conc (par, pseq) x :: MVar Int -> Int -> Int x m a = unsafeDupablePerformIO $ withMVar m $ \i -> do sum [1..1000000 + a] `seq` return i main1 = do m <- newMVar 42 let w = x m 0 w `par` print w {- spark: thread blocked indefinitely in an MVar operation -} main2 = do m <- newMVar 42 let w = x m 0 forkIO $ print w forkIO $ print w print w {- spark: <<loop>> spark: <<loop>> -} main = main2 }}} This is not a bug; what happens is that the RTS suspends one of the duplicated computations of {{{w}}}, effectively killing the IO action that was passed to {{{unsafeDupablePerformIO}}} in the middle. This limitation of {{{unsafeDupablePerformIO}}} should be documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4