I've committed the attached patch to fix PR target/64533 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64533 which is a 5.0 regression. Splitting rA := rB + N to rA := N and rA := rA + rB isn't safe when rA is the stack pointer. If someone interrupts between these 2 set insns, we could see a bad value in the stack pointer. I've got a few sporadic and unreproducible errors in libjava testsuite on sh-linux because of this. The attached one liner is to avoid that splitting when rA is the stack pointer. Tested on sh4-unknown-linux-gnu with no new failures.
Regards, kaz -- 2015-01-08 Kaz Kojima <kkoj...@gcc.gnu.org> PR target/64533 * config/sh/sh.md (*addsi3_compact): Use u constraint instead of r for the second alternative of the destination operand. diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index 37d2a20..6e0b97f 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/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