Hacker News new | ask | show | jobs
by lazyjones 4538 days ago
esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete with LLVM, it just needs to become a technically better product. I don't buy the implication that it cannot become that without dropping some of the FSF's goals.

The gcc project is ancient and while I don't know the code base well, I'd assume that the fact doesn't necessarily help make it more approachable for new developers. Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people? The licenses seem to allow it.

6 comments

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

>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?
> The point is, gcc doesn't need to relax its policies to better compete with LLVM, it just needs to become a technically better product.

gcc has an explicit policy against making the code modular and reusable, for political reasons (to make it hard to use individual pieces of GCC as independent programs, which could form part of a proprietary compiler toolchain). The point is, this political policy has made gcc's code technically inferior in some ways to clang (modular code, with separation of concerns and clearly defined interfaces between components, is a technically good thing). GCC can't resolve this technical problem without abandoning this policy.

> Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people?

That would inherently mean abandoning this policy. And the answer is that while it's possible, the GCC codebase is still good, it still outperforms clang in many cases, and pulling in parts of clang would already require cleaning up and modularizing the GCC codebase - at which point we'd quite possibly end up with a compiler that's better than clang in all respects. So why not just do that?

> GCC can't resolve this technical problem without abandoning this policy

It seems to have been abandoned. GCC supports plugins and is working towards modularization.

You are the one conflating technical differences with political issues. The problem with gcc is not the license, but the decision to architect the system so that the intermediate formats are not accessible to plugin developers. Plenty of the projects that LLVM has made possible have no beef at all in licensing under GPL, however, under the current design of the gcc they are flatly impossible to write for it.

This is because the FSF deliberately designed gcc not for technical goals, but to prevent access to intermediate formats without merging the compiler, because that would allow non-free plugins (as they wouldn't be derivative works of the gcc and so could choose their own license). Unfortunately, these choices not only restrict non-free work, but the technical decisions made prevent a lot of useful things from being made, and makes contributing to the project much harder than contributing to LLVM/Clang.

> but the decision to architect the system so that the intermediate formats are not accessible to plugin developers.

What do you mean exactly? GCC plugins provide access to all internal data structures.

ESR's response to Ian Taylor:

"Then I don't understand why David Kastrup's question was even controversial.

"If I have failed to understand the background facts, I apologize and welcome being corrected.

"I hope you (and others) understand that I welcome chances to help the FSF's projects when I believe doing so serves the hacker community as a whole. The fact that I am currently working full-time on cleaning up the Emacs repoaitory for full git conversion is only one instance of this."

(I haven't been following ESR (not being part of his tribe and all), nor have I really been following Emacs. Do the other Emacs folks know about his "clean-up" there? Is it going to go any better than his clean up of the Linux kernel build system?)

Does GCC need to compete with clang at all? What's that mean exactly? Other than in terms of compile speed, it just seems like most modern compilers sort of reach some level of maturity and you really have to fabricate benchmarks to demonstrate that interesting of a difference between them.

ESR is just trolling. What his bug is, I don't know. Seems like he's dancing around something that might be interesting and more inline with the social observation that he's a little better at. I assert that GCC doesn't actually compete and doesn't need to compete. It just has to be available and it simply has to have hackers that are willing to work on it for the principle. Let's just assume that clang takes over the world, consistently produced better code than GCC, etc.. What exactly does that matter to GCC? Presumably hackers will stop working on GCC, but guile, hurd, and numerous other GNU projects show that that isn't always the case. I think that as long as GNU exists and they have some money and fans, there will be GCC contributors. Is there some other fear of what will happen if people use a different tool chain? Conversely, BSD has depended upon GCC for decades and I'm not convinced that that has affected it in any way and their switch to clang I suspect isn't going to radially alter things either. If we go back a week or two, I don't know that emacs' choice of revision control software makes any difference to its use, it may have some amount of impact on people contributing to it but I don't think that is clear cut either, there are A LOT of emacs contributions that aren't in the main tree... Also these projects don't want 'drive by' contributions, they want actively involved supporters.

Seems like he's dancing around some social observations that he wants to be true but can't prove or they might not be true. People hack on stuff because they have an itch, that itch might be technical need, it might be some sense of aesthetic that they think isn't being answered, it could also be related to something like freedom. When do other factors outweigh the itch? Now maybe GCC is GNU's most important software asset and there is some larger social thing ESR is worried about or has observed.

You are the one conflating the technical and political. This has little to do with licenses. GCC is written poorly on purpose in order to make it difficult to work with gcc. They do not want gcc to be used as a typical unix tool, doing some task and then having the output piped to some other tool to do some other task. They want you to have to directly extend gcc to add whatever functionality you want, this way you would have to make your functionality GPL. The consequence of this moronic decision is that gcc is an absolute nightmare to work on, is full of bugs that are very hard to isolate, and is being abandoned by everyone sane in favor of clang.
> GCC is written poorly on purpose in order to make it difficult to work with gcc

That's a strange conspiracy theory that has been posted here several times and debunked as well. It seems particularly odd to me because when I worked at a university 15 years ago, everyone in the compiler research world would occasionally hack on gcc to add features, retarget it, add optimizations etc. ... It didn't seem prohibitively difficult.

It's not a conspiracy theory. Could you point to the 'debunking' because I don't see one that contains any actual evidence?. There are lots and lots of public mailing list posts by RMS and other GCC engineers explaining their reasoning for not making GCC more modular. The reasons were political.

For example RMS vetoed the first attempts to add support for Java bytecode to GCC because he thought it would allow people to interact with GCC from other non-free software: http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html

That same reasoning is why there is no GCC equivalent to LLVM IR or libclang or libtooling.

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 some links in this wiki page that cover some of the arguments made against adding support for plugins to GCC. http://gcc.gnu.org/wiki/GCC_Plugins under 'Potential disadvantages of supporting a plugin architecture in GCC'

Here is a post from a GCC maintainer explaining that RMS was personally blocking the inclusion of this much desired basic functionality for political reasons: http://gcc.gnu.org/ml/gcc/2007-11/msg00193.html

> Is there any progress in the gcc-plugin project ?

Non-technical holdups. RMS is worried that this will make it too easy to integrate proprietary code directly with GCC.

Are posts from 2001 and 2007 really relevant for this discussion?

Look at this for example: http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html

The "debunking" in this thread was the confirmation that plugins actually work now because the policies were relaxed in favor of them.

The Stallman post about LLVM being bad because it allows people to use it to build other tools was from 2012. Why did you ignore that?

Plugins are only part of the story. Without stable intermedia representations there is still no GCC equivalent to libtooling or LLVM IR. That is by design, and remains true.

No conspiracy theory. Just an ugly truth that some people want to deny.

Why would you post an outright lie like that? Anyone can read the discussion and see multiple mailing list postings from RMS himself confirming the "conspiracy theory" is in fact reality. Quite an odd concept of debunking.