http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 01:03:28 UTC --- Maintainers (those who decide) are too few and they either do not care or do not have time to fix these things. Existing or new contributors that are paid to do something specific don't care about anything else as long as it doesn't interfere with their job (if it does, whatever improvement it may be, then they are against it). I don't think there is any GCC contributor that is paid to improve GCC's diagnostics (am I wrong?). This is very different from Clang, where Chris obviously cares a great deal about Clang's diagnostics, and it seems to be supported by a team in Apple (and in Google?). Contributors to GCC that care about these things, either unpaid or in their free time, are very few and completely overworked. It is true that the GCC code base has a huge technical debt, but diagnostic fixes tend to be easy to fix, if you have a little of experience. However, there are a lot of them, and getting patches reviewed and accepted requires herculean amounts of perseverance. But probably you can share with me more about your (or Googlers) thoughts on the latter, since you have the experience of submitting the same project to both LLVM and GCC. New contributors to GCC are almost non-existent (except those that are paid to work on very specific stuff, like a new port, but these new contributors also don't care about GCC in general, as long as it doesn't interfere with their job). The reasons why GCC fails to attract new contributors are very well-known: the copyright assignment is a major hurdle for casual/unpaid contributors, patches from new contributors are routinely ignored and the patch review process is hostile to new contributors (in reality, much less than in the Linux kernel, but they have enough developers to afford being hostile). Interacting for the first time with GCC developers can easily discourage a lot of people (there is a whole page just on the subject! http://gcc.gnu.org/wiki/GCC_Research). In Clang for example, small obvious fixes proposed by new contributors without any changelog or even without a patch are often committed immediately. I have never seen this in +6 years contributing to GCC, on the contrary, the contributor will be asked to bootstrap, regtest, provide a Changelog, fix the Changelog, provide a patch, read the code style, fix the code style, some bikeshedding, and between each step, there may be weeks of no feedback at all. GCC also has a huge marketing problem, no overall vision, no clear leadership (it is easy to get contradictory answers by the people who decide), and GCC developers show both a lack of enthusiasm (just compare presentations by Clang/LLVM developers, full of amazing features, awesome graphics, never-seen-before numbers and LLVM webpages are full of how good their compiler is, how much better than anything else, etc.) and a sense of superiority ("we don't want to be like Clang/LLVM! It produces slower code by 0.0001%! It doesn't support mmix-knuth-mmixware"). These kind of things are essential to attract new contributors, however, they do not seem to provide any advantage to existing developers, and they are seen as pointless extra work better done by, wait for it, new contributors. Nothing of the above gets fixed by switching to C++ or by having a clearly defined AST...
