[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-14 12:10:13 UTC --- 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. 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. 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.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14 12:24:47 UTC --- (In reply to comment #7) 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, There's the problem. I know C++ very well but don't know the front end well enough to work on it, and don't have time to learn it. My main problem is that everything is a void* so I have no idea what I can do with a given tree or what type it is, so I just try something, it compiles (because there's no type checking) so I run it then debug an ICE and continue by trial and error. That's not productive. The bottleneck is not the bureaucracy for me. 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, Why should the wiki be maintained? If people want to add to it they can, why should there be a maintainer?
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-14 12:42:53 UTC --- (In reply to comment #8) (In reply to comment #7) 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, There's the problem. I know C++ very well but don't know the front end well enough to work on it, and don't have time to learn it. My main problem is that everything is a void* so I have no idea what I can do with a given tree or what type it is, so I just try something, it compiles (because there's no type checking) so I run it then debug an ICE and continue by trial and error. That's not productive. The bottleneck is not the bureaucracy for me. Thanks for sharing this. This broadens my perception of the issues contributors have with GCC. That said, it should be possible right now to use a C++ wrapper around tree, and use that in the C++ FE (and require C++ to bootstrap the C++ FE). What do you think about that? 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, Why should the wiki be maintained? If people want to add to it they can, why should there be a maintainer? Well, the wiki is just a minor example, but it is awfully slow, nobody has administrator login (I can access as Daniel Berlin and ban users, but little more), and it is a unsupported version with known security issues.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14
13:16:18 UTC ---
(In reply to comment #9)
(In reply to comment #8)
Thanks for sharing this. This broadens my perception of the issues
contributors
have with GCC. That said, it should be possible right now to use a C++ wrapper
around tree, and use that in the C++ FE (and require C++ to bootstrap the C++
FE). What do you think about that?
I think that would help me, I don't know about others.
This is probably more suitable for the mailing list not bugzilla but it would
certainly help me if a tree is a FIELD_DECL then pass in a field_decl wrapper
around a tree, if it's a TREE_LIST pass in a tree_list wrapper around a tree.
Then functions/accessors that work on a TREE_LIST could be overloaded to work
on the wrapper, so you can use the original accessor on the raw tree if you
know what you're doing, or the type-safe overload on the wrapper which will
only compile if it's a valid operation.
But that wouldn't work when a function parameter is a tree that could be either
one type or another. That would either require the function to be refactored
to take two parameters, or some other way to have a wrapper that could be more
than one thing e.g. make the wrapper a template parameterised on by an enum
bitmask
templatetree_code C
struct tree_wrapper
{
tree t;
explicit tree_wrapper(tree t) : t(t)
{ gcc_checking_assert ( code() C ); }
tree_code code() const { return TREE_CODE (t); }
};
typedef tree_wrapperTREE_LIST tree_list;
typedef tree_wrapperTARGET_EXPR target_expr;
typedef tree_wrapperCONSTRUCTOR constructor;
// etc.
void f( tree_list list );
void g( target_expr expr );
void h( tree_wrapperTREE_LIST|TARGET_EXPR tree )
{
if (tree.code() == TREE_LIST)
f( tree_list(tree.t) );
else
g( target_expr(tree.t) );
}
Well, the wiki is just a minor example, but it is awfully slow, nobody has
administrator login (I can access as Daniel Berlin and ban users, but little
more), and it is a unsupported version with known security issues.
Ah yes, I see what you mean now.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
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
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-12 22:54:23 UTC --- Works for me: pinskia@server:~$ ~/treecombine-gcc/bin/gcc t.c -W -S -Wall t.c: In function ‘test’: t.c:5:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-12 22:59:55 UTC --- If it is about how clear suggestion the warning gives, then it is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280 .
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-12 23:07:44 UTC --- Yep, a dup. I am sorry David, but many of these deficiencies are well-known. What GCC sorely needs is people working on fixing them, and that is an issue that has no easy fix and it is only going to get worse. :-( *** This bug has been marked as a duplicate of bug 29280 ***
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #4 from davidxl xinliangli at gmail dot com 2012-04-12 23:28:38 UTC --- (In reply to comment #3) Yep, a dup. I am sorry David, but many of these deficiencies are well-known. What GCC sorely needs is people working on fixing them, and that is an issue that has no easy fix and it is only going to get worse. :-( *** This bug has been marked as a duplicate of bug 29280 *** This brings up the issue of programmer productivity where Clang can claim that their C++ based code base and clearly defined AST can make fixing things like this easier .. David
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
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...
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
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
