From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10124 invoked by alias); 29 Mar 2006 15:12:37 -0000 Received: (qmail 9973 invoked by uid 48); 29 Mar 2006 15:12:32 -0000 Date: Wed, 29 Mar 2006 15:12:00 -0000 Message-ID: <20060329151232.9972.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" 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 X-SW-Source: 2006-03/txt/msg02847.txt.bz2 List-Id: ------- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 15:12 ------- The first time we lay out the type, we have the fields reversed. See parse.y:java_reorder_fields. I don't know why this happens. (We construct the field list in reverse order, presumably for efficiency. What is unclear is why the type can be laid out before the fields are correctly ordered.) In any case, on ppc32, the ordering of fields matters, because the class One can be packed more efficiently if 'b' comes first. Then what happens is that when we lay out Two$Three, the initial size of One is used to lay out the super class field. This field's size is not recomputed the second time we lay out Two$Three, yielding the incorrect result. One possible fix would be to reset the field sizes when we null out TYPE_SIZE in java_reorder_fields (and perhaps elsewhere). A better fix might be to remove the need for reordering fields. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042