Status Update 04/2012

GCC has been building stages 2 and 3 in C++ mode for a while. We are now working on switching the default to build in C++ mode from stage 1. This means testing that all the commonly used targets have C++ compilers able to handle GCC.

If you regularly build GCC, please see the C++ build status page for a list of targets that need to be validated. You can follow the instructions in that page to build your favourite target and report its status.

Additionally, the following efforts are underway:

Status Update 06/2010

Use of C++ in gcc has now been approved by the Steering Committee, please see the following links for additional details:

The gcc-in-cxx branch

This page is meant to eventually help document the ongoing effort in the "gcc-in-cxx" branch to make gcc compile in C++ mode, i.e. as C++ source code. So, the goal of this branch is to facilitate switching GCC's implementation language to C++.

The initial goal of the gcc-in-cxx branch will be to produce code which is quite close to mainline, but compiles gcc with C++ (as of 05/2009, this reflects the current status and scope of this effort).

Background: What matters for gcc going forward is that it continue to be comprehensible and maintainable. That is a struggle that gcc has faced for its entire existence as a free software project. It is certainly true that using C++ unwisely can make that struggle more difficult. But this issue is not qualitatively different from the issues we face today.

Whether we use C or C++, we need to try to ensure that interfaces are easy to understand, that the code is reasonably modular, that the internal documentation corresponds to the code, that it is possible for new developers to write new passes and to fix bugs. Those are the important issues for us to consider. The C++ features which are not present in C--features which are well documented in many books and many web sites--are not an important issue.

For additional background information on this effort and its scope, please check out This branch can be easily viewed and browsed using your browser


Migrating gcc to C++ as implementation language:


One possible approach would be to compile code on the branch. Where it fails, fix it so that it compiles. Then, if appropriate, move the patch back to mainline, test the patch there, and submit it for mainline.

Possibly useful Tools

Among Linux kernel hackers, the coccinelle tool has been increasingly used to do automated source code transformations using semantic patching. The tool itself is admittedly somewhat undocumented at the moment, but it is extremely useful and powerful and seems possibly like an ideal candidate for an effort like the gcc-in-cxx branch, simply because this effort does naturally involve lots of source code transformations, that would be much less tedious if they could be largely automated. Here are some related pointers:


This development branch follows the usual gcc maintainership rules, except that any non-algorithmic maintainer may additionally approve or commit patches which permit compilation with C++.

Project Status (last updated 06/2009)

Development Plan (last updated 06/2009)

Starting Points

Quoting (1):"Longer term, we know that memory usage is an issue in gcc. In the old obstack days, we had a range of obstacks with different lifespans, so we could create RTL with a temporary lifetime which was given a longer lifetime when needed. We got away from that because we spent far too much time chasing bugs in which RTL should have been saved to a longer lifetime but wasn't. However, that model should permit us to run with significantly less memory, which would translate to less compile time.I think we might be able to do it by implementing a custom allocator, such as a pool allocator which permits allocating different sizes of memory, and never frees memory. Then the tree class could take an allocator as a template parameter. Then we would provide convertors which copied the tree class to a different allocation style. Then, forexample, fold-const.c could use a temporary pool which lived only for the length of the call to fold. If it returned a new value, the convertor would force a copy out of the temporary pool. If this works out, we can use type safety to enforce memory discipline, use significantly less memory during compilation, and take a big step toward getting rid of the garbage collector."

Remaining Issues (last updated 2009-05-14)

Major TODO


Related mailing list discussions include (listed chronologically):

None: gcc-in-cxx (last edited 2012-04-06 17:02:43 by DiegoNovillo)