Using of parse tree externally

[fire@blood.byz.org]

>>>>> "M" == Mark Mitchell <mark@codesourcery.com> writes:
    M> That might change, though.  I think the FSF fears are somewhat
    M> well-grounded.
...
    M> We have been approached more than once by people who wanted to glue
    M> GCC front-ends to their back-ends. Most of these people didn't
    M> understand the GPL; when we made it clear to them that they
    M> would have to make their code available, they backed off of
    M> this plan.  If, however, there was an easy to handle external
    M> representation that didn't have that impact, they might well
    M> make use of it.

I think this has already come to pass.

No one else seems to have mentioned it, but the recently open-sourced
SGI IA64 compiler appears to do exactly what the FSF fears.  It uses
the gcc front end. I'm not sure whether it is completely up to sync
with the current gcc front end, but it appears to be close enough for
Linux work. It has a lot of facilities for dumping out various
intermediate representations to files, from practically a raw AST to
very optimized code, and reading it back in again. It appears that
much of the communication between phases is done through intermediate
files. A manual for the IR comes with the source tree.

It also has a very modern global and inter-procedural analysis
framework, and F90 capabilities, making it a quite worthwhile compiler
in its own right. It might make an even better base for a proprietary
backend than gcc. Its main disadvantage lies in that it does not have
the many ports that gcc has, and isn't as mature as gcc. This may
change in time.

It would appear that making the gcc parse tree available externally
does not open the door to proprietary software any further than the SGI
IA64 compiler already has.