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).
