This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][4.4] Convenience reorganization of parts of tree.h
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Diego Novillo" <dnovillo at google dot com>
- Cc: "Simon Baldwin" <simonb at google dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 2 Dec 2007 10:24:05 +0100
- Subject: Re: [RFC][4.4] Convenience reorganization of parts of tree.h
- References: <20071130002823.A8E0E41A9D4@localhost> <firstname.lastname@example.org> <4751A9FC.email@example.com>
On Dec 1, 2007 7:37 PM, Diego Novillo <firstname.lastname@example.org> wrote:
> Richard Guenther wrote:
> > Please make sure you do not make debugging gcc at -O0 a PITA. Also
> > compare gcc bootstrap times for inline fns vs macros.
> Turning macros into inline functions has the exact opposite effect for
> debugging. It will now be possible to call these accessors from gdb
> instead of having to remember the field names.
I am used to it.
> If you mean that now there are more functions to step into, I don't
> think that is a significant impediment. We already have that in various
> places. Given the other advantages of the inline functions, the balance
> is positive.
I don't believe that - for example the relatively new tree_operand_length
is a PITA if you just want to step into
fold_build2 (PLUS_EXPR, type, TREE_OPERAND (arg0, 1), tmp);
as you first step into that for TREE_OPERAND. If you now make _all_
the macros inline functions I can imagine myself running and screaming.
So please - with this work - make sure there is a way to make this smoother,
either with some fancy gdb support or with fancy gcc support. Or just tell
me this is already possible.
> It has other beneficial properties as well. It makes it easier to
> refactor internal APIs, add new checks, etc.
I don't see how it is easier with inline functions than with macros.
Obviously I am biased because it looks like I am more regularly single-stepping
through the innards of gcc than you.