Airs – Ian Lance Taylor

GCC Project

GCC as a free software project is clearly very successful. Over more than 20 years it’s grown from nothing to become the standard compiler for several operating systems and many microprocessors. So far in 2010 the core part of the compiler alone has seen over 1000 commits by over 100 contributors. GCC continues to get significant new features; e.g., the recent GCC 4.5 release includes a new link time optimization facility.

On the other hand, the GCC project has some problems. The major individual contributors to GCC are hired to work on it. That means that they have a lot of time and resources to use to improve the compiler, which is good. However, it also has some negative effects. It’s difficult for new volunteers to join the community. It’s hard for them to learn the code base and it’s hard for them to keep up with the pace of change. It’s also hard for them to learn the conventions of how the project works, and they get little help in getting their patches in. Also, the people who work on GCC have learned the intricacies of the code base over time. They do not rely on the internal documentation. The effect is that the internal documentation for some parts of the code base is quite weak, and none of the main contributors are motivated to fix it.

Another, separate, problem is that there is no single person or group with a clear ability and willingness to decide on the direction of the project. In the past the direction has been set at different times by people like Richard Stallman, Richard Kenner, Jeff Law, and Richard Henderson. None of them are playing that role today. The effect is that nobody can see whether significant new features should or should not go into the project, which leads to a tendency for inconclusive discussions and unreviewed patches. People hoping to contribute are left with no clear path forward. (I should mention that groups like the GCC Steering Committee and the GCC Release Managers are effective but do not take on this role, which is more that of an architect.)

A third problem is that GCC has no public relations activity. The project web page tells you what GCC is but says nothing about how it compares to other compilers or how it has improved over time. There are some common criticisms of GCC, such as the belief that it is measurably worse than proprietary compilers, or that it is stagnating, which the project makes no attempt to discuss or dispute.

None of these issues are critical. As I said, GCC is highly successful. But they are areas where I think GCC could improve. Unfortunately, pointing out these issues is insufficient; it’s necessary for peole to step up to take on these roles. The various companies which pay people to work on GCC are generally less interested in these aspects of the project, which makes it that much harder to find people to work on them.

Posted

in

by

Ian Lance Taylor

Tags:

Comments

