[Bug rtl-optimization/107248] New: Sparc V8 Invalid Stack Pointer Code

[dennis.borde at ohb dot de]

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

            Bug ID: 107248
           Summary: Sparc V8 Invalid Stack Pointer Code
           Product: gcc
           Version: 7.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dennis.borde at ohb dot de
  Target Milestone: ---

Created attachment 53700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53700&action=edit
source code to trigger the bug

Environment: GCC V7.1.0, Sparc V8, RTEMS V4.8.0

When compiling with optimization level -O2 (including -fschedule-insns2) the
compiler generates code like this:

(1) add %sp, 0x50, %g1
(2) add %sp, 0x50, %sp
(3) add %g1, %o0, %o0
(4) ld [ %o0 + -8 ], %o0

In line (2) the stack pointer is moved by 80 bytes forward, which means memory
is "freed".
In line (4) it accesses the "freed" stack memory.

When an interrupt occurs in between line (2) and (4) it will overwrite the
stack data and "corrupt" it for the reading in line (4).

E.g.: As part of the RTEMS _ISR_Handler() the interrupt stack frame is stored
(see label symbol save_isf). For more information see RTEMS source code.
However, this is just one example to show the order of instructions above is
not safe. It is not important for the bug itself.

Work-around: Compile with -fno-schedule-insns2

With the work-around the generated code looks like this:
(1) add %sp, 0x50, %g1
(2) add %g1, %o0, %o0
(3) ld [ %o0 + -8 ], %o0
(4) add %sp, 0x50, %sp 

Here the stack memory is "freed" (4) after the access (3).

It seems to be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644