August 2013 - ghc-tickets

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 14 Aug '13

14 Aug '13

#7953: Segfault on x86 with -O2 -------------------------------------+---------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------- Comment (by kazu-yamamoto): I confirmed that this bug was fixed both on Linux and Mac. Let's close this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7953#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7382: Evaluating GHCi expressions is slow following the dynamic-by-default change
by GHC 14 Aug '13

14 Aug '13

#7382: Evaluating GHCi expressions is slow following the dynamic-by-default change -------------------------------------+------------------------------------- Reporter: parcs | Owner: Austin Seipp Type: bug | <aseipp@…> Priority: highest | Status: closed Component: GHCi | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp <aseipp@…>): In [changeset:22eccb7edb86e0ad4e7a6e8c2064cd0632df96a3/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="22eccb7edb86e0ad4e7a6e8c2064cd0632df96a3" print035 now passes (see #7382) Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7382#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7382: Evaluating GHCi expressions is slow following the dynamic-by-default change
by GHC 14 Aug '13

14 Aug '13

#7382: Evaluating GHCi expressions is slow following the dynamic-by-default change -------------------------------------+------------------------------------- Reporter: parcs | Owner: Austin Seipp Type: bug | <aseipp@…> Priority: highest | Status: closed Component: GHCi | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by Austin Seipp <aseipp@…>): * owner: => Austin Seipp <aseipp@…> * status: patch => closed * resolution: => fixed Comment: In [changeset:333273792479695cf79a72cffa4c579d0c9deb21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="333273792479695cf79a72cffa4c579d0c9deb21" Don't run the system linker unncessarily. This wastes time when evaluating expressions in GHCi. We also disable object unloading when using the dynamic linker, too. Fixes #7382. Fixes #7326. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7382#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7326: print035(ghci) fails when ghci is dynamic
by GHC 14 Aug '13

14 Aug '13

#7326: print035(ghci) fails when ghci is dynamic -------------------------------+------------------------------------------- Reporter: igloo | Owner: Austin Seipp <aseipp@…> Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by Austin Seipp <aseipp@…>): * owner: => Austin Seipp <aseipp@…> * status: new => closed * resolution: => fixed Comment: In [changeset:333273792479695cf79a72cffa4c579d0c9deb21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="333273792479695cf79a72cffa4c579d0c9deb21" Don't run the system linker unncessarily. This wastes time when evaluating expressions in GHCi. We also disable object unloading when using the dynamic linker, too. Fixes #7382. Fixes #7326. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7326#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8125: iOS patch no 17: Add .a suffix onto libraries that take the place of executables
by GHC 14 Aug '13

14 Aug '13

#8125: iOS patch no 17: Add .a suffix onto libraries that take the place of executables -------------------------------------------+-------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: Other Difficulty: Easy (less than 1 hour) | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | -------------------------------------------+-------------------------- When we cross-compile to iOS we want to generate .a files in place of executables. These .a files are linked by hand into an Xcode project. This patch adds the correct .a extension onto the end of the output file name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8126: iOS patch no 18: Fix Stage1Only so it doesn't build ghctags
by GHC 14 Aug '13

14 Aug '13

#8126: iOS patch no 18: Fix Stage1Only so it doesn't build ghctags -------------------------------------+------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | -------------------------------------+------------------------------------- Without this patch, the build breaks when Stage1Only = YES is set in mk/build.mk, because it tries to use the non-existent stage 2 compiler to build ghctags. I am not 100% sure this is correct but it seems so and it works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7382: Evaluating GHCi expressions is slow following the dynamic-by-default change
by GHC 14 Aug '13

14 Aug '13

#7382: Evaluating GHCi expressions is slow following the dynamic-by-default change --------------------------------------------+------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by parcs): The patch seems to make the test `ghci.debugger/scripts print035` successfully pass again. It's currently marked as broken on dynamic GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7382#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7382: Evaluating GHCi expressions is slow following the dynamic-by-default change
by GHC 14 Aug '13

14 Aug '13

#7382: Evaluating GHCi expressions is slow following the dynamic-by-default change --------------------------------------------+------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by parcs): * status: new => patch Comment: Here's a consolidated patch that contains the previous two patches and a final fix to the `unload` function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7382#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 14 Aug '13

14 Aug '13

#7953: Segfault on x86 with -O2 -------------------------------------+---------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------- Comment (by kazu-yamamoto): Austin guessed that 3e598fe0b01f4692f50c377ac91010040227e7ce fixed this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7953#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

13 Aug '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 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 exbb2): Replying to [comment:21 simonmar]: > Just never catch `SomeException` unless you intend to re-throw it. The code in my case quickly grew into monstrosity such as {{{ bracket openFile doDangerousStuff close `catches` [\Async -> throw ,\Some -> logFailureAndResume] }}} Even that doesn't work for Timeout, unless we resort to string comparison. > If you're handling an exception, you always know which exception(s) you're handling No. All arguments and values in function can throw any exception whatsoever, there can be no knowing of what exceptions you'll receive. e.g. what if the next version of base introduces a hard-to-track division by zero? We shouldn't ever care about what exception we got. If it had arisen from code enclosed by the handler, — there can be no doubt as to its intended recipient — and no danger in catching it. Asynchronous exceptions have only dimmest relation to code being executed or none at all, there can be no modularity when every exception handler is concerned with whole state of the universe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0