[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

["vries at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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