From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27003 invoked by alias); 28 Sep 2005 20:29:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26955 invoked by alias); 28 Sep 2005 20:29:01 -0000 Date: Wed, 28 Sep 2005 20:29:00 -0000 Message-ID: <20050928202901.26954.qmail@sourceware.org> From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050714141428.22488.micis@gmx.de> References: <20050714141428.22488.micis@gmx.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg03532.txt.bz2 List-Id: ------- 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. 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