------- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-01 00:17 -------
In the faulty case, stack protector inserts PIC codes after the result
is set to R0 register. It looks like
rX = [EMAIL PROTECTED]
A = rX + r12
B = mem[A]
and combine optimization pass makes this turn into
rX = [EMAIL PROTECTED]
B = mem[rX + r12]
Unfortunately, the last insn requires R0 which is already used and we
see the famous R0 spill failure. We didn't get this error on SH4 with
-O2 because the first insn scheduling and other optimizations move
the insn which set the result to R0 after these protector codes.
But it looks to be fragile even on SH4 -O2. I'm testing the patch
below on the trunk.
* config/sh/sh.md (symGOT_load): Don't schedule insns when
the symbol is generated with the stack protector.
--- ORIG/trunk/gcc/config/sh/sh.md 2007-04-27 21:30:47.000000000 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.md 2007-06-01 08:21:18.000000000 +0900
@@ -8502,6 +8502,20 @@ label:
operands[2],
gen_rtx_REG (Pmode, PIC_REG)));
+ /* When stack protector inserts codes after the result is set to
+ R0, @(rX, r12) will cause a spill failure for R0. Don't schedule
+ insns to avoid combining (set A (plus rX r12)) and (set op0 (mem A))
+ when rX is a GOT address for the guard symbol. Ugly but doesn't
+ matter because this is a rare situation. */
+ if (!TARGET_SHMEDIA
+ && flag_stack_protect
+ && GET_CODE (operands[1]) == CONST
+ && GET_CODE (XEXP (operands[1], 0)) == UNSPEC
+ && GET_CODE (XVECEXP (XEXP (operands[1], 0), 0, 0)) == SYMBOL_REF
+ && strcmp (XSTR (XVECEXP (XEXP (operands[1], 0), 0, 0), 0),
+ \"__stack_chk_guard\") == 0)
+ emit_insn (gen_blockage ());
+
/* N.B. This is not constant for a GOTPLT relocation. */
mem = gen_rtx_MEM (Pmode, operands[3]);
MEM_NOTRAP_P (mem) = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
