Hacker News Reader

Comment by jevinskie | Hacker News Reader

> Technical differences are ephemeral.

Hardly the case when you want to extend/embed your compiler frontend/backend. In this case, LLVM/Clang shine. They are written in fairly clean and comprehensible C++ libraries. Most CLI tools are well under 1k lines! GCC is a real pain to even comprehend, let alone extend/embed!

View on HN

Clang only support a subset of the features that GCC has, so it is naturally easier to comprehend. Reading the user manual, more "tricky" GCC extensions is intentionally not implemented because they would be too hard to implement.

If you think this is good/bad for Clang/GCC, depend if you ever used said features, or if one prefer a smaller compiler which has less features.

It's not really more/less features so much as it is a tradeoff. LLVM is extremely powerful in that it lets you write front-ends for many different languages without worrying about the complexities of native code gen. Likewise, it lets you write backends for other target platforms (i.e. JavaScript), allowing you to gain the ability to port those languages to new platforms easily. Thirdly, you can write optimizers for LLVM's intermediate representation and gain the benefit across most/all front-end languages and back-end platforms.

GCC, on the other hand, seems to have a much narrower focus but with a lot more optimizations and weird extensions.

This is exactly GCC's architecture as well, where front-ends are transpiled into a generic language, which is then compiled into native code for a given platform.

That's how GCC works internally, but neither the front-ends nor the back-ends are available to use individually. Indeed, RMS specifically avoided having a flexible architecture similar to llvm, because he was afraid such flexibility would be used for non-GPL "plugins".

If you can dump or generate the IR you can use the front or back ends as you please, no? You might have to write something that reads in the IR.

Thats a lot of work for what you get out of the box with clang. There is a whole community of tooling around llvm for these types of use case, so why use gcc?

Sure, I was just arguing possibility, not feasibility.

GCC supports external dynamically loaded plugins since 4.5.0 (3 years ago)

http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

The wiki has links to some plugins too http://gcc.gnu.org/wiki/plugins

Sure, but what about the inverse? With LLVM you can use frontends as libraries for integrating into an (possibly non-free) IDE for completion, syntax highlighting, refactoring etc. This is especially powerful because you can avoid serialization and just keep the ASTs in memory. I'm not aware of this being possible with GCC, but I could be wrong.

I'm not sure the bigger number of nonstandard and noncompliant extensions is really a desirable attribute when comparing the merits of C compilers.

As I remember, at the time Apple started Clang, GCC wasn't nearly as clean. The various stages (parsing, compiling, optimization, etc) were not cleanly separated/documented so using the compiler's parser for syntax highlighting wasn't really possible. GCC has improved quite a bit since Clang/LLVM showed up in many of these areas.

Even if GCC had very clean separation between the steps, the FSF's interpretation is that you couldn't use the GCC parser for something like highlighting/suggestions the way Apple does in XCode without making all of XCode GPL.

It's a perfectly fair interpretation. I think making the opposite case would be quite difficult. But it shouldn't be surprising that Apple wouldn't want to open up all of XCode. I also don't blame Apple for not wanting to continue to re-implement parts of GCC and try to stay bug-for-bug on parsing when the only reason you can't re-use the same code is licensing.

> Even if GCC had very clean separation between the steps, the FSF's interpretation is that you couldn't use the GCC parser for something like highlighting/suggestions the way Apple does in XCode without making all of XCode GPL.

Only in this one technical implementation you've imagined. Interacting with GPLd tools via basically any method expect actually linking it into your code (e.g. pipes) doesn't infect your code with GPL obligations. Presumably just piping the entire code to gcc -fdump-tree-original every keystroke would be too slow but you could probably get it working nicely if you had the sort of engineer time Apple do.

This might change though, now that GCC has some stiff open source competition.

I heard GCC is partly a bit of a hairball to prevent GPL loopholes. They wanted to ensure you can't wrap it in some kind of RPC framework to get around the GNU GPL. They might clean things up a bit, if there's no longer an incentive for people to want to effectively steal it (since they can just use Clang instead).

In fact, open source projects (even GLP ones) might start switching to Clang, if it has a cleaner API.

So the costs of a hairy API are going to start outweighing the benefits.

Reply on news.ycombinator.com