Here's some more debug output. Can someone interpret it: genRaInsn cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4) r_dying = [%vI_n1nD, %vI_n1nE, %vI_n1nF] w_dying = [] virt_read = [%vI_n1nD, %vI_n1nE, %vI_n1nF] virt_written = [] freeregs = FreeRegs 4282318848 assig = [n1nD :-> InMem 0, n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg (RealRegSingle 3)] ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 (i.e. it's the cmpxchg instruction which is causing the failure.) On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell <johan.tib...@gmail.com> wrote: > I'm trying to understand the output from the register allocator: > > (GHC version 7.9.20140626 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1nD > assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle > 2)),(n1nF,InReg (RealRegSingle 3))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Without understanding exactly what's wrong, the message above suggests > that we're trying to allocate a reg for n1nD, but there's already an > assignment for that virtual reg, is that right? > > > > On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell <johan.tib...@gmail.com> > wrote: > >> Herbert pushed my revert for me a minute ago. Everyone should be good >> once they sync. >> >> >> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell <johan.tib...@gmail.com> >> wrote: >> >>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which >>> I pushed this morning) which is fine. You should be in a good state now >>> when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. >>> >>> >>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones < >>> simo...@microsoft.com> wrote: >>> >>>> git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> >>>> [master f958079] Revert "Add more primops for atomic ops on byte arrays" >>>> >>>> 23 files changed, 86 insertions(+), 1016 deletions(-) >>>> >>>> rewrite compiler/nativeGen/CPrim.hs (62%) >>>> >>>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c >>>> >>>> delete mode 100644 >>>> testsuite/tests/concurrent/should_run/AtomicPrimops.hs >>>> >>>> delete mode 100644 >>>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout >>>> >>>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>>> >>>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>>> >>>> HEAD $ >>>> >>>> What now? >>>> >>>> Simon >>>> >>>> >>>> >>>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com] >>>> *Sent:* 26 June 2014 13:25 >>>> *To:* Simon Peyton Jones >>>> *Cc:* Karel Gardas; ghc-devs >>>> *Subject:* Re: Two days old build breakage on i386. >>>> >>>> >>>> >>>> Just to make sure this is the same breakage, are you on an i386 Windows >>>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. >>>> >>>> >>>> >>>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones < >>>> simo...@microsoft.com> wrote: >>>> >>>> Aaaargh! Once again the Windows build is broken. I am utterly >>>> stalled. >>>> >>>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. >>>> At least they should elicit warnings saying that they are disabled pending >>>> the fix to X and Y. >>>> >>>> Please can someone bisect to find out which patch is the culprit? >>>> >>>> I wish we had a more systematic way to find this out. I hate being the >>>> main person who gets stuck because some unrelated change has broken the >>>> Windows build. (Thanks for Karel, who got to it a day before me.) >>>> >>>> Thanks >>>> >>>> Simon >>>> >>>> >>>> | -----Original Message----- >>>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of >>>> Karel >>>> | Gardas >>>> | Sent: 26 June 2014 09:56 >>>> | To: ghc-devs; Johan Tibell >>>> | Subject: Two days old build breakage on i386. >>>> | >>>> | >>>> | Hello, >>>> | >>>> | builders running on i386 building for this platform caught issue which >>>> | shows as a build breakage: >>>> | >>>> | ghc-stage1: panic! (the 'impossible' happened) >>>> | (GHC version 7.9.20140624 for i386-unknown-linux): >>>> | RegAllocLinear.allocRegsAndSpill: no spill candidates >>>> | allocating vreg: VirtualRegI n1Q6 >>>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) >>>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >>>> | freeRegs: FreeRegs 4282318848 >>>> | initFreeRegs: FreeRegs 4282318861 >>>> | Please report this as a GHC bug: >>>> http://www.haskell.org/ghc/reportabug >>>> | make[1]: *** >>>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 >>>> | libraries/ghc-prim/ghc.mk:4: recipe for target >>>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed >>>> | >>>> | Have a look for example on linux-i386 buildot log here: >>>> | >>>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >>>> | >>>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 >>>> so >>>> | it's OS independent and probably 32bit/i386 platform specific and it's >>>> | two days old breakage now. The last two night builds fail on all >>>> | mentioned buildbots. I'm not sure but perhaps: >>>> | >>>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> | Author: Johan Tibell <johan.tib...@gmail.com> >>>> | Date: Mon Jun 9 11:43:21 2014 +0200 >>>> | >>>> | triggers that issue? I'm not claiming that the commit is actual >>>> culprit, >>>> | this may be just recently un-hidden issue in linear regs allocator on >>>> | i386! >>>> | >>>> | Thanks! >>>> | Karel >>>> >>>> | _______________________________________________ >>>> | ghc-devs mailing list >>>> | ghc-devs@haskell.org >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>> >>> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs