AW: dump-translation-unit format

[Sascha Alexander Jopen]

Hi,

Sorry for my double posts on this list and answering to the wrong persons. I
had/have major trouble with my mail client and anti-spam. I hope that
everything works as expected now.

> > I'm currently working on the output of gcc/g++ -fdump-translation-
> unit
> > to do source code analysis. I found several references that the 
> > internal ast should include nodes for for, while and do constructs.
> > But I can't find those nodes in the dumped files. Sometimes there 
> > are such FOR_STMT nodes when I compile large units, but when 
> > compiling a small test unit containing not much more than a for 
> > loop, this loop isn't included in the dump. Instead there is a 
> > GOTO_EXPR where I
> would
> > expect the for loop. This holds for other loops and conditional 
> > expressions as well. All FOR_STMT nodes I encountered where not from
> my custom code, but from templates from system includes.
> >
> > Are there any optimizations done on the tree before dumping it, and 
> > how can I prevent this to get an unoptimized tree? Are there other 
> > possibilities to get those loop nodes? I need them to check whether 
> > function calls are done in loops or not. Without the bodies of loops
> I
> > can get information about functions called from other functions 
> > using the chain links, but not whether they are called within loops.
> 
> Which version of gcc are you using?  In mainline -fdump-translation- 
> unit just dumps the global declarations.  If you want to see FOR_STMT 
> nodes, you need -fdump-tree-original.  But that is pretty 
> unsatisfactory these days since for_stmt nodes are not dumped in a 
> useful way.  And that only happens for C++; for C FOR_STMT nodes are 
> never generated.
> 

I'm using recent gcc-4.1.2. I used -fdump-tree-original-raw to obtain all
declarations from within functions. It seems that I can find all loop
constructs there, although there are many other nodes dumped, which I do not
understand completely by now. To do automatic parsing of the output seems to
be not as simple as I hoped initially.
But thank you for the -fdump-tree-original hint, anyway.

> 
> > Another thing I don't understand is the following. This dumped 
> > function node contains two body definitions, one undefined and one 
> > with a proper node chain. Is this a dump error or has it special
> meaning?
> >
> > @1639   function_decl    name: @2001    mngl: @2002    type: @2003
> >                          scpe: @812     srcp: char_traits.h:322
> >                          chan: @2004    note: member   accs: pub
> >                          args: @2005    body: undefined
> >                          link: extern   body: @2006
> >
> > Maybe someone could help me or point me to other resources.
> 
> The tree dump code prints out "body: undefined" for an external 
> function which is not to be compiled by itself.  But such a function 
> can still have a body; this will be the case for a C++ inline function.
> This is somewhat confusing.
> 
> Ian

I do not understand the link: external. All my own functions are also marked
as external, though they are defined, declared and used within the same
compilation unit. Additionally I do only have one compilation unit for
testing. Why are those functions marked as externally linked?

Sascha