[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly

[dberlin at dberlin dot org]

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