Hi, this patch fixes PR50251, which was caused by r178353.
The patch was bootstrapped and reg-tested on i686 and x86_64. On i686, the test-cases reported failing in PR50251 pass again. The patch selects the DRAP type stack realignment method in case a stack_restore is used. If that is not done, the presence of the stack_restore at reload leaves FRAME_POINTER without an elimination rule for i386 port. OK for trunk? Thanks, - Tom 2011-09-03 Tom de Vries <t...@codesourcery.com> * explow.c (emit_stack_restore): Set crtl->need_drap if stack_restore is emitted.
Index: gcc/explow.c =================================================================== --- gcc/explow.c (revision 178145) +++ gcc/explow.c (working copy) @@ -1062,6 +1062,20 @@ emit_stack_restore (enum save_level save /* The default is that we use a move insn. */ rtx (*fcn) (rtx, rtx) = gen_move_insn; + /* If stack_realign_drap, the x86 backend emits a prologue that aligns both + STACK_POINTER and HARD_FRAME_POINTER. + If stack_realign_fp, the x86 backend emits a prologue that aligns only + STACK_POINTER. This renders the HARD_FRAME_POINTER unusable for accessing + aligned variables, which is reflected in ix86_can_eliminate. + We normally still have the realigned STACK_POINTER that we can use. + But if there is a stack restore still present at reload, it can trigger + mark_not_eliminable for the STACK_POINTER, leaving no way to eliminate + FRAME_POINTER into a hard reg. + To prevent this situation, we force need_drap if we emit a stack + restore. */ + if (SUPPORTS_STACK_ALIGNMENT) + crtl->need_drap = true; + /* See if this machine has anything special to do for this kind of save. */ switch (save_level) {