From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13851 invoked by alias); 11 Oct 2010 17:15:28 -0000 Received: (qmail 13809 invoked by uid 22791); 11 Oct 2010 17:15:25 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,MISSING_MID X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Oct 2010 17:15:21 +0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/45791] Missed devirtualization X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 11 Oct 2010 17:15:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-10/txt/msg00911.txt.bz2 Message-ID: <20101011171500.R4SjGd5zYjY452i_qNlPuWm3xGHkYyeK4BplA08l3bQ@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791 Martin Jambor changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mjambor at suse dot cz |jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor 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).