Point remains that gcc already has an optimizer and working backend and it's still hard to implement just the necessary changes.
Quote:
"The concern that has long been expressed by the FSF (which owns the copyrights on GCC) is that a general plugin mechanism would make it possible for companies to traffic in binary-only GCC modules. Rather than contribute a new analysis or optimization tool - or a new language - to the community, companies might have an incentive to distribute their work separately under a restrictive license. That runs very much counter to what the FSF is trying to accomplish, so opposition from that direction is not particularly surprising."
Whatever you think of RMS's stance on plugins, or gcc's plugin system, they have little relationship with the ease or otherwise of adding C++11 features to gcc.
The latter has much more to do with the difficulty of understanding the gcc C++11 front end, the difficulty of understanding the fine details of the C++11 standard sufficiently to implement it, and the amount of manpower available from people who can do both those things (or who have the time to learn).
gcc certainly does have a lot of historical baggage in its code base (though this is slowly improving with time), but given its rather complete support for C++11 (on par with clang certainly, and far ahead of MS's compiler and most other proprietary C++ compilers), they're not doing so bad...
I have a (basic) understand of clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM, which I can ignore the other side of. The interface between gcc front ends and backends is none of clear, simple or documented.
> clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM
(1) People adding C++11 features to clang are not going to be dealing with LLVM, they're going to be modifying and extending clang's existing C++ parser. So however nice the clang-LLVM front-end-middle-end interface is, that's not going to have much impact on this job. Rather, what's important is the quality of clang's internal algorithms and data-structures (and those in gcc's c++ front-end). If clang does better there (dunno), that's great for them, but it has nothing to do with RMS's plugin position.
(2) RMS is not against clean code, nice interfaces, good data structures, and good documentation. His concerns (whether you agree with them or not) are the degree to which interfaces are expressed in a way that circumvents the GPL. Good interfaces don't circumvent the GPL;
So it's perfectly fine to clean up and document gcc's data structures and interfaces (and indeed, this is already happening, and has been for a long time). RMS isn't going to stop you.
Chris Lattner, "The Design of LLVM" http://www.drdobbs.com/architecture-and-design/the-design-of...
(Seems possibly relevant to the boundary issue.)
I'm not sure how seriously to take that.
I don't see what this has to do with RMS or plugins.