C++ Conversion

This project is a continuation to the build GCC in C++ project. Its goal is to explore re-implementing some existing GCC components in C++.

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 http://airs.com/ian/cxx-slides.pdf

Rationale

Migrating GCC to C++ as implementation language:

• C++ is a standardized, well known, popular language.
• C++ is nearly a superset of C90 used in GCC.
• The C subset of C++ is just as efficient as C.
• C++ supports cleaner code in several significant cases.
• C++ makes it easier to write cleaner interfaces by making it harder to break interface boundaries.
• C++ never requires uglier code.
• C++ is not a panacea but it is an improvement.

Contributing

• This development branch follows the usual GCC maintainership rules.

• It is maintained by Diego Novillo (dnovillo@google.com), who will do periodic merges from trunk.

• Patches in the branch should be contributed to trunk following the usual contribution procedures.

• Patches should follow the new C++ coding conventions. Note: As of 2012-04-11 these conventions are still in draft form. Before patches can be moved out of this branch into trunk, we need to wait until they are approved and installed in http://gcc.gnu.org/codingconventions.html.

• ChangeLog entries should be written in the file ChangeLog.cxx-conversion in the corresponding directories.

• All e-mail communication related to the branch, should be tagged with [cxx-conversion] in the subject.

Accessing the branch

The branch is accessible via SVN at ssh://gcc.gnu.org/svn/gcc/branches/cxx-conversion. It was also registered in GCC's Git mirror, see these instructions for details on how to access it.

Additionally, you can view the branch with your browser at http://gcc.gnu.org/viewcvs/branches/cxx-conversion/

Starting Points

• Convert VEC to std::vector is a good starting point. This is the interface in vec.h.

• Another easy starting point would be converting uses of htab_t to type safe C++ hash tables, e.g., std::tr1::unordered_map. Here portability suggests the ability to switch to different hash table implementations; see gold/gold.h in the GNU binutils for one way to approach that.

• Another easy starting point is finding calls to qsort and converting them to std::sort, which typically leads to code which is larger but runs faster.

• Work out the details of using STL containers with GC allocated objects. This means teaching gengtype how to generate code to traverse STL containers, which would then be used during GC. This is not a task for the faint-hearted. But see also here Tom Tromey's hint.

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, for example, 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."