RE: [GHC] #10052: Panic (something to do with floatExpr?)

Peter: Here's a bad crash, due to you. (Doing this by email because I'm offline.) The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply panics in some cases. Could you fix this please? Either that case shouldn't happen, in which case Core Lint should check for it, and whoever is generating it should be fixed. Or it should happen, in which case floatExpr should do the right thing. Could you leave a Note to explain what is happening in the floatExpr (Tick ...) cases? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 31 January 2015 17:38 | Cc: ghc-tickets@haskell.org | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | | #10052: Panic (something to do with floatExpr?) | -------------------------------------+----------------------------------- | -- | Reporter: edsko | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.10.1-rc2 | Keywords: | Operating System: | Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | | -------------------------------------+----------------------------------- | -- | Loading | | {{{ | main = let (x :: String) = "hello" in putStrLn x | }}} | | using a very simple driver for the GHC API (see T145.hs) causes a ghc | panic: | | {{{ | [1 of 1] Compiling Main ( T145-input.hs, interpreted ) | T145: T145: panic! (the 'impossible' happened) | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | floatExpr tick | <<details unavailable>> | | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | }}} | | This panic is arising in our test case for #8333, so it may be related | to | that bug. | | -- | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10052 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

We are clearly trying to float past a breakpoint here, which is simply impossible. Pretty sure this would have been a panic before my changes too (it would have tried to "mkNoCount" the breakpoint). Guess I was wrong reading a "breakpoints don't appear here" invariant out of that... The quick fix would be to drop all floats in-place: -- scoped, counting and unsplittable, can't be floated through | otherwise = floatBody tOP_LEVEL expr This fixes the panic, but is a bit awkward. Probably better to change SetLevels? Not a piece of code I'm very familiar with... Greetings, Peter On 04/02/2015 13:31, Simon Peyton Jones wrote:
Peter:
Here's a bad crash, due to you. (Doing this by email because I'm offline.)
The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply panics in some cases.
Could you fix this please? Either that case shouldn't happen, in which case Core Lint should check for it, and whoever is generating it should be fixed. Or it should happen, in which case floatExpr should do the right thing.
Could you leave a Note to explain what is happening in the floatExpr (Tick ...) cases?
Thanks
Simon
| -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 31 January 2015 17:38 | Cc: ghc-tickets@haskell.org | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | | #10052: Panic (something to do with floatExpr?) | -------------------------------------+----------------------------------- | -- | Reporter: edsko | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.10.1-rc2 | Keywords: | Operating System: | Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | | -------------------------------------+----------------------------------- | -- | Loading | | {{{ | main = let (x :: String) = "hello" in putStrLn x | }}} | | using a very simple driver for the GHC API (see T145.hs) causes a ghc | panic: | | {{{ | [1 of 1] Compiling Main ( T145-input.hs, interpreted ) | T145: T145: panic! (the 'impossible' happened) | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | floatExpr tick | <<details unavailable>> | | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | }}} | | This panic is arising in our test case for #8333, so it may be related | to | that bug. | | -- | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10052 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

