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

[Simon Peyton Jones]

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 at leeds.ac.uk]
| Sent: 05 February 2015 11:47
| To: Simon Peyton Jones; Simon Marlow
| Cc: ghc-devs at 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 at haskell.org] On Behalf Of
| Peter
| > | Wortmann
| > | Sent: 04 February 2015 17:24
| > | To: ghc-devs at 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 at haskell.org] On
| Behalf
| > | Of
| > | > | GHC
| > | > | Sent: 31 January 2015 17:38
| > | > | Cc: ghc-tickets at 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 at haskell.org
| > | > | http://www.haskell.org/mailman/listinfo/ghc-tickets
| > | >
| > |
| > | _______________________________________________
| > | ghc-devs mailing list
| > | ghc-devs at haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-devs