[GHC] #4368: T4144(dyn) failing on x86/Linux

[GHC]

#4368: T4144(dyn) failing on x86/Linux
-------------------------------+--------------------------------------------
    Reporter:  simonmar        |        Owner:  benl         
        Type:  bug             |       Status:  new          
    Priority:  highest         |    Milestone:  7.0.1        
   Component:  Compiler (NCG)  |      Version:  6.13         
    Keywords:                  |     Testcase:               
   Blockedby:                  |   Difficulty:               
          Os:  Linux           |     Blocking:               
Architecture:  x86             |      Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by benl):

 Yes, the spill cleaner has messed up because it's not tracking slot usage
 across jumps properly. Here is the code before cleaning:

 {{{
 c5Xy:
                 call 1f
              1: popl    %eax
                 addl    $_GLOBAL_OFFSET_TABLE_+(.-1b), %eax
                      # born:    %r0

                 SPILL %r0,SLOT(0)
                      # r_dying: %r0

                 cmpl $0,3(%esi)

                 jne .Lc5XA

                 RELOAD SLOT(0),%r0
                      # born:    %r0

                 addl $r3k3_closure at gotoff,%eax

                 SPILL %r0,SLOT(0)
                      # r_dying: %r0

                 RELOAD SLOT(0),%r0
                      # born:    %r0

                 leal 1(%eax),%esi
                      # r_dying: %r0

                 addl $80,%ebp

                 jmp *0(%ebp)

          c5XA:
 ....
                 RELOAD SLOT(0),%r0
                      # born:    %r0

                 movl dirty_MUT_VAR at got(%eax),%eax
                      # born:    %r0
                      # r_dying: %r0


 }}}

 In this code {{{%r0}}} is really {{{%eax}}}.

 The cleaner has erased the first RELOAD instruction because %eax isn't
 written to between it's initialisation (by popl) and that RELOAD. The
 cleaner has then erased the first SPILL instruction because it doesn't
 know that block {{{c5XA}}} also reloads from it. The fact that other
 programs work with this bug in place shows how regular GHC generated code
 is.

 It should be easy to fix by tracking what slots are live across jumps as
 well as what vregs are live. I'm working on it..

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