public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "zadeck at naturalbridge dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/33669] [4.3 Regression]  Revision 128957 miscompiles 481.wrf
Date: Wed, 10 Oct 2007 03:40:00 -0000	[thread overview]
Message-ID: <20071010033947.11523.qmail@sourceware.org> (raw)
In-Reply-To: <bug-33669-682@http.gcc.gnu.org/bugzilla/>



------- Comment #18 from zadeck at naturalbridge dot com  2007-10-10 03:39 -------
Subject: Re:  [4.3 Regression]  Revision 128957
 miscompiles 481.wrf

HJ,

Sorry about the committing snafu.  I should have posted the irc log of
seonbae's comments to the log for the bug.  Also I had a meeting in the
city tonight, so there was not time to commit it between when seonbae
gave the final approval and when i had to catch my train.

I have committed the corrected patch as revision 129193.  It looks like
you had left the testcase when you reverted so there is no test case in
this patch.

This patch was tested on ia-64, ppc-32, xa6-{64,32}.

Kenny

> This patch fixes pr33669 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33669>.
>
> The failure only happens if you have a block with 2 or more uses of a
> multiword pseudo register that is local to this block and has been
> allocated by local_alloc.  The uses must be in a particular form: the
> last use must be a subreg use that only used some of the hard registers and
> a previous non subreg use of the multiword register.
>
> When all of this happens, the code did not properly expand this to a
> whole multiregister when the second to last use is encountered in the
> backwards scan.
>
> I.e. a lot of things have to happen to get this to fail.
>
> I have tested this patch on ia-64, x86-{64,32} and ppc-32.
>



2007-10-07  Kenneth Zadeck <zadeck@naturalbridge.com>

    PR middle-end/33669
    * ra-conflict.c (record_one_conflict_between_regnos,
    set_conflicts_for_earlyclobber, global_conflicts): Improved logging.
    (global_conflicts): Enhanced incorrect check.


Index: ra-conflict.c
===================================================================
--- ra-conflict.c       (revision 129192)
+++ ra-conflict.c       (working copy)
@@ -196,7 +196,7 @@ record_one_conflict_between_regnos (enum
   int allocno2 = reg_allocno[r2];

   if (dump_file)
-    fprintf (dump_file, "  rocbr adding %d<=>%d\n", r1, r2);
+    fprintf (dump_file, "    rocbr adding %d<=>%d\n", r1, r2);

   if (allocno1 >= 0 && allocno2 >= 0)
     set_conflict (allocno1, allocno2);
@@ -401,9 +401,6 @@ set_conflicts_for_earlyclobber (rtx insn
                                                    recog_data.operand[use +
1]);
                }
        }
-
-  if (dump_file) 
-    fprintf (dump_file, "  finished early clobber conflicts.\n");
 }


@@ -983,12 +980,12 @@ global_conflicts (void)
                        set_renumbers_live (&renumbers_live, live_subregs,
live_subregs_used, 
                                            allocnum, renumber);
                    }
-                 
-                 else if (!sparseset_bit_p (allocnos_live, allocnum))
+                 else if (live_subregs_used[allocnum] > 0
+                          || !sparseset_bit_p (allocnos_live, allocnum))
                    {
                      if (dump_file)
-                       fprintf (dump_file, "    dying pseudo\n");
-                     
+                       fprintf (dump_file, "    %sdying pseudo\n", 
+                                (live_subregs_used[allocnum] > 0) ? "partially
": "");
                      /* Resetting the live_subregs_used is
                         effectively saying do not use the subregs
                         because we are reading the whole pseudo.  */
@@ -1071,6 +1068,8 @@ global_conflicts (void)
                 FIXME: We should consider either adding a new kind of
                 clobber, or adding a flag to the clobber distinguish
                 these two cases.  */
+             if (dump_file && VEC_length (df_ref_t, clobbers))
+               fprintf (dump_file, "  clobber conflicts\n");
              for (k = VEC_length (df_ref_t, clobbers) - 1; k >= 0; k--)
                {
                  struct df_ref *def = VEC_index (df_ref_t, clobbers, k);
@@ -1132,6 +1131,8 @@ global_conflicts (void)
              if (GET_CODE (PATTERN (insn)) == PARALLEL && multiple_sets
(insn))
                { 
                  int j;
+                 if (dump_file)
+                   fprintf (dump_file, "  multiple sets\n");
                  for (j = VEC_length (df_ref_t, dying_regs) - 1; j >= 0; j--)
                    {
                      int used_in_output = 0;
@@ -1166,7 +1167,7 @@ global_conflicts (void)
            }
        }

-           /* Add the renumbers live to the hard_regs_live for the next few
+      /* Add the renumbers live to the hard_regs_live for the next few
         calls.  All of this gets recomputed at the top of the loop so
         there is no harm.  */
       IOR_HARD_REG_SET (hard_regs_live, renumbers_live);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33669


  parent reply	other threads:[~2007-10-10  3:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-05 14:49 [Bug rtl-optimization/33669] New: " hjl at lucon dot org
2007-10-05 15:00 ` [Bug rtl-optimization/33669] " rguenth at gcc dot gnu dot org
2007-10-05 21:17 ` hjl at lucon dot org
2007-10-05 21:49 ` hjl at lucon dot org
2007-10-05 21:52 ` hjl at lucon dot org
2007-10-05 23:14 ` hjl at lucon dot org
2007-10-06  2:07 ` hjl at lucon dot org
2007-10-06  2:31 ` hjl at lucon dot org
2007-10-06  4:12 ` zadeck at naturalbridge dot com
2007-10-06 16:17 ` hjl at lucon dot org
2007-10-07  3:18 ` zadeck at naturalbridge dot com
2007-10-07  9:41 ` steven at gcc dot gnu dot org
2007-10-07 11:36 ` zadeck at naturalbridge dot com
2007-10-07 21:57 ` zadeck at naturalbridge dot com
2007-10-08  3:53 ` zadeck at naturalbridge dot com
2007-10-08 20:18 ` seongbae dot park at gmail dot com
2007-10-09 14:00 ` hjl at gcc dot gnu dot org
2007-10-09 15:33 ` zadeck at naturalbridge dot com
2007-10-09 15:41 ` zadeck at naturalbridge dot com
2007-10-09 16:19 ` hjl at lucon dot org
2007-10-10  3:33 ` zadeck at gcc dot gnu dot org
2007-10-10  3:40 ` zadeck at naturalbridge dot com [this message]
2007-10-10  3:41 ` zadeck at naturalbridge dot com
2007-10-10  3:47 ` hjl at lucon dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071010033947.11523.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).