
Help improve gcc - lysium
https://gcc.gnu.org/ml/gcc/2014-10/msg00040.html
======
kazinator
Oh, you need helpers to improve diagnostics, do you?

How about you merge the fscking C++ diagnostic I wrote more than 6 years ago
which is sitting in your Bugzilla (with patches!) collecting dust.

[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587)

What this does is warn you about constructs where you are using an object for
its construction side effect, but forget to give the declaration a name:

    
    
        void foo::bar()
        {
          mutexlocker(&my_mutex);
          // critical section
        }
    

This should be:

    
    
        void foo::bar()
        {
          mutexlocker locker(&my_mutex);
          // critical section
        }
    

Without the name, it's just a constructor call that doesn't define an object
that is scoped around the block, and so the mutex is not locked around the
critical section. Its value is discarded and that's that. If it's not
optimized away, it will do a quick lock and unlock.

I developed this while working as the "guy who makes the from-scratch embedded
Linux + toolchain distro". The app developers on the same project wrote a
large C++ application, and made this mistake in more than one place, so I
whipped up this diagnostic for them.

~~~
slavik81
cppcheck will find this sort of error, though a compiler warning would be
nicer. I've definitely made this mistake before and not noticed until check-
in.

------
userbinator
Easier said than done, when the codebase seems to be deliberately designed in
an obfuscated way due to paranoia around licensing issues. The rest of the GNU
toolchain has a similar feel to it too.

As an RE who has looked at a lot of compiler output, the code GCC generates is
quite different compared to e.g. MSVC and ICC, and I'm almost willing to bet
that it's not by chance. I have attempted to discover where to implement
improvements by reading the source, but the whole thing is so complex that
it's difficult to understand.

Complexity and licensing are probably the biggest issues that put people off
trying to improve GCC.

~~~
tedks
I really doubt that any free software project would intentionally make its
code harder to deal with. What would that even accomplish? People ripping off
GPL'd code aren't distributing the source, so your obfuscation isn't going to
be noticed. The code GCC outputs is irrelevant to licensing; RMS decided very
early on that he wasn't going to try to make GCC only compile free software.

Really, I think the GNU toolchain suffers from being an early adopter of
internationalization (since RMS was always committed to Unix saying "Hello,
world" and not "Hello, America") and as such has a lot of cruft for inserting
translated strings into things like cp.

But GCC is also just old. That's far more likely than a GPL conspiracy story.

~~~
CJefferson
No, this really is true, RMS wanted to make sure the GCC front ends and back
ends could not be seperated, because he didn't want people using the front end
for other projects. This has (in my opinion) hugely set back open source
software, and is why everyone new uses clang for any situation where they want
to parse C++ -- because g++ is purposefully designed to make it painful to
just get a C++ parse tree.

Here are the words from the man himself:
[https://gcc.gnu.org/ml/gcc/2005-01/msg00008.html](https://gcc.gnu.org/ml/gcc/2005-01/msg00008.html)

~~~
deng
Your information is old. You can easily access the C++ parse tree by writing a
gcc plugin. This is possible since gcc 4.5 or so, but somehow nobody really
noticed since everyone just stared at the new kid on the block.

You might say the tree itself isn't easy to deal with, which is true, but that
is just because the code is very old and things were done differently back
then (hint: union of structs).

There is even a very nice tutorial which explains how to do this:

[http://www.codesynthesis.com/~boris/blog/2010/05/03/parsing-...](http://www.codesynthesis.com/~boris/blog/2010/05/03/parsing-
cxx-with-gcc-plugin-part-1/)

------
Animats
GCC dates from an era when, to do cool programming, you had to work on
compilers or operating systems. Those are hard. The people who might have
worked on GCC in the past are now out writing "apps", hoping to get rich.

~~~
smallsharptools
@Animats, this is very true. Many only want to use languages which are
considered easy. Ruby and Swift are examples of the easier languages which
allow developers to avoid issues like memory allocation bugs. I do find that
the side effect of using simple languages, relying heavily on frameworks and
easy to use dependencies leads to complex applications which the developer
does not really understand. The extreme example is a WordPress site which is
slow or buggy and the "developer" who put it together does not know why much
less appreciate what is going on in the MySQL database. I wonder how many
developers are even capable of doing this low level work in relation to the
total number of people who call themselves developers.

~~~
ForHackernews
Real programmers don't call themselves "developers" and they don't use Pascal:
[http://www.pbm.com/~lindahl/real.programmers.html](http://www.pbm.com/~lindahl/real.programmers.html)

~~~
smallsharptools
I love that. From 1983 no less. It is basically the same sort of rant/argument
you hear today. I will be sharing it with the undergrads I know.

------
smallsharptools
Is it possible or does it make sense for GCC and LLVM to work together? Or
does the licensing make that impossible?

~~~
ihnorton
DragonEgg is an LLVM backend for GCC:
[http://dragonegg.llvm.org/](http://dragonegg.llvm.org/)

There was some discussion of joining forces in the early days of LLVM (ca.
2005 I believe), but for various reasons that did not go forward. Licensing is
indeed a big issue: GCC has had the explicit goal of making proprietary
plugins technically infeasible, which leads to avoidance of some
modularization/decoupling opportunities.

------
tomjen3
Am I misremembering or is the GCC maintainer famous for being such a gigantic
asshole that he has essentially scared people away from working on the
project?

~~~
mwfunk
You may be thinking of glibc, which (for a time at least) was known for having
an especially abrasive maintainer.

~~~
kazinator
I found that person good to work with back in around 2000-2001. I had no idea
he's not among the maintainers now. You get all sorts of "heads up" on
HackerNews without having to have your nose in multiple grapevines. :)

