#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 <[email protected]>
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 <[email protected]>
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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
