HN Explorer

25 comments

[ 2.5 ms ] story [ 65.8 ms ] thread
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/

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.

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

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

arnsholt
I can't find it right now, but there's a pretty interesting thread from the GCC mailing lists where RMS states explicitly that parts of GCC are very tightly coupled, by design, precisely to make it hard to reuse the code-generation backend in non-free software.

I believe the rationale is that such a reuse would be very hard to find, much less prove conclusively.

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

riffraff
making two parts not separated does not imply the code is obfuscated. Also, the gcc maintainers have in the meantime moved away from that policy, IIRC.
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-...

[deleted]
(comment deleted)
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. :)
[deleted]
(comment deleted)
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

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.