------- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-28
20:16 -------
Subject: Re: [4.1 Regression]
push_fields_onto_fieldstack calculates offset incorrectly
On Wed, 2005-09-28 at 19:39 +0000, jason at redhat dot com wrote:
> ------- Additional Comments From jason at redhat dot com 2005-09-28 19:39
> -------
> Subject: Re: [4.1 Regression] push_fields_onto_fieldstack
> calculates offset incorrectly
>
> mmitchel at gcc dot gnu dot org wrote:
> > I think this is a hack so that later, when we use the COMPONENT_REFs, we
> > don't
> > have to cast from the as-base type back to the nominal C++ type. (Of
> > course,
> > this would also be cleaner with a real C++-lowering pass.)
> >
> > However, I think the right thing is to have the cast; as you've discovered,
> > Jason's approach is lying about what's really there. Jason?
>
> My intent was to use COMPONENT_REFs where it's close enough to the
> truth, and casts where it isn't. The middle/back end produced
> significantly better code for COMPONENT_REFs than casts when I made the
> change, particularly with aliasing; I'm not sure if it's gotten any
> better since then.
>
> And besides, my approach isn't lying at all about this testcase; since
> there's only one appearance of the virtual base, it appears exactly
> where the field lists say it will. Daniel agreed that the problem is in
> his code.
>
No, it actually isn't.
I sent mark a followup mail, that didn't get put into the bug report for
some reason.
The type looks like this:
Main type of var: C
First field of C: field of type B ( <field_decl 0x40212ebc D.1814
type <record_type 0x40212170 B ... chain <field_decl 0x40212b24 x>)
First field of B : _vptr.B ( <field_decl 0x40212450 _vptr.B ... chain
<type_decl 0x401eec98>)
Second field of B: type_decl ( <type_decl 0x401eec98 B ... chain
<field_decl 0x40212564 D.1781>)
Third field of B: field of type A ( <field_decl 0x40212564 D.1781 ...
chain NULL)>
Second field of C: field of type X (<field_decl 0x40212b24 x
type <record_type 0x4020e844 X ... chain <type_decl 0x401eee38 C>)
Third field of C: type_decl (<type_decl 0x401eee38 C ... chain
<field_decl 0x4021605c D.1817>)
Fourth field of C: field of type A (<field_decl 0x4021605c D.1817
type <record_type 0x4020e9b4 A .. chain NULL)
This causes us to walk type A twice (once as the third field of B, once
as the fourth field of C), and where we get the offsets wrong, since we
process the fields of type A twice.
I don't see why type A appears in type C except through type B
Is this because of virtual inheritance?
If so, are those fields of "A in B" really *there*, at those offsets
from the beginning of type B?
The layout you had posted in the bug matches the offsets when we process
the type A field of C, but not the type A field of type B.
IE type A appears in two places.
It's the first place that screws us up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
