public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
Date: Thu, 07 Feb 2013 20:05:00 -0000	[thread overview]
Message-ID: <bug-53948-4-U9taimQtmL@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53948-4@http.gcc.gnu.org/bugzilla/>


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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
         AssignedTo|steven at gcc dot gnu.org   |law at gcc dot gnu.org

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> 2013-02-07 20:04:00 UTC ---
So, the real problem here is that replacing

VAR_OR_FUNCTION_DECL_P && ! DECL_ARTIFICAL

with REG_USERVAR_P

is not the same.  In particular the former is _false_ for parameters and the
latter is true.  c#3 is totally wrong, parameters are marked with
REG_USERVAR_P.

The real way to get the prior behaviour without reverting the patch is to
either explicitly mark parameters so we can check for them in this one hunk of
code.  Or to create a helper function in a suitable location that can map from
a reg to its decl, then check if it's a parameter.  Given that flags in the
main rtl structures are generally scarce, I think the latter is a better
solution given how rarely we need to make this distinction.

It's unfortunate that this P1 regression was left languishing, half analyzed in
our tree for 6+ months ;(


  parent reply	other threads:[~2013-02-07 20:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13  8:51 [Bug debug/53948] New: " jan.kratochvil at redhat dot com
2012-07-13  9:12 ` [Bug debug/53948] " rguenth at gcc dot gnu.org
2012-07-16 19:37 ` jakub at gcc dot gnu.org
2012-07-16 19:49 ` steven at gcc dot gnu.org
2012-07-16 20:23 ` steven at gcc dot gnu.org
2012-07-16 21:58 ` steven at gcc dot gnu.org
2012-09-19 13:45 ` rguenth at gcc dot gnu.org
2013-02-07 20:05 ` law at redhat dot com [this message]
2013-02-07 20:24 ` stevenb.gcc at gmail dot com
2013-02-07 20:41 ` jakub at gcc dot gnu.org
2013-02-07 20:47 ` law at redhat dot com
2013-02-08  8:28 ` rguenth at gcc dot gnu.org
2013-02-08 13:20 ` law at redhat dot com
2013-02-08 13:46 ` jakub at gcc dot gnu.org
2013-02-08 20:04 ` law at gcc dot gnu.org
2013-02-08 20:05 ` law at redhat dot com
2013-02-08 20:07 ` law at redhat 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-53948-4-U9taimQtmL@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).