------- Additional Comments From jason at redhat dot com 2005-09-29 17:19 ------- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
mark at codesourcery dot com wrote: > > 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. Nah, "lying" is fair. If you lie to the compiler, it will have its revenge. > 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. The problem is that when you do that kind of type punning the optimizers get lost. > (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".) I think it might actually work better to use the base type for most expressions, and only use the complete type when we know the complete type of the expression. Within the compiler, we ought to be able to express the complete type as a RECORD_TYPE containing fields of the as-base type and any vbases, so that the relationship between them is clear and we shouldn't need to do any ugly casting. Of course, this would also be a significant amount of work. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
