Hi Iain,
> > +/* Helper function for looking at TREE_TYPE (node). */
> > +DEBUG_FUNCTION void
> > +debug_tree_type (tree node)
> > +{
> > + debug_tree (TREE_TYPE (node));
> > +}
> >
> > This way I can do:
> >
> > (gdb) call debug_tree_type(tree)
> >
> > and get more concise output. But the code uses the various macros
> > TREE_* also in nested form, so I would have to write a wrapper for
> > each combination that appears in the code.
> >
> > So is there a better way? There should be!
>
> There are helpers available to view some if not all the macros (but that
> can depend on the platform you use - they don’t work for me on macOS).
>
> ====
>
> I am not sure if it counts as “better” but, providing you do not mind
> viewing the code as “C-like” you can use the pretty-printer.
>
> For example, I have debug functions in my local tree like this...
>
> DEBUG_FUNCTION void
> coro_pretty_p_expression (tree expr, const char *msg = NULL)
> {
> if (msg)
> fprintf (stderr, "%s", msg);
> cxx_pretty_printer pp;
> pp.set_output_stream (stderr);
> if (expr)
> {
> pp_newline_and_indent (&pp, 0);
> pp.expression (expr);
> }
> else
> pp_string (&pp, "<null>");
> pp_newline_and_flush (&pp);
> }
>
> so, in the code you can call this kind of thing with a “msg” to say what you
> were dumping
> and in the debugger
> “call coro_pretty_p_expression (expr_tree, “”) “
>
> obviously you’d name the functions differently :)
I am trying to get this to work here (fighting with includes),
but will keep trying.
> I have in addition :
> DEBUG_FUNCTION void
> coro_pretty_p_decl (tree decl, const char *msg = NULL)
>
> DEBUG_FUNCTION void
> coro_pretty_p_type (tree type, const char *msg = NULL)
>
> DEBUG_FUNCTION void
> coro_pretty_p_statements (tree stmts, const char *msg = NULL)
>
> I guess you could make a fortran pretty-printer .. but that is probably a
> project in its own right.
I am not looking for pretty-printing tailored to Fortran.
It's essentially about following the trees in gfortran's trans*.cc
albeit in a form that I can handle.
> FWIW, I find that debug_tree() can be more useful sometimes - it has more
> details and with some judicious casting you can drill down into it..
I do not doubt that debug_tree() is needed, and it is useful at times.
Just not now.
> .. but, as you say, seeing the wood for the trees can be hard,
Exactly. If I change just one token in the Fortran input,
I want to see that change propagate through its representation,
and not all the less-relevant scrub coming with it which diverts
my focus.
(For my specific purpose I'd think of "differential debugging",
somewhat along the idea of Cray's comparative debugger, but applied
to gcc. That would mean that one could "diff" trees between runs
of the gfortran frontend with slightly changed input.)
>
> Iain
>
> > call debug_tree_type(tree)
> >
> > Thanks for any insight!
> >
> > Harald
> >
> >
Thanks,
Harald