7 responses to “GCC Project”

  1. jyasskin Avatar
    jyasskin

    Another problem for new contributors is the stage system. If I’m inspired to write a patch, there’s a 2/3 chance that I’ll have to wait 2-6 months to get it in. If I don’t keep paying attention through that time, I may miss the opening of stage 1 and have to wait another version.

  2. Manu Avatar
    Manu

    I think the problems are critical because now there is a credible alternative and companies are likely to divest resources from GCC to the alternatives. If GCC had a large volunteer developer base or just a large part-time developer base, that wouldn’t be so problematic. As currently GCC is mostly developed by a handful full-time hired individuals from major companies, any single developer that is told to not work on GCC by its boss is a significant loss. And currently GCC is seriously lacking human resources.

    The fact that the barrier for a minor contribution is so high also means that little details are never fixed because main developers do not have time for them. It also means that contributing to GCC on your free time is a perseverance test that very few manage to pass and very few do for a long time.

    You say that people need to step up to fix these issues. But who? The people in the SC are the ones that have more power to get things done but they won’t step up to fix any of this. Then, hired developers have a lot of saying and a lot of time to dedicate to GCC but they (or their bosses) don’t see any of these issues important enough to step up themselves. The very few volunteer contributors have too little decision power to be sure their work will not be rejected, too little time for GCC to work on something big and to not want to waste their time in case it is rejected, and I will dare to say that they receive too little moral support to feel such work is welcome. Who else remains?

    A good thing from the recent alternatives is that they are showing to GCC what is possible and what actually works: (1) Marketing works. (2) There are users interested on contributing (3) There is a lot of interest on compilers which GCC is not able to capitalize on. (4) A faster development pace is possible (5) A better compiler is possible.

    GCC is catching up on some aspects but it is totally stalled on others.

  3. Ian Lance Taylor Avatar
    Ian Lance Taylor

    Thanks for the comments.

    I’m not sure I agree that the SC are the ones that have the power to get things done. They play two main roles in the GCC project today: they appoint new maintainers, and they talk to the FSF on the behalf of the GCC developers. While there have been weaknesses in the past, I think they are doing well in both roles today. The SC deliberately does not tell people what to work on, and does not make technical decisions. I think the GCC project could benefit from more of that, but I’m not sure the SC is the right place to make those decisions. The SC was designed to represent different user and developer communities in the project; it was not designed for technical leadership. The members of the SC are not in general the main people doing technical work on GCC; this is a deliberate choice, not an oversight.

    As you say, hired developers are often not free to make their own choices on what to work on. And I agree that volunteers are not sufficiently encouraged and there are not many of them. I think the community as a whole can steadily improve at this. The more we discuss it, the more people will be aware of the issues and, I trust, act accordingly.

    Meanwhile, let’s not ignore the fact that GCC is in fact improving steadily. The stream of improved optimizations and improved diagnostics is impressive. There are problems here that must be fixed if the project is going to continue to improve. But I would not characterize the situation as a crisis.

  4. Manu Avatar
    Manu

    The SC has more decision power than maintainers, and hence, some things must be consulted with them first, e.g., the C++ decision. I understand that it is not a decision to be taken lightly but the mere fact that it takes some much time and energy to get a decision done means that either the proponent has a lot of patience and perseverance, or some things won’t get done even if there is a consensus that they should be done and there is someone willing to do them.

    The FSF has even more power and it is even slower and non-responsive. I think most GCC developers agree that the copyright assignment process is overly complex and slow. Yet no one can fix this except the FSF.

    Volunteers have offered to upgrade GCC’s bugzilla, and they have been ignored. Perhaps my perception is not accurate (I would love to see some hard numbers) but I see less contributors than when I started a few years ago and even less volunteer contributors. And in my experience, a lot of polishing and boring-but-essential work is done by volunteers and they bring a lot of energy to the project (e.g., Steven Bosscher). Who represents the interests of volunteers and small-time contributors in the SC?

    It is true GCC is improving greatly on each release (and it is sad that this is not publicised well-enough!). However, I don’t think it improves fast enough to keep up with LLVM/Clang. And there is the issue of the diversion of contributors (and users) from GCC to LLVM/Clang. One of the goals of LLVM is to be a drop-in replacement of GCC. They haven’t achieved this yet but I wonder what would happen when they are ready. And everybody will know when they are.

  5. Ian Lance Taylor Avatar
    Ian Lance Taylor

    The FSF is definitely an impediment to the development of GCC. They own the code, but their interests are not the same as the interests of GCC developers.

    It seemed appropriate to raise the C++ decision at the SC level, but most decisions that do not affect licensing do not go to the SC.

    It’s a big problem that volunteers get ignored. That problem arises both because nobody takes responsibility for handling volunteers, and because nobody feels that they have the power to make things happen. E.g., who is responsible for bugzilla? Nobody. Who is responsible for supporting a volunteer to upgrade bugzilla? Nobody. Many people support an upgrade to bugzilla, but nobody is responsible for it.

    It’s a good point that volunteers are not represented on the SC. But the place where volunteers really need support is in having somebody to explain how the community works and getting their patches reviewed.

    I have no data as to whether LLVM/Clang is improving faster than GCC. It’s clear that LLVM has much better marketing than GCC does. LLVM tends to describe performance in terms of compile time. GCC tends to describe performance in terms of time it takes to run compiled code. Each compiler tends to win by its chosen definition.

  6. Manu Avatar
    Manu

    That is precisely my point. GCC seriously lacks manpower given its size. However, I don’t think this is acknowledged enough. What is the reason for this and how to fix it?

    Some reasons are that the mere lack of manpower does not allow more reviewers, better marketing, good introductory documentation, and good support to newcomers. It is a vicious circle: We need more people to attract more people. But the thread “Why not contribute?” showed that the first major barrier that most would-be contributors cannot overcome is the copyright assignment process. I would like to be able to announce to the list: “We have taken the feedback into account and now there is a simple webform that addresses 99% of the situations.” Then, I will move to analyze what is the next major hurdle and fix it. However, I cannot do this by myself and I cannot move forward such proposal. And *this* is the real issue in many other cases: Even if volunteers are willing to put work and free time on fixing something, they can’t because the power to enable them to do so resides elsewhere and it would take lots of additional energy and time just to start the process.

  7. LLVM i GCC – wiwerna ze?re antylop?? « OSblog.pl Internet, Social Media, Hardware & Software

    […] fragmenty s? autorstwa Iana Lance Taylora i pochodz? z jego prywatnej strony. Wykorzysta?em je korzystaj?c z przys?uguj?cego mi prawa cytatu. Wykorzystane logo LLVM i GCC […]

Leave a Reply