[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

--- Comment #13 from vries at gcc dot gnu.org 2011-12-19 13:23:41 UTC ---
(In reply to comment #11)
> This is the patch which I am testing:
> Index: genattrtab.c
> ===================================================================
> --- genattrtab.c        (revision 182342)
> +++ genattrtab.c        (working copy)
> @@ -4280,6 +4280,11 @@ write_eligible_delay (const char *kind)
>    printf ("  if (!INSN_P (candidate_insn))\n");
>    printf ("    return 0;\n");
>    printf ("\n");
> +  /* Frame related instructions are hard to put in the delay slot for
> +     debugging info reasons. */
> +  printf ("  if (RTX_FRAME_RELATED_P (candidate_insn))\n");
> +  printf ("    return 0;\n");
> +  printf ("\n");
> 
>    /* If more than one delay type, find out which type the delay insn is.  */

What is the exact reason we're completely avoiding scheduling frame-related
insns in delay slots? Why don't we try to fix it like this?:
...
Index: src/gcc-mainline/gcc/reorg.c
===================================================================
--- src/gcc-mainline/gcc/reorg.c (revision 182341)
+++ src/gcc-mainline/gcc/reorg.c (working copy)
@@ -2716,7 +2716,7 @@ fill_slots_from_thread (rtx insn, rtx co
       if (!must_annul
           && (condition == const_true_rtx
               || (! insn_sets_resource_p (trial, &opposite_needed, true)
-              && ! may_trap_or_fault_p (pat))))
+              && ! may_trap_or_fault_p (pat) && !RTX_FRAME_RELATED_P
(trial))))
         {
           old_trial = trial;
           trial = try_split (pat, trial, 0);
...
AFAIU, the only thing causing problems is frame-related insns being speculated.