This is the mail archive of the
mailing list for the GCC project.
Re: Using of parse tree externally
- To: anguiano at cs dot ucdavis dot edu
- Subject: Re: Using of parse tree externally
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Tue, 10 Oct 2000 11:30:09 -0700 (PDT)
- Cc: gcc at gcc dot gnu dot org
> 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
The organization that owns gcc fears nothing more than making gcc's front
ends available as an API. The reason is that gcc is the most demonstrable
example of the "GNU public virus" in action: organizations that originally
did not want to make their code free made it free because there wasn't
another practical choice. That's why GNU has a free C++ and Objective-C
compiler today, and that's also why a number of the free back ends exist.
RMS feels that if we do what you want, we will quickly see proprietary
processor-specific backends that outperform gcc on specific processors
(not hard if you make a non-portable compiler) using the GNU front ends.
But you are right, there can be advantages.
> or Genoa/Gen++
> 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?
Certainly. But is it necessary to split gcc in half to write such tools?
Why not just extend the compiler? It already "knows", as part of its
analysis, everything that gen++ knows. If it just dumps a tree, then
the other tool will have to repeat some work that is already done in gcc
(e.g. compute control flow graph).
Why not add flags to have the compiler to write out a report? (A separate
tool would need to combine reports from separate object files).