January 2014 - ghc-tickets

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 20 Jan '14

20 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:40 awson]: > If we leave {{{lookupSymbol}}} unmodified then address of "far" symbol, imported from DLL, and returned by {{{lookupSymbol}}} is different from trampoline address. Is this ok? Or do I completely misunderstand the picture? That should be fine. Callers of `lookupSymbol` probably want the real address, not a newly allocated trampoline. If we allocated a trampoline for every call to `lookupSymbol`, we would have a problematic memory leak. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 20 Jan '14

20 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): If we leave {{{lookupSymbol}}} unmodified then "far" symbol, imported from DLL, being accessed through {{{lookupSymbol}}} has different address than being accessed through trampoline. Is this ok? Or do I completely misunderstand the picture? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7619: Make worker-wrapper unbox data families
by GHC 20 Jan '14

20 Jan '14

#7619: Make worker-wrapper unbox data families ------------------------------------------+-------------------------------- Reporter: akio | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: type family Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: perf/should_run/T7619 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by nomeata): * status: new => closed * testcase: => perf/should_run/T7619 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7619#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7619: Make worker-wrapper unbox data families
by GHC 20 Jan '14

20 Jan '14

#7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"2bb19fad1d809dda37011f442b0fd561aea045b6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2bb19fad1d809dda37011f442b0fd561aea045b6" Make worker-wrapper unbox data families by passing the FamInstEnvs all the way down. This closes #7619. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7619#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 20 Jan '14

20 Jan '14

#4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by simonmar): Things got worse for a while when we were including timestamps in the interface, but then #8144 fixed that. There are still a set of underlying problems that cause non-determinism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 20 Jan '14

20 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:38 awson]: > Edit: > Perhaps, reusing {{{SymbolExtra *symbol_extras}}} pointer in {{{ObjectCode}}} structure is not such a good idea, because in current code {{{lookupSymbol}}} is used in haskell object-linking code and calls {{{lookupSymbolInDLLs}}} directly. Thus we probably should make a trampoline for every "far" symbol, imported from DLL, as is now in my patch. I don't understand this, could you explain more? Surely it should be fine to return a 64-bit pointer from `lookupSymbol`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 20 Jan '14

20 Jan '14

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------ Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 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 lpsmith): * cc: leon.p.smith@… (added) * difficulty: => Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 20 Jan '14

20 Jan '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Andrea): Replying to [comment:33 thoughtpolice]: > Furthermore I can't find the source code for `pthread_getspecific` & co, so it's impossible to check if my 10.8 fix still works OK. The most recent `pthread_getspecific` source released by Apple was part of Libc-825.40.1. You can find it here: http://www.opensource.apple.com/source/Libc/Libc-825.40.1/x86_64/pthreads/p… Following Libc-825.40.1 Apple released the source for Libc-997.1.1 but the `pthread_getspecific` code is missing (they forgot it: http://lists.apple.com/archives/darwin-dev/2013/Nov/msg00002.html) I'm not an uber expert but TLS seems now to be working very similarly to how it works on other unixes and therefore it's unlikely that there has been any further change to `pthread_getspecific`. So maybe an inline function (like the `_pthread_getspecific_direct` in comment 13) can now be used with a key from 'pthread_key_create' without stealing a predefined slot. Recommendations in comment 16 by simonmar would still apply, of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7216: Compositional blocking on file descriptors
by GHC 20 Jan '14

20 Jan '14

#7216: Compositional blocking on file descriptors -------------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by twhitehead): It seems a bit strange that the last patch re-implemented different versions of threadWait{Read,Write}STM in Control.Concurrent for Windows (mingw32_HOST_OS) despite the GHC.Conc versions covering both Windows and non-Windows. Why not just Control.Concurrent.threadWaitReadSTM :: Fd -> IO (STM (), IO ()) Control.Concurrent.threadWaitReadSTM = GHC.Conc.threadWaitReadSTM Control.Concurrent.threadWaitWriteSTM :: Fd -> IO (STM (), IO ()) Control.Concurrent.threadWaitWriteSTM = GHC.Conc.threadWaitWriteSTM If the issue is the GHC.Conc versions for Windows are deficient (e.g., they don't handle [pass along] threadWait{Read,Write} exceptions), shouldn't they be fixed instead? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7216#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 19 Jan '14

19 Jan '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 Tarrasch): Hi Carter, Implementing stack traces can be thought of two parts, (1) the code- generator stuff that now has to be able to also emit debug data and (2) Library and rts components. Peter is working on the (1)-part, his most recent work is here[1] (afaict). I work on the (2)-side of things. My work is here[2]. But I think the most interesting parts is the research and conversations we're having. Peter and I are usually collaborating at least weekly on this. I'll be more than happy to share or explain any detail you might be interested in. [1]: https://github.com/scpmw/ghc/tree/profiling-import [2]: https://github.com/Tarrasch/ghc/tree/dev (I just pushed this, good thing you reminded me) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0