(Simon Marlow, can you help?) I don't understand how breakpoints work. Why do you say "we are clearly trying to float past a breakpoint"? Why is it so clear? Why is it wrong to float a lazy thunk out of a breakpoint? The float-out pass really doesn't have anywhere else where we say "you really can't float anything out of this subexpression, not even top-level constant expressions". Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Peter | Wortmann | Sent: 04 February 2015 17:24 | To: ghc-devs@haskell.org | Subject: Re: [GHC] #10052: Panic (something to do with floatExpr?) | | | | We are clearly trying to float past a breakpoint here, which is simply | impossible. Pretty sure this would have been a panic before my changes | too (it would have tried to "mkNoCount" the breakpoint). Guess I was | wrong reading a "breakpoints don't appear here" invariant out of that... | | The quick fix would be to drop all floats in-place: | | -- scoped, counting and unsplittable, can't be floated through | | otherwise | = floatBody tOP_LEVEL expr | | This fixes the panic, but is a bit awkward. Probably better to change | SetLevels? Not a piece of code I'm very familiar with... | | Greetings, | Peter | | On 04/02/2015 13:31, Simon Peyton Jones wrote: | > Peter: | > | > Here's a bad crash, due to you. (Doing this by email because I'm | offline.) | > | > The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply | panics in some cases. | > | > Could you fix this please? Either that case shouldn't happen, in which | case Core Lint should check for it, and whoever is generating it should | be fixed. Or it should happen, in which case floatExpr should do the | right thing. | > | > Could you leave a Note to explain what is happening in the floatExpr | (Tick ...) cases? | > | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of | > | GHC | > | Sent: 31 January 2015 17:38 | > | Cc: ghc-tickets@haskell.org | > | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | > | | > | #10052: Panic (something to do with floatExpr?) | > | -------------------------------------+------------------------------- | ---- | > | -- | > | Reporter: edsko | Owner: | > | Type: bug | Status: new | > | Priority: normal | Milestone: | > | Component: Compiler | Version: 7.10.1-rc2 | > | Keywords: | Operating System: | > | Unknown/Multiple | > | Architecture: | Type of failure: | None/Unknown | > | Unknown/Multiple | Blocked By: | > | Test Case: | Related Tickets: | > | Blocking: | | > | Differential Revisions: | | > | -------------------------------------+------------------------------- | ---- | > | -- | > | Loading | > | | > | {{{ | > | main = let (x :: String) = "hello" in putStrLn x | > | }}} | > | | > | using a very simple driver for the GHC API (see T145.hs) causes a | ghc | > | panic: | > | | > | {{{ | > | [1 of 1] Compiling Main ( T145-input.hs, interpreted ) | > | T145: T145: panic! (the 'impossible' happened) | > | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | > | floatExpr tick | > | <<details unavailable>> | > | | > | Please report this as a GHC bug: | http://www.haskell.org/ghc/reportabug | > | }}} | > | | > | This panic is arising in our test case for #8333, so it may be | related | > | to | > | that bug. | > | | > | -- | > | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10052 | > | GHC http://www.haskell.org/ghc/ | > | The Glasgow Haskell Compiler | > | _______________________________________________ | > | ghc-tickets mailing list | > | ghc-tickets@haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-tickets | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Simon Peyton Jones wrote:
Why do you say "we are clearly trying to float past a breakpoint"? Why is it so clear?
It's the only kind of Tickish that is scoped, counting and not splittable. This means that we can't a) Simply float code out of it, because the payload must still be covered (scoped) b) Copy the tick, because it would change entry counts (here: duplicate breakpoints)
Why is it wrong to float a lazy thunk out of a breakpoint?
Good questions - I haven't given breakpoint semantics a lot of thought, to be honest. My assumption was that most optimisation passes would never see them. And where they did, they should just leave them in peace as much as possible. For whatever it's worth, the source cautions against making breakpoints unscoped: -- Breakpoints are scoped: eventually we're going to do call -- stacks, but also this helps prevent the simplifier from moving -- breakpoints around and changing their result type (see #1531). Hm. We might try to make them pseudo-splittable, with non-counting breakpoints being NOPs for now? This might still allow us to implement breakpoint-based stack traces if we really want them... Greetings, Peter
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Peter | Wortmann | Sent: 04 February 2015 17:24 | To: ghc-devs@haskell.org | Subject: Re: [GHC] #10052: Panic (something to do with floatExpr?) | | | | We are clearly trying to float past a breakpoint here, which is simply | impossible. Pretty sure this would have been a panic before my changes | too (it would have tried to "mkNoCount" the breakpoint). Guess I was | wrong reading a "breakpoints don't appear here" invariant out of that... | | The quick fix would be to drop all floats in-place: | | -- scoped, counting and unsplittable, can't be floated through | | otherwise | = floatBody tOP_LEVEL expr | | This fixes the panic, but is a bit awkward. Probably better to change | SetLevels? Not a piece of code I'm very familiar with... | | Greetings, | Peter | | On 04/02/2015 13:31, Simon Peyton Jones wrote: | > Peter: | > | > Here's a bad crash, due to you. (Doing this by email because I'm | offline.) | > | > The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply | panics in some cases. | > | > Could you fix this please? Either that case shouldn't happen, in which | case Core Lint should check for it, and whoever is generating it should | be fixed. Or it should happen, in which case floatExpr should do the | right thing. | > | > Could you leave a Note to explain what is happening in the floatExpr | (Tick ...) cases? | > | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of | > | GHC | > | Sent: 31 January 2015 17:38 | > | Cc: ghc-tickets@haskell.org | > | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | > | | > | #10052: Panic (something to do with floatExpr?) | > | -------------------------------------+------------------------------- | ---- | > | -- | > | Reporter: edsko | Owner: | > | Type: bug | Status: new | > | Priority: normal | Milestone: | > | Component: Compiler | Version: 7.10.1-rc2 | > | Keywords: | Operating System: | > | Unknown/Multiple | > | Architecture: | Type of failure: | None/Unknown | > | Unknown/Multiple | Blocked By: | > | Test Case: | Related Tickets: | > | Blocking: | | > | Differential Revisions: | | > | -------------------------------------+------------------------------- | ---- | > | -- | > | Loading | > | | > | {{{ | > | main = let (x :: String) = "hello" in putStrLn x | > | }}} | > | | > | using a very simple driver for the GHC API (see T145.hs) causes a | ghc | > | panic: | > | | > | {{{ | > | [1 of 1] Compiling Main ( T145-input.hs, interpreted ) | > | T145: T145: panic! (the 'impossible' happened) | > | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | > | floatExpr tick | > | <<details unavailable>> | > | | > | Please report this as a GHC bug: | http://www.haskell.org/ghc/reportabug | > | }}} | > | | > | This panic is arising in our test case for #8333, so it may be | related | > | to | > | that bug. | > | | > | -- | > | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10052 | > | GHC http://www.haskell.org/ghc/ | > | The Glasgow Haskell Compiler | > | _______________________________________________ | > | ghc-tickets mailing list | > | ghc-tickets@haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-tickets | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Peter, OK. This is really beyond my knowledge. Might you and Simon be able to work out something together? I can advise on FloatOut if necessary. Simon | -----Original Message----- | From: Peter Wortmann [mailto:scpmw@leeds.ac.uk] | Sent: 05 February 2015 11:47 | To: Simon Peyton Jones; Simon Marlow | Cc: ghc-devs@haskell.org | Subject: Re: [GHC] #10052: Panic (something to do with floatExpr?) | | | | Simon Peyton Jones wrote: | > Why do you say "we are clearly trying to float past a breakpoint"? Why | is it so clear? | | It's the only kind of Tickish that is scoped, counting and not | splittable. | | This means that we can't | | a) Simply float code out of it, because the payload must still be | covered (scoped) | | b) Copy the tick, because it would change entry counts (here: duplicate | breakpoints) | | > Why is it wrong to float a lazy thunk out of a breakpoint? | | Good questions - I haven't given breakpoint semantics a lot of thought, | to be honest. My assumption was that most optimisation passes would | never see them. And where they did, they should just leave them in peace | as much as possible. | | For whatever it's worth, the source cautions against making breakpoints | unscoped: | | -- Breakpoints are scoped: eventually we're going to do call | -- stacks, but also this helps prevent the simplifier from moving | -- breakpoints around and changing their result type (see #1531). | | Hm. We might try to make them pseudo-splittable, with non-counting | breakpoints being NOPs for now? This might still allow us to implement | breakpoint-based stack traces if we really want them... | | Greetings, | Peter | | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Peter | > | Wortmann | > | Sent: 04 February 2015 17:24 | > | To: ghc-devs@haskell.org | > | Subject: Re: [GHC] #10052: Panic (something to do with floatExpr?) | > | | > | | > | | > | We are clearly trying to float past a breakpoint here, which is | simply | > | impossible. Pretty sure this would have been a panic before my | changes | > | too (it would have tried to "mkNoCount" the breakpoint). Guess I was | > | wrong reading a "breakpoints don't appear here" invariant out of | that... | > | | > | The quick fix would be to drop all floats in-place: | > | | > | -- scoped, counting and unsplittable, can't be floated through | > | | otherwise | > | = floatBody tOP_LEVEL expr | > | | > | This fixes the panic, but is a bit awkward. Probably better to change | > | SetLevels? Not a piece of code I'm very familiar with... | > | | > | Greetings, | > | Peter | > | | > | On 04/02/2015 13:31, Simon Peyton Jones wrote: | > | > Peter: | > | > | > | > Here's a bad crash, due to you. (Doing this by email because I'm | > | offline.) | > | > | > | > The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply | > | panics in some cases. | > | > | > | > Could you fix this please? Either that case shouldn't happen, in | which | > | case Core Lint should check for it, and whoever is generating it | should | > | be fixed. Or it should happen, in which case floatExpr should do the | > | right thing. | > | > | > | > Could you leave a Note to explain what is happening in the | floatExpr | > | (Tick ...) cases? | > | > | > | > Thanks | > | > | > | > Simon | > | > | > | > | -----Original Message----- | > | > | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On | Behalf | > | Of | > | > | GHC | > | > | Sent: 31 January 2015 17:38 | > | > | Cc: ghc-tickets@haskell.org | > | > | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | > | > | | > | > | #10052: Panic (something to do with floatExpr?) | > | > | -------------------------------------+--------------------------- | ---- | > | ---- | > | > | -- | > | > | Reporter: edsko | Owner: | > | > | Type: bug | Status: new | > | > | Priority: normal | Milestone: | > | > | Component: Compiler | Version: | 7.10.1-rc2 | > | > | Keywords: | Operating System: | > | > | Unknown/Multiple | > | > | Architecture: | Type of failure: | > | None/Unknown | > | > | Unknown/Multiple | Blocked By: | > | > | Test Case: | Related Tickets: | > | > | Blocking: | | > | > | Differential Revisions: | | > | > | -------------------------------------+--------------------------- | ---- | > | ---- | > | > | -- | > | > | Loading | > | > | | > | > | {{{ | > | > | main = let (x :: String) = "hello" in putStrLn x | > | > | }}} | > | > | | > | > | using a very simple driver for the GHC API (see T145.hs) causes | a | > | ghc | > | > | panic: | > | > | | > | > | {{{ | > | > | [1 of 1] Compiling Main ( T145-input.hs, interpreted | ) | > | > | T145: T145: panic! (the 'impossible' happened) | > | > | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | > | > | floatExpr tick | > | > | <<details unavailable>> | > | > | | > | > | Please report this as a GHC bug: | > | http://www.haskell.org/ghc/reportabug | > | > | }}} | > | > | | > | > | This panic is arising in our test case for #8333, so it may be | > | related | > | > | to | > | > | that bug. | > | > | | > | > | -- | > | > | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10052 | > | > | GHC http://www.haskell.org/ghc/ | > | > | The Glasgow Haskell Compiler | > | > | _______________________________________________ | > | > | ghc-tickets mailing list | > | > | ghc-tickets@haskell.org | > | > | http://www.haskell.org/mailman/listinfo/ghc-tickets | > | > | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs@haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs
participants (2)
-
Peter Wortmann
-
Simon Peyton Jones