http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #11 from davidxl <xinliangli at gmail dot com> 2012-04-15 04:09:53 UTC --- (In reply to comment #7) > > > are against it). I don't think there is any GCC contributor that is paid > > > to > > > improve GCC's diagnostics (am I wrong?). > > > > Right, but partially because it is a hard thing to do improve and the ROI is > > low. > > It is not *technically* hard. Anyone that knows C and a bit of C++ can fix > hundreds (if you know C++ well and have a some experience with the C++ parser, > you can probably fix thousands of bugs on your own, each fix taking no more > than a couple of hours of debugging and few minutes of programming). However, > it is time-consuming because of all the bureaucracy: copyright assignment, > setting up the environment, bootstrapping+testing, patch submission, patch > review, communication delays, style nits, changelogs nits, and updating the > testsuite. That is why even current contributors often don't bother with > one-liners, because all the associated tasks can make a one minute change > require days of effort. For many compiler hobbyists, the bureaucratic issues you mentioned don't exist yet before they start hacking on GCC FE. If the learning curve is steep and the interfaces are obscure, GCC will be less appealing to them. There is a difference between 'can do' and 'want to do'. > > > > 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?). > > > > Yes, and in Google, but do you know why? Because it is easy to improve their > > diagnostics and benefit can be quickly seen. > > But why is it easy? For example, the C++ FE, although I don't like many of its > design decisions, is quite easy to hack. > Clang can be used to do lots of interesting stuff -- such as source code indexing (for semantic based code search), complicated automatic code refactoring etc. The Clang's design makes it possible because 1) source location information is well preserved; 2) information about macros are preserved; 3) there is no on the fly constant folding etc. > And I don't think this is the reason. GCC is obviously easy to hack for their > current developers, but they focus on different things than the Clang/LLVM > developers. The whole attitude is quite different, for better or worse, and in > terms of popularity, the LLVM crowd wins (of course, the GCC crowd may say > that > this is not a popularity contest, but if you want to attract new developers, > who now have a choice, then it is). > > > > 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. > > > > Infrastructure makes a big difference here -- see more about this below. > > Indeed, but my point is that moving to C++ does little (in my opinion) to fix > the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, > patch submission is a pain, patch review is a bottleneck, no automatic style > checks, useless obligatory changelogs, no marketing, poor documentation for > beginners, poor coordination with other projects (binutils, gdb, glibc), etc. > (and, worse, the expectation that new/non-paid contributors should take care > of > fixing these issues). > > > > > > > Nothing of the above gets fixed by switching to C++ or by having a clearly > > > defined AST... > > > > I think they are clearly related. > > In any case, I hope you are right, and the move to C++ helps. I imagine that > it > can help to attract more corporate contributors, who don't have to bother with > legal paperwork and are paid to do also boring bits. For sporadic and/or > non-paid contributors, there are other bigger issues to solve. Moving to C++ itself won't do anything useful -- it is the new design as a result of moving to C++ that will make a difference. David
