#13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a latent bug, so there's no test case. Given code like {{{ let f = \x y z -> e1 in e2 }}} we have `SetLevels` put a “join ceiling” around `e1` to be sure that we don't let a join point float out, since any jump to that join point from `e1` would be invalid. However, an oversight in `lvlFloatRhs` has us putting the join ceiling around the lambdas instead—in other words, it appears that we might produce {{{ let f = join j = ... in \x y z -> ... jump j ... in e2 }}} (which is wrong because you can't jump out of a lambda) rather than {{{ let f = \x y z -> join j = ... in ... jump j ... in e2 }}} As it happens, this bug is latent because of the way `FloatOut` and `SetLevels` interact. `FloatOut` correctly understands where the join ceiling //should// be. Then, at each join ceiling, `FloatOut` drops all bindings marked “float me to the nearest join ceiling,” so if `j` is so marked, the latter example (the correct one) is the result and not the former. Nonetheless, `lvlFloatRhs` as written is clearly wrong. (This of course illustrates a shortcoming of the “join ceiling” scheme, at least as implemented: we rely on `FloatOut` and `SetLevels` agreeing on where the join ceilings are. It's easy to specify where they //should// be, but since there are two modules implementing them, we have twice the opportunities to get it wrong.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13382 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler