> > Some strong way of addressing the concern that this could be used to make > > proprietary front-ends or proprietary back-ends using part of GCC! > > Why is this case different from the existing llvm-gcc?
It's the question of what one means by "plug-in interface". If you view it as no different from the existing llvm-gcc, then you're basically saying we already HAVE a plug-in interface. So then what are we talking about? So the answer to your question is "whatever the difference is between what we have now and what a plug-in interface would provide". :-) More seriously, the issue is copyright law. In order to write a front-end for GCC right now (or for a GCC front end to use another backend), you have to use a sufficient number of header files and interfaces of GCC that there's no question that it's a derived work from GCC and hence must have a compatible license. But if you create a well-defined interface, you have the legal issue that the better you do in isolating the two pieces, the weaker the case is that one piece is a derived work of the other and if it's not, then you indeed CAN have a proprietary front-end. This is an issue that goes back decades and influences a lot of GCC. For example, it might have been tempting to have the dump files (originally just RTL, but now tree) contain everything needed to read them back in and continue the compilation. But if this were done, then it would be trivial to have proprietary front ends, back ends, and optimizers. So RMS never allowed any such thing nor any scheme that resulted in having any file that could be used for such a purpose.
