[Bug target/64533] New: [5 Regression] [SH] alloca generates unsafe code

[kkojima at gcc dot gnu.org]

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

            Bug ID: 64533
           Summary: [5 Regression] [SH] alloca generates unsafe code
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kkojima at gcc dot gnu.org
            Target: sh*-*-*

The trunk compiler compiles

  void *foo() { return alloca (0x400);}

to

foo:
        mov.l   r14,@-r15
        mov     r15,r1
        mov     r15,r14
        mov.w   .L2,r15        (*)
        add     r1,r15
        mov     r15,r0
        mov     r14,r15
        rts
        mov.l   @r15+,r14
        .align 1
.L2:
        .short  -1028

with -O2.
r15 has been set -1028 at (*) which isn't always safe.  For example
sh-linux uses the negative stack values for software roll-back and
I've got a few sporadic and unreproducible errors on libjava testsuite
because of this.  I've introduced a splitter which splits rA := rB + N
to rA := N and rA := rA + rB for LRA's register elimination phase.
It should take rA=r15 case into account.  I'm testing the patch below.

--- config/sh/sh.md
+++ config/sh/sh.md
@@ -2061,9 +2061,10 @@
 ;; The problem is that LRA expects something like
 ;;    (set rA (plus rB (const_int N)))
 ;; to work.  We can do that, but we have to split out an additional reg-reg
-;; copy before the actual add insn.
+;; copy before the actual add insn.  Use u constraint for that case to avoid
+;; the invalid value in the stack pointer.
 (define_insn_and_split "*addsi3_compact"
-  [(set (match_operand:SI 0 "arith_reg_dest" "=r,&r")
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r,&u")
     (plus:SI (match_operand:SI 1 "arith_operand" "%0,r")
          (match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))]
   "TARGET_SH1