[Bug c++/52957] Missing suggestions on '=' and '==' confusion

["xinliangli at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957

--- Comment #6 from davidxl <xinliangli at gmail dot com> 2012-04-13 05:01:56 UTC ---
I think you indirectly proved my point (see below) :)

(In reply to comment #5)
> 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?).

Right, but partially because it is a hard thing to do improve and the ROI is
low.

> 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.

> 
> 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. 

But Clang is even easier to hack on. Any person without any compiler background
can build tools on top of it. In other words, the bar of working on compiler
becomes very low -- and this is really exciting and attractive for developers
who used to think it as untouchable area to work on.

> 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.

> 
> 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).

I am aware of this.

> 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.

The root cause is still GCC's older infrastructure. Lack of modern design 
leads to weird interactions between various components, lots of hidden
assumptions, lack of good verification etc -- all these lead to the problem you
mention -- GCC patches from new contributors are bound to be buggy or to
trigger other latent bugs here and there, which means the heavy weight process
in GCC is required. Being an expert in GCC requires years of knowledge
accumulation and hostility is bound to happen (and ironically really required
to ensure quality) because qualified reviewers are so few and it just does not
scale. 

Clang can afford to lower the bar for contributors because its infrastructure.

> 
> 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 

I think part of the reasons is that contributors in that community are much
younger on average (the requirement on contributor experience is lower). Young
kids tend to be very enthusiastic.

>("we
> don't want to be like Clang/LLVM! It produces slower code by 0.0001%! 

I will assure you the performance difference is much more than that.

>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...

I think they are clearly related.

thanks,

David