http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at redhat dot com
--- Comment #7 from vries at gcc dot gnu.org 2011-12-14 17:04:46 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > So my question is: what is the mechanism that should prevent epilogue insns
> > from being moved to before the epilogue?
>
> A full compiler barrier? See PR38644 for an epilogue scheduling bug on ARM
> Thumb-1 that got fixed by prefixing the epilogue with a barrier. That PR also
> refers to an older PowerPC bug that was fixed in a similar way.
Richard,
this tentative patch fixes both PR51471 and PR51271:
...
Index: src/gcc-mainline/gcc/config/mips/mips.c
===================================================================
--- src/gcc-mainline/gcc/config/mips/mips.c (revision 181878)
+++ src/gcc-mainline/gcc/config/mips/mips.c (working copy)
@@ -10400,6 +10400,9 @@ mips_expand_epilogue (bool sibcall_p)
return;
}
+ if (dwarf2out_do_frame ())
+ emit_insn (gen_blockage ());
+
/* In MIPS16 mode, if the return value should go into a floating-point
register, we need to call a helper routine to copy it over. */
if (mips16_cfun_returns_in_fpr_p ())
...
Is the proper way to fix these PRs?
Thanks,
- Tom
