August 2013 - ghc-tickets

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 01 Aug '13

01 Aug '13

#7473: getModificationTime gives only second-level resolution ----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/directory | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by redneb): * cc: redneb@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 01 Aug '13

01 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by danr): * cc: danr@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7881: Warning for pointless ranges like [5..2]
by GHC 01 Aug '13

01 Aug '13

#7881: Warning for pointless ranges like [5..2] -------------------------------------+------------------------------------ Reporter: mpe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: beginner,warning Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Thanks for the suggestion; now done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7881#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 01 Aug '13

01 Aug '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): note: the primary first user for this planned work, ryan newton, is ok with the atomic operations being the threaded versions even with the single threaded RTS. (this will simplify initial engineering, though it does mean there will be a small perf penalty on sequential RTS relative to theoretical peformance). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 01 Aug '13

01 Aug '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Some notes on which operations the "atomic-primops" library is currently exposing, and the other concurrent data structure libs (e.g. chaselev- deque) are using: * CAS on MutVars, MutableArray#, and MutableByteArray# * fetch and add on MutableByteArray# * barriers / memory fences Drafts of .cmm for these can be found inside the atomic-primops library. Note that *only* casMutVar# is currently shipped with GHC. Ultimately there's no reason that we shouldn't aim for a fairly "complete set". For example, why not have fetch-and-sub and the other "atomicrmw" variants? Relating these to the LLVM atomics and memory orderings, they become: * CAS variants = LLVM cmpxchg with SequentiallyConsistent ordering * fetch-and-X variants = LLVM atomicrmw with SequentiallyConsistent * store_load_barrier = LLVM fenceInst with SequentiallyConsistent * write_barrier and load_load_barrier = I *think* these are both covered by a FenceInst with AcquireRelease ordering... I'm not an LLVM expert, so please double check these yourself before trusting them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: Runtime failure profiling with +RTS -hc -hbdrag, void
by GHC 01 Aug '13

01 Aug '13

#7836: Runtime failure profiling with +RTS -hc -hbdrag,void ----------------------------------+---------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by crockeea): I got the following error: {{{ > ghc -rtsopts -prof -fprof-auto -threaded A > ./A +RTS -sstderr -hb A: internal error: Invalid object in processHeapClosureForDead(): 0 (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} All other heap profiling options (-hc -hm -hd -hy -hr) work without error. Note that this occurred with GHC 7.6.3. My program is too large to post, but I figured I would add this to the bug report to let you know the problem persists. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 01 Aug '13

01 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by goldfire): * cc: eir@… (added) Comment: I just ran into the same problem as parcs, in trying to fix a performance bug it seems I have introduced (in my own branch). Is there a page with advice on fixing performance problems other than [wiki:Debugging/ProfilingGhc]? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8106: Confusing parse error for missing do keyword
by GHC 01 Aug '13

01 Aug '13

#8106: Confusing parse error for missing do keyword -------------------------------------+-------------------------- Reporter: mhitza | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+-------------------------- {{{ import Control.Monad (when) main = do when (True == True) $ x <- getLine print "y" }}} This piece of code is missing the `do` keyword before the block, yet the error message that is returned is: {{{ poc.hs:4:11: Parse error in pattern: True == True }}} Yet the next variant provides a bit more helpful information {{{ import Control.Monad (when) main = do when (True == True) $ print "x" print "y" }}} {{{ poc.hs:5:9: Couldn't match expected type `(a0 -> IO ()) -> [Char] -> m0 ()' with actual type `IO ()' The function `print' is applied to three arguments, but its type `[Char] -> IO ()' has only one In the second argument of `($)', namely `print "x" print "y"' In a stmt of a 'do' block: when (True == True) $ print "x" print "y" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1