This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Stage 2: Implement access check for template instantiation (2/n)
- From: "Giovanni Bajo" <rasky at develer dot com>
- To: "Paolo Bonzini" <paolo dot bonzini at lu dot unisi dot ch>
- Cc: <lerdsuwa at users dot sourceforge dot net>,"Mark Mitchell" <mark at codesourcery dot com>,<gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 May 2005 20:31:28 +0200
- Subject: Re: [C++ PATCH] Stage 2: Implement access check for template instantiation (2/n)
- References: <42859D60.firstname.lastname@example.org> <4285E92E.email@example.com>
Paolo Bonzini <firstname.lastname@example.org> wrote:
> > The first operand of ACCESS corresponds to TREE_PURPOSE,
> > and the second operand of ACCESS corresponds to TREE_VALUE
> > of TREE_LIST respectively. Several ACCESS nodes can be
> > linked in a linked list via TREE_CHAIN.
> Can you please consider accessing the field via a separate ACCESS_CHAIN
> macro (it is fine to #define it to TREE_CHAIN, it is only for clarity)?
Better, I don't see a real reason for introducing yet another use of
TREE_CHAIN in GCC. The list of deferred access checks could be stored as a
Vec of ACCESS trees.
And now that I think of it, we could probably avoid having the new ACCESS
tree code at all, and just define a struct AccessCheck containing a couple
of tree pointers. Unless I am missing something.
I think it is a general consensus (at least in the C++ FE) that we should
stop using trees for things that we can do without (especially those we
don't survive till the middle-end).