[Bug target/77570] New: [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration

[oarias at knights dot ucf.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570

            Bug ID: 77570
           Summary: [msp430-elf] Wrong assembly in delay_cycles_32x insn
                    declaration
           Product: gcc
           Version: 6.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: oarias at knights dot ucf.edu
  Target Milestone: ---

Created attachment 39607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39607&action=edit
Patch which fixes the assembly issued by the delay_cycles_32x insn.

Greetings,

We ran into a bug this weekend and traced it back to the following. The delay
loop insn for loops with 32bit constants currently does the following:

(define_insn "delay_cycles_32x"
  [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
                     (match_operand 1 "immediate_operand" "i")
                     ] UNS_DELAY_32X)]
  ""
  "PUSHM.A      #2,r13
        MOV.W   %A0, r13
        MOV.W   %B0, r14
1:      SUB.W   #1, r13
        SUBC.W  #0, r14
        JNE     1b
        TST.W   r13
        JNE     1b
        POPM.A  #2,r13"
  )

The assembly issued by this insn is not correct. According to the CPUX
description of the pushm and popm instructions, the list of registers saved is
from n-1 to the listed register in the instruction. As such,

pushm.a #2, r13 ; saves r12 and r13 in the stack, and
popm.a #2, r13 ; restores r12 and r13 from the stack

However, in this loop, the compiler uses r13 and r14 as temporaries. However,
it does not save r14 into the stack, corrupting its value. The attached patch
fixes the insn. I have not checked whether a similar situation happens
somewhere else in the msp430-elf backend. Thank you.

Cheers,
Orlando.