This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH]: Commence binfo extraction
- From: Andrew Haley <aph at redhat dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, Ziemowit Laski <zlaski at apple dot com>
- Date: Thu, 1 Jul 2004 10:31:07 +0100
- Subject: [PATCH]: Commence binfo extraction
- References: <40E3D4B7.3080905@codesourcery.com>
Nathan Sidwell writes:
> Hi,
> this patch separates binfos from TREE_VECs. As a stepping stone to turning
> a binfo into not-a-tree I've turned it into a new tree node. I've separated
> the uses of tree_type.binfo into those that are as binfos, and those that
> are other. Note the following points,
> *) The only two languages that appear to be using binfos are C++ and Java.
> *) There is a tiny memory reduction with this patch, as the tree_binfo struct
> is slightly smaller than the equivalent tree_vec struct.
> *) I've introduced a new global variable 'binfo_lang_slots' to record
> the number of language dependent slots. This is a *temporary* situation.
> *) The java changes are extremely mechanical here
> *) The objc change was more complicated, but mechanical. Objc was using the
> binfo slot for not-a-binfo, but still calling the binfo machinery to process
> it. This confused me.
> *) I grepped the various debugging info outputters for binfo use, but only
> dwarf2out appeared to be using them. It's possible I missed something.
>
> bootstraped and tested will all languages on i686-pc-linux-gnu, ok?
This looks OK, but we're trying to track down a recent regression in
Java. Would it be a problem to delay for a day or two?
Thanks,
Andrew.