[Bug c/77904] New: [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

["freddie_chopin at op dot pl" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 77904
           Summary: [ARM Cortex-M0] Frame pointer thrashes registers if
                    assembly statements with "sp" clobber are used
           Product: gcc
           Version: 6.2.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
            Target: arm-none-eabi

In some very specific cases frame pointer can thrash caller's r7 (frame
pointer) register. The following test case demonstrates the problem.

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

$ cat test.cpp 
void removeStackFrame(const void* const savedStackPointer)
{
  __asm volatile ("MSR psp, %0\n" : : "r" (savedStackPointer) : "sp");
}
$ arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -O2 test.cpp -c
$ arm-none-eabi-objdump -S test.o 

test.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_Z16removeStackFramePKv>:
   0:   af00            add     r7, sp, #0
   2:   f380 8809       msr     PSP, r0
   6:   46bd            mov     sp, r7
   8:   4770            bx      lr
   a:   46c0            nop                     ; (mov r8, r8)

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

As you can see in this particular function the frame pointer thrashes caller's
r7, which should be saved on stack and restored before returning. In this test
case this seems to be caused by the "sp" clobber in the assembly statement
(this particular line comes from CMSIS headers for ARM Cortex-M
microcontrollers) - if I remove this clobber, then the frame pointer is omitted
and the problem is gone, but this can hardly be considered a solution...

This is somehow specific only to ARM Cortex-M0 - selecting ARM Cortex-M4
("-mcpu=cortex-m4") causes r7 to be pushed to the stack.

This is not related to optimization level, as the same behaviour can be
observed on all optimization levels.

Using "-fomit-frame-pointer" doesn't change anything, but doing the opposite
"-fno-omit-frame-pointer" - causes r7 to be stacked.

This problem was not present on GCC 5.3.1 (at least on the version with ARM
patches) - with that version the frame pointer was omitted. Currently I'm
observing this problem on almost clean GCC 6.2.0 - the only change is the
multilib configuration.