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
next prev 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: linkBe 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).