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

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-09-28 20:34 -------
Subject: Re:  [4.1 Regression]
	push_fields_onto_fieldstack calculates offset incorrectly

On Wed, 2005-09-28 at 20:29 +0000, mark at codesourcery dot com wrote:
> ------- Additional Comments From mark at codesourcery dot com  2005-09-28 20:28 -------
> Subject: Re:  [4.1 Regression] push_fields_onto_fieldstack
>  calculates offset incorrectly
> 
> jason at redhat dot com wrote:
> 
> > 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.
> 
> What I meant by "lying" (an admittedly overly contentious choice of
> word) was that the field for B-in-C is marked as having the complete B
> type due to the code at the end of layout_class_type.  However, the A
> virtual base isn't located in that B; it's located after the data
> members of C.  So, the base field for B is incorrect.

If you give me guys a way to detect this case from the middle end, i'm
happy to say "Don't walk this structure, it's not really there".

:)

> 
> I agree that using COMPONENT_REFs is good, but I think that the
> FIELD_DECL for B should have the as-base type.  Then, when you actually
> form the COMPONENT_REF, you should do the equivalent of:
> 
>   *(complete B*)&c.b_base
> 
> That will give the expression the correct type from the front-end's
> point of view, but not result in inaccuracy with respect to the
> TYPE_FIELDS for C.  Obviously, we need to make sure that B-as-base
> complete-B are in the same alias set.
> 
> (It might be even better just to have the front end consider B-as-base
> and complete-B as the same type, so that the expression could have the
> more-accurate B-as-base type.  But, that would be a huge change to the
> front end, so I think we have no choice but to use the complete-B type
> for an expression like "*(B*)&c".)
> 
> 
> 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488