public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66334] cleanup block fails to initialize EBX
Date: Tue, 07 Jul 2015 19:35:00 -0000	[thread overview]
Message-ID: <bug-66334-4-3kDon2NkSu@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-66334-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66334

--- Comment #11 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #10)
> (In reply to Vladimir Makarov from comment #9)
> > 
> > I will work on the patch and commit it on next week.
> > 
> > Thanks.
> 
> I tried this patch:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;
> h=ab377c74f283f3db51b4e250b9c7acecc32e8ff8
> 
> It seems to work.

Thanks, H.J.  Your patch fixes given problem but I'd like to play more safe. 
May be there are some analogous situations with explicit ebx setting.

So I am going to submit the following patch today or tomorrow.

Index: ChangeLog
===================================================================
--- ChangeLog   (revision 225200)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2015-07-06  Vladimir Makarov  <vmakarov@redhat.com>
+
+       PR middle-end/66334
+       * ira-lives.c (process_bb_node_lives): Make conflicts with PIC
+       hard regno live at the start of BB with incoming abnormal edges.
+       * lra-lives.c (process_bb_lives): Ditto.
+
 2015-06-30  Vladimir Makarov  <vmakarov@redhat.com>

        PR debug/66691
Index: ira-lives.c
===================================================================
--- ira-lives.c (revision 225134)
+++ ira-lives.c (working copy)
@@ -1346,7 +1346,21 @@ process_bb_node_lives (ira_loop_tree_nod
             allocate such regs in this case.  */
          if (!cfun->has_nonlocal_label && bb_has_abnormal_call_pred (bb))
            for (px = 0; px < FIRST_PSEUDO_REGISTER; px++)
-             if (call_used_regs[px])
+             if (call_used_regs[px]
+#ifdef REAL_PIC_OFFSET_TABLE_REGNUM
+                 /* We should create a conflict of PIC pseudo with
+                    PIC hard reg as PIC hard reg can have a wrong
+                    value after jump described by the abnormal edge.
+                    In this case we can not allocate PIC hard reg to
+                    PIC pseudo as PIC pseudo will also have a wrong
+                    value.  This code is not critical as LRA can fix
+                    it but it is better to have the right allocation
+                    earlier.  */
+                 || (px == REAL_PIC_OFFSET_TABLE_REGNUM
+                     && pic_offset_table_rtx != NULL_RTX
+                     && REGNO (pic_offset_table_rtx) >= FIRST_PSEUDO_REGISTER)
+#endif
+                 )
                make_hard_regno_born (px);
        }

Index: lra-lives.c
===================================================================
--- lra-lives.c (revision 225200)
+++ lra-lives.c (working copy)
@@ -957,7 +957,18 @@ process_bb_lives (basic_block bb, int &c
         allocate such regs in this case.  */
       if (!cfun->has_nonlocal_label && bb_has_abnormal_call_pred (bb))
        for (px = 0; px < FIRST_PSEUDO_REGISTER; px++)
-         if (call_used_regs[px])
+         if (call_used_regs[px]
+#ifdef REAL_PIC_OFFSET_TABLE_REGNUM
+             /* We should create a conflict of PIC pseudo with PIC
+                hard reg as PIC hard reg can have a wrong value after
+                jump described by the abnormal edge.  In this case we
+                can not allocate PIC hard reg to PIC pseudo as PIC
+                pseudo will also have a wrong value.  */
+             || (px == REAL_PIC_OFFSET_TABLE_REGNUM
+                 && pic_offset_table_rtx != NULL_RTX
+                 && REGNO (pic_offset_table_rtx) >= FIRST_PSEUDO_REGISTER)
+#endif
+             )
            make_hard_regno_born (px, false);
     }


  parent reply	other threads:[~2015-07-07 19:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  2:50 [Bug middle-end/66334] New: " hjl.tools at gmail dot com
2015-05-29  2:56 ` [Bug middle-end/66334] " hjl.tools at gmail dot com
2015-05-29 20:37 ` hjl.tools at gmail dot com
2015-05-29 21:54 ` hjl.tools at gmail dot com
2015-05-29 21:55 ` hjl.tools at gmail dot com
2015-05-31 13:16 ` hjl.tools at gmail dot com
2015-06-01 14:21 ` hjl.tools at gmail dot com
2015-07-03 17:25 ` vmakarov at gcc dot gnu.org
2015-07-03 18:42 ` hjl.tools at gmail dot com
2015-07-03 21:04 ` vmakarov at gcc dot gnu.org
2015-07-04 13:57 ` hjl.tools at gmail dot com
2015-07-07 19:35 ` vmakarov at gcc dot gnu.org [this message]
2015-07-08 15:05 ` vmakarov at gcc dot gnu.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=bug-66334-4-3kDon2NkSu@http.gcc.gnu.org/bugzilla/ \
    --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).