Hacker News new | ask | show | jobs
by fafner 4538 days ago
I think GCC receives a lot of undeserved hate at the moment. It is still a very good compiler which constantly improves. E.g., for my projects it generates better (faster) code. But still there are a lot of flame comments made against GCC. It was very similar when Chrome was released and suddenly the web was filled with flame comments against Firefox.

I think one problem is that many developers on Apple systems think the Apple GCC was state of the art. When in fact the latest release (a patched 4.1?) was rather old and obsolete. The Clang homepage still used to compares itself to GCC 4.1 instead of 4.8.2 or 4.9. It was similar when Chrome was released and Firefox was stuck on 3.6.1 waiting for 4.0. Sure Chrome was a lot faster but Firefox quickly caught on. But still people seem to think otherwise.

There is a GCC for LLVM, called DragonEgg http://dragonegg.llvm.org/. It is a _plugin_ (yes GCC has those since 4.5) for GCC. But I don't know what huge advantage it's supposed to bring. Especially when GCC seems to have the better backend (at least for my projects) at the moment.

I think the GCC folks should make the GCC Python plugin official because it provides a more stable and clean API (mentioned by ian lance taylor here: http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html). They should continue with the transition for C++ (which will help to clean up the code base a lot, no matter what the C++ haters say) and increase the work towards modularization (http://gcc.gnu.org/wiki/ModularGCC that would probably allow making the frontend available as a library similar to libclang). Libgccjit could be very interesting as well http://gcc.gnu.org/wiki/JIT

3 comments

>increase the work towards modularization

Is that actually going to happen though? RMS is very clear that he doesn't want it to happen, and continues to argue against it. He knows that the decision to keep the architecture monolithic and only expose unstable internal data structures limits functionality, and he is happy to make that sacrifice:

https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00...

The GNU Project campaigns for freedom, not functionality. Sometimes freedom requires a practical sacrifice, and sometimes functionality is part of that sacrifice.

https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00...

Part of the reason why clang/llvm weakens our commnity, compared with GCC, is that the clang front ends can feed their data to nonfree tools.

There are very real differences between Clang and GCC - not when you use them as a client, to compile your code in the CLI, where gcc did indeed make big improvements in the areas it was not as good as clang, and was already pretty kick ass anyway, but when you try to use them as libraries, eg. use the AST to do source transformations, or use the code generator to make a backend for a new language.

Using clang/llvm for this is a breeze. They were concieved for that from the get go. Using gcc's AST to do anything is an horrible nightmare, and you pretty much have to fork the whole gcc code base to do that anyway.

Using gcc to implement a backend for a new language is possible, but still a lot harder than doing so with LLVM, which actually has a spec for its IR, and is well documented.

Those things are not going to be easy to change because GCC wasn't designed to account those needs.

It's not too surprising that the IR is LLVM's strength, since that was originally the sole point of the project: the Low Level Virtual Machine was a research project at the University of Illinois to produce a target-independent low-level assembly infrastructure, in particular to be able to serve as the code-gen backend for managed/VM languages (vs. the GHC/SBCL approach of the language runtime bundling its own custom codegen). C-- was another project in that space.

GCC by contrast started as a project to replace AT&T's CC, and has since grown into a project to provide a free compiler suite, but in general an AOT compiler suite, not a backend for VM-based languages (even the Java support, the now-mostly-dead gcj, was an AOT approach). Its main competitors for years were proprietary compilers like icc, Sun Studio, and IBM VisualAge, and the main focus of comparison was language feature support and optimization performance. So that produced a pretty different development focus in each case for quite some time, though they've converged more in recent years. Nowadays the LLVM project has put a lot more resources into the compiler than they used to (including AOT-compiled languages), and GCC has been cleaning up the compiler internals and producing a plugin API. But for much of the lifetime of the two projects they weren't really in the same space.

> Using gcc's AST to do anything is an horrible nightmare, and you pretty much have to fork the whole gcc code base to do that anyway.

GCC supports Plugins which allow you to access all internal structures.

> Those things are not going to be easy to change because GCC wasn't designed to account those needs.

They are working towards modularization. It will certainly not be an easy task. But I hope they accomplish that.

>They are working towards modularization. It will certainly not be an easy task. But I hope they accomplish that.

gcc-xml was already written and the gcc devs refused to merge it. Has that changed in the last year?

http://gccxml.github.io/HTML/News.html

Looks quite dead to me, and I recall reading that the author do not recommend using it anymore.

There are still commits (latest ~1 month ago) https://github.com/gccxml/gccxml/commits/master
When was that? 10 years ago?
I definitely don't hate GCC, for a long time it was the best free compiler that I knew so I am really grateful to the people that made it possible.

But honestly, after seeing the error messages of Clang compared to those of GCC, I have zero intention of going back to GCC.

It may be that GCC generates better code (to be honest, I don't know) but 99% of the time that I'm using a compiler, I'm interacting with the error messages. The quality of the error messages has a real, significant impact in my development time. And if I want better code, I can always use GCC for the final compilation after doing all the debugging work with Clang.

As I said, I can't say I hate GCC, it's a free product and many, many wonderful projects have been compiled with it. But I honestly don't understand why, after all these years of development, the error messages are still that bad.

GCC error messages aren't that bad. Could it be that you compare the old Apple GCC to the latest clang?