[Phoronix] C++11 & The Long-Term Viability Of GCC Is Questioned

Back on Tuesday there was a basic email by a developer volleyed on the GCC mailing list, which has since sparked dozens of responses and a rather interesting conversation about the future of the GNU Compiler Collection and its ultimate path and viability moving forward. The initial e-mail was simply an inquiry asking about an estimated time-frame for having full support of the ISO C++11 specification. Diego Novillo, a well known GCC developer and Google employee, has even expressed fear that GCC may be past the tipping point and could die out naturally.

The mailing list thread that began on Tuesday and remains quite active to this day, can be found on the GCC list. Quickly pointed out was this C++11/C++0x status page for GCC, but the thread expanded well beyond that to talk about GCC development, luring in new developers, and the viability of this leading open-source compiler. Below are some of the interesting comments and overview of the thread.

Sparking the wider discussion about GCC were the usual comments by GCC developers responding to the reasonable question of when the C++11 support will be complete... "As usual, it'll be done when volunteer maintainers do it."

The "volunteer maintainers" response sparked a separate side-discussion about needing volunteers that are willing, which is easy to do, but the volunteers actually capable of working on GCC is very hard and a much smaller group of individuals. "This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor."

For developers new to GCC wishing to get involved, it's recommended to visit the GCC Getting Started Wiki.

In response to lowering the barrier for new developers to contribute to GCC was also the rather classic responses of "compilers are extremely complex programs" and "even fewer people are interested and competent to write such documentation" for getting into GCC.

Of course, LLVM/Clang also gets tossed into the discussion. One of the responses to when GCC will have full C++11 support was, "About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best."

In response to Clang comments, Google's Diego Novillo shared his views:

I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: "toolability" (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. That is not necessarily a bad thing for g++. But, to effectively compete in those areas, it will need to be significantly re-organized. LLVM has similar properties, at least as far as the middle end of the compiler is concerned. GCC still has an edge wrt backend portability.
In response to another email message about GCC needing to bring in newcomers by young students and experiments from academia, while most new developments these days are using LLVM, Novillo forked the mailing list thread to talk about the long term viability of GCC. Diego thinks the project could already be past the tipping point and the Free Software Foundation compiler could naturally die out.
This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers).
Richard Guenther responded by saying, "Note that we can't drive GCC into the garage and refactor it for two years. Any refactoring done has to be while being live on the road! Which essentially limits on what kind of refactoring is possible - which also may limit the ultimate outcome of the sum of all refactorings. Always have this in mind before you turn GCC into an even greater mess than it is!"

There's a whole lot more messages for those interested in the varying views of GCC developers and users about the future of this most popular open-source compiler, so see the thread index.