This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: CNI changes (Was: Binary Compatibility)
- From: Tom Tromey <tromey at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Anthony Green <green at redhat dot com>, java at gcc dot gnu dot org
- Date: 04 Aug 2003 09:14:49 -0600
- Subject: Re: CNI changes (Was: Binary Compatibility)
- References: <Pine.LNX.4.44.0307300929080.11078-100000@ops2.one-point.com><87smoot8xw.fsf@fleche.redhat.com><16167.60120.49100.864112@cuddles.cambridge.redhat.com><1059964034.4179.643.camel@escape><16174.11577.13994.318051@cuddles.cambridge.redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
Andrew> Well, I guess it does save memory. However, the last time I looked
Andrew> there was some fairly nasty hacking in the C++ front end to make this
Andrew> work. I'll ask Jason if we can have thaht code in a common place.
We could try to approach the problem in a different way. C++, as I
understand it, just builds subclasses that look like:
struct subclass {
char padding[sizeof(superclass)];
my fields;
}
That's pretty ugly. When I looked into this (last time we talked
about it), I thought that stor-layout.c:finalize_type_size() was
rounding up each class' size, and that if we added a new hook to let
us skip this, we would be ok. I never tested this theory though.
Maybe it isn't that easy; stuff in gcc rarely is.
Tom