Re: [RFC][4.4] Convenience reorganization of parts of tree.h

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Dec 1, 2007 7:37 PM, Diego Novillo <dnovillo@google.com> 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.

Richard.