Opened 5 years ago

Closed 4 years ago

#7050 closed bug (fixed)

stage 1 compiler crashes when the "quickest" build flavour is chosen

Reported by: ilya Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.5
Keywords: Cc:
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


A fresh build from scratch of the "master" branch from the GHC repository runs into the following problem if the build flavour is set to "quickest" in mk/ file:

BuildFlavour = quickest

The compiler successfully passes stage 0 and the last lines of stage 1 (run with verbosity level V=1) look as follows:

make -r --no-print-directory -f phase=final all
"inplace/bin/ghc-stage1"   -H64m -O0 -fasm    -package-name base- -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim- -package integer-gmp- -package rts-1.0  -package-name base -XHaskell98 -XCPP -O0 -fasm  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/base/./Control/Concurrent/Chan.hs -o libraries/base/dist-install/build/Control/Concurrent/Chan.o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.5.20120704 for x86_64-apple-darwin):

Please report this as a GHC bug:

make[1]: *** [libraries/base/dist-install/build/Control/Concurrent/Chan.o] Error 1
make: *** [all] Error 2

Change History (3)

comment:1 Changed 4 years ago by igloo

difficulty: Unknown

Paolo found this was a minimal testcase:

data Foo a = Foo {-# UNPACK #-} !(Foo a)

comment:2 Changed 4 years ago by simonpj

Status: newmerge

OK, the commit that broke this was

commit 792449f555bb4dfa8e718079f6d42dc9babe938a
Author: Simon Peyton Jones <>
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 <>
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.


comment:3 Changed 4 years ago by igloo

Resolution: fixed
Status: mergeclosed


Note: See TracTickets for help on using tickets.