Opened 3 years ago

Closed 2 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 Revisions:

Description

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/build.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 ghc.mk phase=final all
"inplace/bin/ghc-stage1"   -H64m -O0 -fasm    -package-name base-4.6.0.0 -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-0.2.0.0 -package integer-gmp-0.3.0.0 -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):
	<<loop>>

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

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

Change History (3)

comment:1 Changed 2 years ago by igloo

  • difficulty set to Unknown

Paolo found this was a minimal testcase:

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

comment:2 Changed 2 years ago by simonpj

  • Status changed from new to merge

OK, the commit that broke this was

commit 792449f555bb4dfa8e718079f6d42dc9babe938a
Author: Simon Peyton Jones <[email protected]>
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 <[email protected]>
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

comment:3 Changed 2 years ago by igloo

  • Resolution set to fixed
  • Status changed from merge to closed

Merged

Note: See TracTickets for help on using tickets.