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

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

[xinliangli at gmail dot com]

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

             Bug #: 52957
           Summary: Missing suggestions on '=' and '==' confusion
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: xinliangli@gmail.com


void foo();
 void bar();
 void test(int i) {
  // ...
 if (i = 42) foo();
  else bar();
 }

 /*

 parentheses1.cpp:5:9: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 if (i = 42) foo();
     ~~^~~~
parentheses1.cpp:5:9: note: place parentheses around the assignment to
silence this warning
 if (i = 42) foo();
       ^
     (     )
parentheses1.cpp:5:9: note: use '==' to turn this assignment into an
equality comparison
 if (i = 42) foo();
       ^
       ==
1 warning generated.

*/

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

[pinskia at gcc dot gnu.org]

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

[pinskia at gcc dot gnu.org]

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

[manu at gcc dot gnu.org]

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

[xinliangli at gmail dot com]

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

[manu at gcc dot gnu.org]

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

[xinliangli at gmail dot com]

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

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

[manu at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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

[manu at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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


  template<tree_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_wrapper<TREE_LIST> tree_list;
  typedef tree_wrapper<TARGET_EXPR> target_expr;
  typedef tree_wrapper<CONSTRUCTOR> constructor;
  // etc.

  void f( tree_list list );

  void g( target_expr expr );

  void h( tree_wrapper<TREE_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

[xinliangli at gmail dot com]

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