5 ms·

Help improve gcc

67 points by lysium 12y ago

smallsharptools 12y ago
Is it possible or does it make sense for GCC and LLVM to work together? Or does the licensing make that impossible?
- ihnorton 12y ago
  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.
- edsrzf 12y ago
  There has been recent talk of it. See here for a link and (brief) HN discussion: https://news.ycombinator.com/item?id=8149810 https://news.ycombinator.com/item?id=8149810
- mwfunk 12y ago
  They already do- for a long time before Clang was ready for prime time, the default compiler on OS X was GCC with an LLVM back end. I'm not sure if any of this ever got merged into mainline GCC (the work was done on a pre-GPLv3 fork of GCC), but the code is widely available per the terms of the GPL.
Animats 12y ago
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 12y ago
  @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 12y ago
    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 12y ago
      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.
userbinator 12y ago
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.
- aric 12y ago
  People or certainly some companies might be put off from contributing due to licensing. That might be. However, it shouldn't be understated that a great number of contributors to GCC do so because of its license.
  - chris_j 12y ago
    I don't think that userbinator is complaining about gcc's licence so much as about the unnecessary complexity of the codebase. The accusation that I've heard levelled at gcc in the past is that the code is structured such a way as to make it hard to use parts of it with other proprietary modules. The consequence of this is a codebase that is less modular and more complex than necessary.
- tedks 12y ago
  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.
tomjen3 12y ago
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 12y ago
  You may be thinking of glibc, which (for a time at least) was known for having an especially abrasive maintainer.
  - kazinator 12y ago
    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. :)
- deleted 12y ago
  [deleted]
- _delirium 12y ago
  GCC hasn't had "a" maintainer since the late '90s, when RMS stopped being sole maintainer. It's now maintained by a whole bunch of people: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS
kazinator 12y ago
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 12y ago
  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.

Help improve gcc

67 points by lysium 12y ago

smallsharptools 12y ago

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

ihnorton 12y ago
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.
edsrzf 12y ago
There has been recent talk of it. See here for a link and (brief) HN discussion: https://news.ycombinator.com/item?id=8149810 https://news.ycombinator.com/item?id=8149810
mwfunk 12y ago
They already do- for a long time before Clang was ready for prime time, the default compiler on OS X was GCC with an LLVM back end. I'm not sure if any of this ever got merged into mainline GCC (the work was done on a pre-GPLv3 fork of GCC), but the code is widely available per the terms of the GPL.

Animats 12y ago

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 12y ago
@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 12y ago
  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 12y ago
    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.

userbinator 12y ago

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.

aric 12y ago
People or certainly some companies might be put off from contributing due to licensing. That might be. However, it shouldn't be understated that a great number of contributors to GCC do so because of its license.
- chris_j 12y ago
  I don't think that userbinator is complaining about gcc's licence so much as about the unnecessary complexity of the codebase. The accusation that I've heard levelled at gcc in the past is that the code is structured such a way as to make it hard to use parts of it with other proprietary modules. The consequence of this is a codebase that is less modular and more complex than necessary.
tedks 12y ago
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.

tomjen3 12y ago

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 12y ago
You may be thinking of glibc, which (for a time at least) was known for having an especially abrasive maintainer.
- kazinator 12y ago
  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. :)
deleted 12y ago
[deleted]
_delirium 12y ago
GCC hasn't had "a" maintainer since the late '90s, when RMS stopped being sole maintainer. It's now maintained by a whole bunch of people: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS

kazinator 12y ago

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 12y ago
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.