public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aoliva at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/41353] VTA missed-debug issues
Date: Tue, 06 Oct 2009 06:06:00 -0000	[thread overview]
Message-ID: <20091006060556.1612.qmail@sourceware.org> (raw)
In-Reply-To: <bug-41353-87@http.gcc.gnu.org/bugzilla/>



------- Comment #14 from aoliva at gcc dot gnu dot org  2009-10-06 06:05 -------
The patch that introduces debug temps fixes the problem in #c9.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html

As for the testcase in #c10, the behavior is correct.  If the pseudo holding a
value becomes dead at a certain point, we shouldn't reference the dead value in
subsequent debug insns because, well, it is dead.  Trying to keep it alive
would do us no good: it would likely cause codegen differences.

Now...  Maybe we could make room for finding the value in alternate locations,
adding a debug temp insn right before the death of the pseudo, and referencing
the debug temp instead of the pseudo itself.  This wouldn't help if it's the
only location known to hold the value, and that location gets actually
clobbered afterwards, say if a register gets reused.  We might end up with lots
of useless debug stmts.  However, if the value survives, or is found at an
equivalent location, we might still represent it, but should we?  If we found
the value to be dead, wouldn't it be more accurate to say so?


-- 


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


  parent reply	other threads:[~2009-10-06  6:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14  7:53 [Bug debug/41353] New: " jakub at gcc dot gnu dot org
2009-09-14  8:19 ` [Bug debug/41353] " jakub at gcc dot gnu dot org
2009-09-14  9:15 ` jakub at gcc dot gnu dot org
2009-09-14 10:09 ` rguenth at gcc dot gnu dot org
2009-09-14 17:36 ` jakub at gcc dot gnu dot org
2009-09-15 13:45 ` jakub at gcc dot gnu dot org
2009-09-16 11:49 ` jakub at gcc dot gnu dot org
2009-09-16 11:53 ` jakub at gcc dot gnu dot org
2009-09-16 16:42 ` jakub at gcc dot gnu dot org
2009-09-16 16:43 ` jakub at gcc dot gnu dot org
2009-09-16 17:17 ` jakub at gcc dot gnu dot org
2009-09-16 17:20 ` jakub at gcc dot gnu dot org
2009-09-21 18:32 ` jakub at gcc dot gnu dot org
2009-09-23 16:31 ` aoliva at gcc dot gnu dot org
2009-10-02 15:02 ` jakub at gcc dot gnu dot org
2009-10-06  6:06 ` aoliva at gcc dot gnu dot org [this message]
2009-10-06  6:10 ` aoliva at gcc dot gnu dot org
2009-10-06  7:53 ` aoliva at gcc dot gnu dot org
2009-10-08 19:20 ` aoliva at gcc dot gnu dot org
2009-10-08 19:22 ` aoliva at gcc dot gnu 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=20091006060556.1612.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).