[GCC-XML]Re-write prototype in CVS

Brad King brad.king at kitware.com
Thu Mar 14 10:48:32 EST 2002


Dave,

> > that the starting name is surprisingly easy to use.  Most of the time,
> > people are interested in dumping header files.
> 
> I'm one of those people. It seems obvious to say "start at line 1 of
> foo.hpp".

Okay, I misunderstood what you meant.  The idea of a "start location" with
-fxml-start is to specify a certain entity in the C++ program.  Anything
to which that entity refers will also be dumped (and anything to which
those things refer, etc).  I thought you were saying that gcc-xml should
find a specific single declaration that exists on that line, and start the
subgraph walk from there.

Unfortunately, by the time the gcc-xml extension is invoked, the
translation unit parsing is done.  The internal representation no longer
has a direct notion of the order of input code.  All the dump has to start
with is a parse tree node called "global_namespace".  Some of the chains
of declarations within this are in reverse order, and some are not (due to
the way the parser builds them).  Recognizing what came from a certain
file would be an unbelievable pain to implement.  Perhaps it could be
done, but my funding source doesn't need it.

> Does g++ refuse to compile a file if it has an .hpp extension?
[snip]
> Are you telling me that GCC will refuse to compile a .hpp file based
> on its extension?

If you invoke GCC through its "gcc" front-end, it won't decide to run the
cc1plus program unless it recognizes a C++ extension.  When I first wrote
gcc-xml two summers ago, I still used the front-end.  Now that gcc-xml is
an executable based on running cc1plus directly, this is no longer a
problem.  I just never realized that until now.

> Arf. Are you telling me that it doesn't dump uninstantiated templates?

Currently, that is correct.  However, there is a spot in the code that
recognizes an uninstantiated template and purposely ignores it.  Adding
the output would just be a matter of implementing a few more node types
(like template_type_parm).  I'm planning to do this, but it just isn't
included in the first revision of the re-write in CVS.

Below is an example of what the output looks like for this code:

template <typename T>
struct A
{
  typedef T Type;
  void f(T);
};

if I remove the code that ignores uninstantiated templates.  The program
attempts to dump a RECORD_TYPE that is the TREE_TYPE of a TEMPLATE_DECL,
but encounters node types that are unimplemented.

<?xml version="1.0"?>
<GCC_XML>
  <Namespace id="_1" name="::" members=""/>
  <Struct id="_2" name="A<T>" context="_1" location="f0:3" members="_4 _5 " bases=""/>
  <Unimplemented id="_3" tree_code="183" tree_code_name="template_type_parm" node="0x4014a000"/>
  <Typedef id="_4" name="Type" type="_3" context="_2" location="f0:4"/>
  <Method id="_5" name="f" returns="_6" context="_2" location="f0:5" extern="1">
    <Argument type="_3"/>
  </Method>
  <FundamentalType id="_6" name="void"/>
  <File id="f0" name="template_example.cxx"/>
</GCC_XML>

-Brad




More information about the gccxml mailing list