Hi all,
re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW]
I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut
right to the chase, the RTL generated by the 130r.eh pass to save %ebp (the
frame pointer) into the jmp_buf struct embedded in the SjLj_Function_Context
struct that is about to be registered looks like so:
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 54 virtual-stack-vars)) -1 (nil))
Pass 133r.vregs turns it into:
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
Then it isn't touched again until pass 174.ira, which replaces it by:
(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))
That is to say, it has performed frame-pointer elimination and replaced the
reference to the fp by a constant offset from the %esp. However, the offset
here is wrong; at least by the time we get to the final generated assembly,
the stack frame size is 0x60 bytes.
So, the question is: Is it valid for IRA to be doing this pre-reload? I
thought stack layout wasn't necessarily congealed until we enter strict mode,
but I could be wrong and/or IRA could have a "special understanding" with
reload about this. The other possibility is that the x86 backend is bogusly
growing the stack frame allocation at a later stage than it's allowed to;
perhaps something to do with stack alignment, which I haven't been following
but I see there were a whole bunch of new testcases added a while ago?[*]
cheers,
DaveK
[ NB. Gotta go AFK for a couple of hours now and get something to eat, so
won't be able to respond to any replies immediately; will check back later. ]
--
[*] - See PR38949, but note that of the new tests, the ones which /don't/
experience the link failure mentioned there all fail at runtime.
