#7050: stage 1 compiler crashes when the "quickest" build flavour is chosen
-------------------------------+--------------------------------------------
Reporter: ilya | Owner:
Type: bug | Status: merge
Priority: normal | Milestone:
Component: Compiler | Version: 7.5
Keywords: | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: Building GHC failed
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
-------------------------------+--------------------------------------------
Changes (by simonpj):
* status: new => merge
Comment:
OK, the commit that broke this was
{{{
commit 792449f555bb4dfa8e718079f6d42dc9babe938a
Author: Simon Peyton Jones <simo...@microsoft.com>
Date: Sat Jun 11 14:26:34 2011 +0100
Ignore UNPACK pragmas with OmitInterfacePragmas is on (fixes Trac
#5252)
The point here is that if a data type chooses a representation that
unpacks an argument field, the representation of the argument field
must be visible to clients. And it may not be if OmitInterfacePragmas
is on.
compiler/typecheck/TcTyClsDecls.lhs | 44
+++++++++++++++++------------------
1 file changed, 22 insertions(+), 22 deletions(-)
}}}
However, it was fixed on the HEAD by
{{{
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
}}}
(Confusingly the latter patch attributes the introduction of the bug to
the wrong patch.)
The basic solution is to apply the fix on the branch too. It may not
apply cleanly because there are some intermediate patches on HEAD, but I
think it should be obvious what to do. The important thing is that in
`tcConArg` we should see
{{{
; let strict_mark = chooseBoxingStrategy dflags arg_ty
(getBangStrictness bty)
}}}
or something like that, NOT `strict_mark <- chooseBoxingStrategy...`.
Ian, can you fix this up please? I'll add a test for HEAD.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7050#comment:2>
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
