------- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-24
01:08 -------
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.
try_optimize_cfg iteration 2
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 46 2 NOTE_INSN_FUNCTION_BEG)
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -28 [0xffffffe4])) [0 S4 A32])
(symbol_ref:SI ("__gxx_personality_sj0") [flags 0x43])) -1 (nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -24 [0xffffffe8])) [0 S4 A32])
(symbol_ref:SI ("*LLSDA0") [flags 0x2])) -1 (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -20 [0xffffffec])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 54 virtual-stack-vars)) -1 (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) -1 (insn_list:REG_LABEL_OPERAND 56 (nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) -1 (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) -1 (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -52 [0xffffffcc])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32])
(reg:SI 65)) -1 (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI ("_Unwind_SjLj_Register")
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
(call_insn 3 55 6 2 ./eh.C:4 (call (mem:QI (symbol_ref:SI ("__main") [flags
0x43]) [0 S1 A8])
(const_int 0 [0x0])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
Pass 133r.vregs turns this into:
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -28 [0xffffffe4])) [0 S4 A32])
(symbol_ref:SI ("__gxx_personality_sj0") [flags 0x43])) 41 {*movsi_1}
(nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -24 [0xffffffe8])) [0 S4 A32])
(symbol_ref:SI ("*LLSDA0") [flags 0x2])) 41 {*movsi_1} (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffffffec])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) 41 {*movsi_1} (insn_list:REG_LABEL_OPERAND 56
(nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) 41 {*movsi_1} (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) 41 {*movsi_1} (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 20 frame)
(const_int -52 [0xffffffcc])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 65)) 41 {*movsi_1} (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI ("_Unwind_SjLj_Register")
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) 466 {*call_0} (expr_list:REG_EH_REGION
(const_int 0 [0x0])
(nil))
(nil))
Note that insn 49 is the crucial one here that stores the (later miscalculated)
value of the frame pointer (i.e., $ebp - before elimination) into the jmp_buf.
At pass 174r.ira, this becomes:
(insn 48 47 73 2 (parallel [
(set (reg/f:SI 0 ax [63])
(plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (expr_list:REG_EQUIV (plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c]))
(nil)))
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
And this is the point at which the incorrect offset first appears.
Ouch. I hope this isn't an IRA bug, I know nothing about that. Is it valid to
do frame pointer elimination before reload like that? Because the other
possibility is that the x86 backend is suddenly growing the frame size during
some later pass. (Well, I guess we *know* that has to be happening, the
question is whether it's allowed to or not. I think it's allowed to change its
mind any time while the middle end is still trying combines and splits and
repeatedly re-layouting the stack and calling INITIAL_FRAME_POINTER_OFFSET over
and again, and I know it's not allowed once we're in strict after reload, but I
don't know when exactly it gets crystallized).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
