July 2013 - ghc-tickets

Re: [GHC] #7902: Add support for byte endianness swapping exposed as a primops
by GHC 18 Jul '13

18 Jul '13

#7902: Add support for byte endianness swapping exposed as a primops ------------------------------------------------+-------------------------- Reporter: tab | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: bswap Operating System: Unknown/Multiple | endianness Type of failure: None/Unknown | Architecture: Test Case: codeGen/should_run/cgrun072 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by tab): Thanks ! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7902#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8071: GHCi consistently hangs, crashes in HEAD
by GHC 17 Jul '13

17 Jul '13

#8071: GHCi consistently hangs, crashes in HEAD ----------------------------------+------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- GHCi seems to be broken in its current state at least on x86_64 Linux: {{{ GHCi, version 7.7.20130717: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> True True Prelude> Tr<it then hangs as I try to type True>^C Prelude>^C Prelude>^C Prelude>^C Prelude>^C Prelude>^C Prelude>^C Prelude> ghc-stage2: internal error: evacuate: strange closure type 2107444472 (GHC version 7.7.20130717 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8071> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 igloo): I don't see why you can't have `newCatch`, provide you are willing to also have `newThrow` and to deal with passing the annoying `Bool`s around. But using an `AsyncException` hierarchy instead might be OK too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:15> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 simonmar): Now I think about it, this isn't such a bad idea. Unfortunately we can't implement `newCatch`, because the async exception might have been re- thrown (say by a `finally`) inside the io. So the best you can do is recognise an async exception by its type - i.e. if it is an child of `AsyncException` then it's async, otherwise not. But that's good, because it means we don't have to change the RTS or primops. Then there's the question of whether restarting the io is safe. It probably is; as Simon pointed out, the io inside `unsafePerformIO` is supposed to be a benign side-effect, so we ought to be able to repeat it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:14> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 igloo): Hmm. If we also had something like {{{ newUnsafePerformIO :: IO a -> a newUnsafePerformIO io = unsafePerformIO io' where io' = io `newCatch` (\eb -> (newThrow eb >> io')) }}} so that at the outermost level the unsafePerformIO knows how to continue, then would that suffice? Or would it still be possible for problematic thunks inside `io` to be reentered? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 simonmar): see also comment:1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:12> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 simonmar): It doesn't solve the problem, because the programmer has to be prepared for `newThrow` to ''return''. This is what happens if an async exception is thrown to a thread that is inside `newCatch` inside `unsafePerformIO` inside a thunk evaluation, and the thunk is subsequently re-entered. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:11> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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:9 igloo]: > If we had > {{{ > newCatch :: Exception e => IO a -> ((e, Bool{- async? -}) -> IO a) -> IO a > newCatch = ... primitive ... > > newThrow :: Exception e => (e, Bool) -> a > newThrow (e, async) = if async then do t <- myThreadId > throwTo t e > else throw e > }}} > then would using `newCatch` and `newThrow` in place of `catch` and `throw` solve the problem? (at the expense of having this annoying `Bool` getting in the way, and making the code less pretty). I've had that design for quite some time now, I'm unsure if there's another sensible solution, except magically tagging the exception values themselves, but that could only complicate things. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:10> 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 17 Jul '13

17 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | 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 igloo): If we had {{{ newCatch :: Exception e => IO a -> ((e, Bool{- async? -}) -> IO a) -> IO a newCatch = ... primitive ... newThrow :: Exception e => (e, Bool) -> a newThrow (e, async) = if async then do t <- myThreadId throwTo t e else throw e }}} then would using `newCatch` and `newThrow` in place of `catch` and `throw` solve the problem? (at the expense of having this annoying `Bool` getting in the way, and making the code less pretty). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8069: Small typo yields GHC panic
by GHC 17 Jul '13

17 Jul '13

#8069: Small typo yields GHC panic ------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following line contains a small typo (show instead of Show), and the result is a GHC panic under GHC 3.4.1: newtype MyInt = MyInt Int deriving(show) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1