#5252: UNPACK without optimisation leads to panic -------------------------------------------------------+-------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: deSugar/should_compile/T5252, T5252Take2 | Blockedby: Blocking: | Related: -------------------------------------------------------+-------------------- Changes (by simonpj):
* status: new => merge * testcase: deSugar/should_compile/T5252 => deSugar/should_compile/T5252, T5252Take2 Comment: Needs this patch too: {{{ commit ba8fd081ba9b222dd5f93604d7deeaca372e4511 Author: Simon Peyton Jones <simo...@microsoft.com> Date: Mon Sep 17 18:22:10 2012 +0100 Make the call to chooseBoxingStrategy lazy again I made it strict, as an incidental consequence of this patch: commit 5bae803a18b17bdb158a7780e6b6ac3c520e5b39 Author: Simon Peyton Jones <simo...@microsoft.com> Date: Sat Sep 15 23:09:25 2012 +0100 Fix UNPACK with -fomit-interface-pragmas. But it's very important that chooseBoxingStrategy is lazy, else (in bigger programs with lots of recursion in types) GHC can loop. This showed up in Data.Sequence; and I think it was making haddock loop as well. Anyway this patch makes it lazy again. compiler/typecheck/TcTyClsDecls.lhs | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) }}} Regression test added. Merge to 7.6 branch. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5252#comment:6> 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