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