This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -fdump-translation-unit considered harmful


Guys,

please. let the -fdump-translation-unit work as it did, this saves
us quite some time custom ad-hoc parsing C/C++. I understand there are political issues with it generating full tree dump (from a previous thread on this list), however, I don't see why we the OSS developers can not benefit from the great work you guys have been doing in impoving C(++) compiler. Another problem is of course the quantity of generated data which is not convenient to parse with home-grown (Awk) scripts I have, see the following paragraph...


Although I am not familiar with ASIS, I do believe we need a way to
flexibly generate data/code from the tree (dump), be it with an API or an external tool. I don't see why such a tool can not be built into GCC,
as long as it has to be supplied externally in form of a script. Such an Awk (or for that matter, Icon) script would get direct access to the tree via standard Awk (Icon) data-structures or functions, and would necessarily have to be supplied in source form, thereby prohibiting vendor lock-in.


Don't cut the trees!

Pjotr Kourzanov

Robert Dewar wrote:
Stefan Strasser wrote:

but I think there should be a stable interface or a stable xml output for c++ code. (I know there is gccxml patch, but it is nothing else than a dump-translation-unit written to a flat xml file, no hierarchy, no statements)


I assume you are aware of the non-technical difficulties with such an
approach, but just to continue with the technical discussions, I think
that an output of this kind is only a first step. What is really needed
is something analogous to the ASIS interface in Ada, i.e. a well defined
API that let's programs make structured queries on the semantics of a
parsed program. This approach has several advantages:

1. You do not have to try to stablilize the intermdiate output used as
an input to this tool (e.g. the GNAT tree changes all the time), but
instead you just keep the API stable.

2. The API is at a far more convenient level for writing typical tools

3. The API is not in general planned to be convenient for, or efficient
enough, to write an entire compiler (thus addressing one of the critical
non-technical issues).

Robert Dewar



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]