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