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]

RE: Using of parse tree externally


Hello All,

Let me explain my position on all of this : 

I am a new person in this puzzle that wants to be able to use or make free
and gpled software anaylsis tools based on the great job that all of you
have been doing on the compiler.
I am willing to and have done taken my personal time aside from my normal
job to try an figure out how this is possible.

When confronted for the first time with tree.h I felt quite lost.

I set out to figure out what was going on inside the trees and what can be
found out about them,
and have been working away for the past year on it, with the idea of
contributing the information back to the free software community. 

Now I am faced with the fear that opening up the tree is not all that
welcome by the community after all.

I can imagine that many honest people would like to know how the tree nodes
are put togeather, 
how to get at that information.
Not all of them are just trying to usurp the gnu compiler,
I myself am trying to support it.

There are many code processing tools out there,
cross reference tools, case tools, program databases and program analysis
tools.

How many times has there been quick hacks to the tree structure to extract
needed information?
How many people could contribute a piece to the puzzle if that structure was
opened up?
How many people have help hopelessly lost when looking at c-parse.in? 

The antlr project also has a very elegant grammar for c++, and tools to work
with it.
Sure it is a different platform with a different angle, but surely steps can
be made in making things better.

Is it a waste of time to try and document and figure out the front end? 
Does it have to be that cryptic to shoo away would-be gold brickers?

I am sure that most are people on the mailing list would agree that better
documentation has to be
made, and let me ask you all :

What type of information *WOULD* you like to see published from the
compilers internals?

	Data Type usage graphs?
	Function Call Graphs?
	Syntax Trees?
	A nice C++ or even XML representation of the tree node for easier
querying?

What would be in line with the steering comittee? 
Is there a place for openness in the open software?

I am sure that we can agree on a starting point that is acceptable to all.
	
Mike
-----Original Message-----
From: Ricardo Anguiano [mailto:anguiano@cs.ucdavis.edu]
Sent: 10 October 2000 18:56
To: gcc@gcc.gnu.org
Subject: Re: Using of parse tree externally



Greetings,

I would personally love to see the front end be made available in an API
for work on tools such as the AST Toolkit or ASTLOG

    http://www.research.microsoft.com/~rfc/

or Genoa/Gen++

   http://www.cs.ucdavis.edu/~devanbu/genp/

How would free software benefit?  These are awesomely powerful tools
with direct applications in software quality.  Isn't that supposed to be
one of the benefits of open source software?

Presently the microsoft stuff works only with the microsoft compiler
(duh) and gen++ works only with the at&t cfront compiler.  I would love
a similar tool for the gnu compiler.

-Ricardo Anguiano

Joe Buck <jbuck@racerx.synopsys.com> writes:

> That doesn't mean that it would necessarily be ruled out, but we'd
> need good arguments for how free software can benefit from the
> capability.
-- 
This communication contains information which is confidential and 
may also be privileged.  It is for the exclusive use of the 
intended recipient(s).  If you are not the intended recipient(s), 
please note that any distribution, copying or use of this 
communication or the information in it is strictly prohibited.  
If you have received this communication in error, please notify 
the sender immediately and then destroy any copies of it.


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