public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/45791] Missed devirtualization Date: Mon, 11 Oct 2010 17:15:00 -0000 [thread overview] Message-ID: <20101011171500.R4SjGd5zYjY452i_qNlPuWm3xGHkYyeK4BplA08l3bQ@z> (raw) In-Reply-To: <bug-45791-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791 Martin Jambor <jamborm at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mjambor at suse dot cz |jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-10-11 17:15:02 UTC --- Hi, (In reply to comment #3) > Hmm, > normally we should see it from COMPONENT_REF: I don't understand the sentence above. > while (true) > { > if (TREE_CODE (ref) == COMPONENT_REF) > { > tree par_type; > tree binfo, base_binfo; > tree field = TREE_OPERAND (ref, 1); > > if (!DECL_ARTIFICIAL (field)) > { > tree type = TREE_TYPE (field); > if (TREE_CODE (type) == RECORD_TYPE) > return TYPE_BINFO (type); > else > return NULL_TREE; > } > but we don't since it has DECL_ARTIFICIAL set. What is the logic here? > Also what about i.e. ARRAY_REF and arrays of objects and COMPONENT_REFs > translated to MEM_REFs? See testcase g++.dg/ipa/ivinline-5.C. We have to differentiate between fields which represent ancestors and field which are really put there by the user. MEM_REFs would indeed pose a problem here, we would have to find the field by (a simpler version of) something like build_user_friendly_ref_for_offset in tree-sra.c. ARRAY_REFs cannot represent ancestors and so are not a problem. But you wrote the field is artificial so the code above should not be an issue. In fact, the code specifically does make sure it does not traverse BINFOs of the first ancestors with virtual methods because they do not have their own list of virtual methods (http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01458.html).
next prev parent reply other threads:[~2010-10-11 17:15 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-09-25 17:28 [Bug tree-optimization/45791] New: " hubicka at gcc dot gnu.org 2010-09-25 19:50 ` [Bug tree-optimization/45791] " hubicka at gcc dot gnu.org 2010-09-26 3:33 ` hubicka at gcc dot gnu.org 2010-09-26 3:39 ` hubicka at gcc dot gnu.org 2010-09-26 6:02 ` hubicka at gcc dot gnu.org 2010-10-11 17:15 ` jamborm at gcc dot gnu.org [this message] 2010-10-11 18:40 ` jamborm at gcc dot gnu.org 2010-12-14 17:46 ` jamborm at gcc dot gnu.org 2010-12-14 23:15 ` hubicka at gcc dot gnu.org 2010-12-14 23:17 ` hubicka at gcc dot gnu.org 2010-12-14 23:35 ` jamborm at gcc dot gnu.org 2010-12-15 0:10 ` hubicka at gcc dot gnu.org 2010-12-15 0:13 ` hubicka at gcc dot gnu.org 2010-12-15 16:07 ` jamborm at gcc dot gnu.org 2014-02-24 9:44 ` matthijs at stdin dot nl 2014-09-25 20:29 ` hubicka at gcc dot gnu.org 2021-01-07 17:38 ` jamborm 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=20101011171500.R4SjGd5zYjY452i_qNlPuWm3xGHkYyeK4BplA08l3bQ@z \ --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).