[GHC] #12562: GHC panic on rebuild (idInfo r_XsTP)

[GHC]

#12562: GHC panic on rebuild (idInfo r_XsTP)
-------------------------------------+-------------------------------------
        Reporter:  cocreature        |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by cocreature):

 * owner:  cocreature =>


@@ -1,4 +1,0 @@
- First of all let me apologize for the terrible testcase. I tried to find a
- smaller one (and am still trying) but haven’t managed to do so. The good
- news is that at least for me it’s reproducible
-
@@ -8,2 +4,1 @@
- -- Install llvm-3.8
- git clone 'https://github.com/bscarlet/llvm-general.git' -b llvm-3.8
+ git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic

New description:

 === Steps to reproduce ===

 {{{
 git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic
 cd llvm-general
 cabal new-build llvm-general
 curl -s
 https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch
 > out.patch
 git apply out.patch
 cabal new-build llvm-general
 }}}

 The patch just adds a newline somewhere to create a rebuild. I’ve seen
 this panic for completely different changes (all in this project) so I
 don’t think the change matters. I’ve also seen this panic with stack,
 cabal new-build and cabal build (using sandboxes).

 === Output ===

 {{{
 In order, the following will be built (use -v for more details):
 llvm-general-3.8.0.0
 Preprocessing library llvm-general-3.8.0.0...
 [84 of 92] Compiling LLVM.General.Internal.Module (
 src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist-
 newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o )
 [85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs,
 /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-
 general-3.8.0.0/build/LLVM/General/Module.o )
 [LLVM.General.Internal.Module changed]
 [89 of 92] Compiling LLVM.General.Internal.PassManager (
 src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general
 /dist-newstyle/build/llvm-
 general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH]
 ghc: panic! (the 'impossible' happened)
   (GHC version 8.0.1 for x86_64-unknown-linux):
         idInfo r_XsTP

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

 === Comments ===

 In this case this can be resolved by running cabal new-build again.
 However I’ve also had cases where this didn’t fix it and I had to blow
 away dist-newstyle. I haven’t yet managed to find a reproducible testcase
 for the latter. Matthew Pickering mentioned that he encountered this (or a
 similar) bug while building GHC. I tried core-lint but that didn’t help.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12562#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler