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

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From mark at codesourcery dot com  2005-09-29 18:20 -------
Subject: Re:  [4.1 Regression] push_fields_onto_fieldstack
 calculates offset incorrectly

jason at redhat dot com wrote:

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

We may have to find some way to give them a compass. :-)

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

Yes, I agree.  The logically best thing would be that (possibly after
some kind of lowering pass), the C++ front-end would generate
expressions using the complete or as-base types, appropriately,
accurately reflecting what we knew about what was there.

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

We almost do create the types as you suggest; we just don't use them for
expressions.  The as-base type is a copy of the complete type, before
the vbases have been added, so it looks almost like a prefix of the
complete type.  The "almost" is because your code changes the types of
the base fields in the complete type but not in the as-base type.

So, I guess maybe we agree on the right plan.  In particular:

1. When we see "T*" or "T&", use the as-base version of T for the type.
 Therefore, for expressions like "*p" where "p" has type "T*", we would
give the expression the as-base version of T.  However, for expressions
like "t" (where "t" is of type "T"), use the complete version of "t".

2. Undo your change at the end of layout_class_type, so that base fields
have the as-base type.

We could implement (1) either by (a) doing that directly during parsing,
etc., or (b) by handling it during genericization/gimplification.  I
vote for the latter.  It should be relatively simple; do a pre-order
walk of the expression tree, and adjust the types of things from the
bottom up.

I'm not sure what else we would need to do.  We need to tell the
optimizers that the as-base type can alias the complete type; I guess we
just give them the same alias set.  We also need the optimizers to
understand that "*p = *q" is going to copy TYPE_SIZE (complete type)
bytes...



-- 


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