public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations
Date: Thu, 12 Jan 2012 11:42:00 -0000 [thread overview]
Message-ID: <bug-51821-4-EdT8x3bDJU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-51821-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
--- Comment #14 from Uros Bizjak <ubizjak at gmail dot com> 2012-01-12 11:42:00 UTC ---
(In reply to comment #12)
> I'm not sure I understand. If the peephole matches, then the insn pattern is
> present in the insn stream with instantiated registers, so it's sufficient to
> scan the insn stream. AFAICS the code doesn't see that edx is live after the
> instruction because DF reports that only eax is; of course it's eax in DImode
> so edx is "implicitly" live, but it's nevertheless live.
A comment to "implicitly" live: my second example (Comment #9) marks ax
register as available, but IT IS SET in the pattern! This supports the theory
outlined in the Comment #13, but df_simulate_one_insn_forwards now marks unused
register ax as available. Again, live analysis is not the correct tool to
determine which registers are clobbered by the insn.
next prev parent reply other threads:[~2012-01-12 11:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 11:02 [Bug c/51821] New: " nos.utelsystems at gmail dot com
2012-01-11 11:21 ` [Bug c/51821] [4.5/4.6/4.7 Regression] " rguenth at gcc dot gnu.org
2012-01-11 11:28 ` [Bug target/51821] " rguenth at gcc dot gnu.org
2012-01-11 12:34 ` ubizjak at gmail dot com
2012-01-11 13:13 ` ubizjak at gmail dot com
2012-01-11 13:21 ` [Bug rtl-optimization/51821] " ubizjak at gmail dot com
2012-01-11 14:15 ` ubizjak at gmail dot com
2012-01-11 22:03 ` ebotcazou at gcc dot gnu.org
2012-01-11 22:35 ` ubizjak at gmail dot com
2012-01-11 22:57 ` ubizjak at gmail dot com
2012-01-12 7:44 ` ebotcazou at gcc dot gnu.org
2012-01-12 8:04 ` ubizjak at gmail dot com
2012-01-12 11:18 ` ebotcazou at gcc dot gnu.org
2012-01-12 11:35 ` ubizjak at gmail dot com
2012-01-12 11:42 ` ubizjak at gmail dot com [this message]
2012-01-12 13:20 ` ebotcazou at gcc dot gnu.org
2012-01-12 17:01 ` ubizjak at gmail dot com
2012-01-12 17:36 ` ubizjak at gmail dot com
2012-01-12 19:18 ` ubizjak at gmail dot com
2012-01-15 18:45 ` uros at gcc dot gnu.org
2012-01-15 20:02 ` uros at gcc dot gnu.org
2012-01-15 20:38 ` uros at gcc dot gnu.org
2012-01-15 21:01 ` uros at gcc dot gnu.org
2012-01-15 21:14 ` ubizjak at gmail dot com
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-51821-4-EdT8x3bDJU@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).