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
