#7240: Stack trace truncated too much with indirect recursion ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar):

* difficulty: => Unknown Comment: I like your original idea (only truncating on a real loop), but I don't understand the explanation of why it didn't work. Is it a bug in `enterCCSFun`, or just a consequence of the way it works? The way I like to think about this problem is in terms of equalities. I want two equalities to hold: {{{ push L (\x.e) == \x. push L e let f = \x.e in E[f] == E[\x.e] }}} I'm using `==` to mean that the stacks are the same, in some sense. Perhaps a more precise way is to say that the stack when evaluating `e` is the same in both cases. The first one tells us that it is ok to move a `push` inside a lambda, which in turn tells us that `push` scopes over the body of a lambda, which is the behaviour we want. The second one corresponds to inlining, which is a transformation that GHC performs all the time. We need it to be the case that inlining a function does not change the stack. The second equality gives rise to this: {{{ call (push f S) S == push f S }}} which is not satisfied by the current definition of `call` and `push`, because `push f S` might truncate the stack (the same applies to your definition too, I believe). One definition that does work is to ignore the second and subsequent occurrences of labels in the stack, but that gives bad results for other reasons. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7240#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs