[Bug rtl-optimization/54540] New: [4.8 regression] postreload incorrectly simplifies stack adjustment into constant load into SP

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54540

             Bug #: 54540
           Summary: [4.8 regression] postreload incorrectly simplifies
                    stack adjustment into constant load into SP
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: rearn...@gcc.gnu.org
            Target: arm-linux-gnueabi


This is probably a latent bug that has been exposed by a recent change to the
ARM back-end.

In the testcase, when compiled with:

/work/rearnsha/scratch/gnu/gcc/trunk/gcc/cc1plus default.ii -O2 -mcpu=cortex-a9
-mthumb --std=c++11

For the function

_Z8run_testIN9__gnu_cxx33simd_fast_mersenne_twister_engineIjLj132049ELj110ELj19E
Lj1ELj21ELj1ELj4294949727ELj4218339221ELj4294901754ELj3489103871ELj1ELj0ELj34111
48800ELj3353943165EEEEvSt16initializer_listINT_11result_typeEE

the stack pointer adjustment in the prologue ends up being optimized into 

  ldr  sp, [pc, #offs]  

which is a load from the constant pool.

After register allocation we have:

    2 r151:SI=sp:SI-0x4080
    3 sp:SI=r151:SI-0x20
      REG_DEAD: r151:SI
      REG_EQUAL: sp:SI-0x40a0
    5 r152:SI=sp:SI+0xf

However, a reload is needed and the reload pass generates

    2 r3:SI=sp:SI-0x4080
  205 sp:SI=0xffffffffffffffe0
    3 sp:SI=sp:SI+r3:SI
      REG_EQUAL: sp:SI-0x40a0
    5 r8:SI=sp:SI+0xf

Note that insn 3 still has a note that describes the result as being an
adjustment to SP.

Postreload somehow then converts this into 

    2 r3:SI=sp:SI-0x4080
  205 sp:SI=0xffffffffffffffef
    5 r8:SI=sp:SI+r3:SI

Which of course is not at all the same result.

There are two issues going on here:

One, reload is using SP as a scratch register.  This violates stack integrity
rules.  If an interrupt or signal occurred while SP was invalid the program
would probably crash.  This is a reload bug.

Two, SP is never correctly updated to the final value, which means that the
code crashes at run time.  This may also be a reload bug, but it might also be
a post-reload one (or both).