41 ms·

Clang and FSF's strategy

149 points by wisesage5001 13y ago

lazyjones 13y 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.
- fafner 13y 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/ 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 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 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 http://gcc.gnu.org/wiki/JIT
  - Raphael_Amiard 13y ago
    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.
    - fafner 13y ago
      > 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.
      - anon1385 13y ago
        >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?
        belorn 13y ago
        http://gccxml.github.io/HTML/News.html 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.
- Tuna-Fish 13y ago
  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.
  - fafner 13y ago
    > 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.
- lmm 13y ago
  > 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?
  - fafner 13y ago
    > 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.
- asdasf 13y ago
  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.
  - lazyjones 13y ago
    > 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.
    - anon1385 13y ago
      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 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/msg00008.html 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 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 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.
- Nelson69 13y ago
  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.
- mcguire 13y ago
  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?)
fhd2 13y ago
Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools. I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war? edit: I'm now aware that esr is not talking about license restrictions but technical restrictions here. I have yet to find any evidence of technical restrictions for political reasons though, and it looks like the folks responding to him on the mailing list are not sure what he means either.
- Tuna-Fish 13y ago
  No. It's not that at all. The GCC/LLVM debate has nothing whatsoever to do with licensing, but crippling the design of gcc for political aims. Educate yourself on the subject.
  - fhd2 13y ago
    I can't claim to know anything about GCC's internals, but from what I know/read, it does have a plugin system and I don't see any indication of that being held back for political reasons (there are many other potential reasons for technical inferiority). And I don't see how the FSF could ever have furthered their political goals by making it technically hard to use GCC in free software tools, quite the contrary. Would be quite interested in evidence of that.
    - fhd2 13y ago
      I think I get what you mean now, you said above that GCC doesn't want to give external tools access to intermediate formats. But is that really the "anti plugin policy" esr is talking about?
    - asdasf 13y ago
      https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00008.html https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00... RMS says "freedom" is worth sacrificing functionality for. GCC is a monolithic mess of shit that is virtually impossible to debug, and produces incorrect code very frequently. Being forced into a terrible architecture where everything is smushed into everything else just to prevent people from being able to use gcc as a front end and something else as a backend is absolutely a case of making the code worse for the sake of trying to further a political agenda.
zombie_hitler 13y ago
esr trolling the gnu mailing lists...
ahazred8ta 13y ago
ESR may be incorrect; GCC has a plugin system. (YMMV) http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html / http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html
- Tuna-Fish 13y ago
  However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.
  - iso-8859-1 13y ago
    is it at least stable across patch levels?
  - Shamanmuni 13y ago
    There's a reply to esr by Alexandre Oliva which touches this point. I'll quote what he says: "That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it up-to-date". I don't know about the subject but it seems a quite reasonable stand and it certainly doesn't hinder the Linux kernel development, I don't see why it wouldn't work in GCC.
    - bjourne 13y ago
      I believe he is talking about different kind of plugins. For example, suppose you are an editor and you want to syntax highlight c source code. You could then feed .c files to clang, get back a parsed ast and use that for awesome syntax highlighting. You can not do that with gcc and the fsf does explicitly not want you to be able to. Because you could then be writing a non-free editor to take advantage of and using gcc as a free front-end.
      - 13y ago
crististm 13y ago
ESR is comming hard on FSF to what is actually embracing "open source" movement. His arguments are technical only as a means to hide the politics. This is not going to happen. I think David Kastrup's reply was pretty clear in that sense. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html
e12e 13y ago
As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, inferior ABI for the sake your proprietary crap -- share or GTFO (And it's easier for everyone if we can just see your code, bugs and all)"). However, isn't this paragraph: "I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course." proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially) doing? I know Apple makes great contributions to (among other projects, clang) -- but is upstream clang the same as what comes with Xcode?
- dalke 13y ago
  As one of the commenters points out, Intel continues to develop a proprietary compiler. I think that's a better example than Apple for this case. In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive-cobol-compiler/46686 http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Group) and PGI (The Portland Group).
  - dded 13y ago
    I'm not part of the Ada world, so I don't actually know, but I thought the important Ada compiler(s) were also proprietary.
    - jordigh 13y ago
      Ada is one of the poster children for early GPL success: https://en.wikipedia.org/wiki/GNAT#History https://en.wikipedia.org/wiki/GNAT#History They also sell GPL exceptions, which I think is a good thing: https://news.ycombinator.com/item?id=7027926 https://news.ycombinator.com/item?id=7027926
Devid2014 13y ago
IMHO GCC has already lost this batle. Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. GCC is just a compiler but Clang is much more as this is a very powerful compiler building library... If we talk about C++ then Clang already support C++14 but GCC still not. And yes License matters, GPL just does not allow to use GCC in most cases. But today one does not need GCC at all any more, there is Clang. gcc-xml was a hope many years ago but it just died, and today all this can be made much much easier and faster using Clang. Clang is standard on OSX. Some Linux distributions already switching to the Clang. Clang support for Windows is already on the way. So if nothing will be changes in GCC politics then it will become unnecessary in the future. Of course some will still use it but only as political reasons.
- vonbladet 13y ago
  > Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. By design. > And yes License matters, GPL just does not allow to use GCC in most cases. By design.
  - coldcode 13y ago
    At that rate GCC will eventually die in obsolescence. By design, apparently.
  - lucian1900 13y ago
    And esr is saying that perhaps it is (no longer) a good design.
jejones3141 13y ago
"I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more." Someone should tell Intel that. Don't they still do things to intentionally make AMD CPUs look bad?
ja30278 13y ago
I found the counter-argument made in the first reply to be more compelling. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.
- unmole 13y ago
  Hear, hear!
- deleted 13y ago
  [deleted]
- jjindev 13y ago
  This is a digression, but it is slightly more complicated. The top US software companies, by market cap, all use FSF tools, but then in turn decide their own separate levels of openness. Entrepreneurs here will use FSF tools, and then decide how far to open their own kimonos. The original FSF intent, that copyleft would provide contagion to a truly open world seems actually stalled. Apologies for the digression.
  - anon1385 13y ago
    It largely stalled because of the web. Lots of SV startups for example are using GPL'd code, but because they only provide web apps they don't have to release their code. Worse still those startups often think they are on the 'good' side of the free software debate because they use some open source code in their products and maybe even contribute a bit back. In my opinion the FSF screwed up majorly by concentrating on local software and the GPL while ignoring the much greater danger of software as a service. The AGPL is too weak and the FSF never really pushed it. The GNU project have tried to create some online services/protocols themselves but they are a total joke (e.g. GNU Free Call).
    - jjindev 13y ago
      But don't most people here, at HN, want that right to decide their own openness? I mean, does everyone here plan to do a web startup and then produce a tarball of [their] full work? A full DB API? I understand that we all, or most of us, have contributed to free or open projects, but I thought the pure-souls, without a little "IP" one way or another, were very rare.
fulafel 13y ago
Sounds like this was posted without reading the linked thread. He retracted the post in a followup as he didn't know about the GCC plugin system: http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html
asb 13y ago
The idea that the FSF (and perhaps more specifically, RMS) are holding back GCC technically due to concerns about people working around the GPL dates way back. As people have pointed out, GCC now has a plugin system but I imagine ESR is thinking back to exchanges such as this one, where RMS rejected the contribution of a Java bytecode backend to GCC purely on the grounds that it could be used with proprietary tools using the bytecode as an IR http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html
Fede_V 13y ago
I doubt ESR was genuinely interested in changing GCC policy - that seems to be like a well written piece of concern trolling. If you want to make suggestions, you discuss it politely with the stakeholders, you don't make intentionally provocative suggestions on a public mailing list.
teddyh 13y ago
I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. (https://news.ycombinator.com/item?id=6146066 https://news.ycombinator.com/item?id=6146066) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.
- justincormack 13y ago
  Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.
  - teddyh 13y ago
    The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.
    - asdasf 13y ago
      The open one would stagnate because it has over 3 times as many developers, writing over 3 times as much code? You seriously think that?
      - teddyh 13y ago
        No, I think that the proprietary one would get all the company contributors, and therefore have the lion’s share of developers.
        asdasf 13y ago
        The apple employees working on it are the minority, that is the point. If apple decided to have their employees work on a closed source fork, they would have less than 25% of the current developers of LLVM/clang working on their compiler. LLVM/clang would still have the other 75%+.
VikingCoder 13y ago
The best part: reading ESR call others ham-handed and counterproductive.
adamtj 13y ago
As I see it, the whole disagreement seems to stem from differing opinions about what happens when free/open software and non-free/closed software meet, and which is "stronger". FSF lives on an island and worries that even one contaminated inhabitant will infect everybody. They seem to hold that non-free is a contagious disease that will overtake and destroy their freedom. FSF is worried about diminishing: what they have is perfect and it can only be reduced. FSF are Tolkein's Elves. ESR would welcome contaminated people to that island, believing strongly in it's restorative properties. He seems to hold that open-source is more powerful and will stamp out closed software whenever they meet. ESR is worried about not expanding quickly enough and dying of stagnation. ESR would probably be Aragorn. That's how I see this argument.
Aqueous 13y ago
I see GCC as performing the necessary function of defining the radical antithesis to proprietary tools, historically like Think C, C++, Borland,and Metrowerks, and presents tools like Microsoft's Visual C/C++. Without GCC staking out the position it has clang wouldn't have its middle ground to stake out. The middle ground would instead be a lot more proprietary than it is now. Without Stallman being as radical as he is, there would be no Linus' who bridge the gap between completely free and completely proprietary software. There would be nothing to react to. Many wrongs actually do make a right, as long as we're all wrong in opposite directions.
bane 13y ago
Ugh, more free software vs. open source politics. In the interest of actually collaborating and getting shit done, I'd like "freedom" from all this nonsense please.
Someone 13y ago
"The clang developers very carefully do _not_ say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals" Beliefs don't need them, but I don't see a rational argument supporting that. IMO, clang developers just won't cripple their product to prevent the potential collateral damage to gcc.

149 points by wisesage5001 13y 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.

fafner 13y 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/ 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 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 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 http://gcc.gnu.org/wiki/JIT
- Raphael_Amiard 13y ago
  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.
  - fafner 13y ago
    > 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.
    - anon1385 13y ago
      >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?
      - belorn 13y ago
        http://gccxml.github.io/HTML/News.html 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.
Tuna-Fish 13y ago
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.
- fafner 13y ago
  > 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.
lmm 13y ago
> 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?
- fafner 13y ago
  > 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.
asdasf 13y ago
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.
- lazyjones 13y ago
  > 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.
  - anon1385 13y ago
    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 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/msg00008.html 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 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 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.
Nelson69 13y ago
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.
mcguire 13y ago
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?)

fhd2 13y ago

Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools. I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war? edit: I'm now aware that esr is not talking about license restrictions but technical restrictions here. I have yet to find any evidence of technical restrictions for political reasons though, and it looks like the folks responding to him on the mailing list are not sure what he means either.

Tuna-Fish 13y ago
No. It's not that at all. The GCC/LLVM debate has nothing whatsoever to do with licensing, but crippling the design of gcc for political aims. Educate yourself on the subject.
- fhd2 13y ago
  I can't claim to know anything about GCC's internals, but from what I know/read, it does have a plugin system and I don't see any indication of that being held back for political reasons (there are many other potential reasons for technical inferiority). And I don't see how the FSF could ever have furthered their political goals by making it technically hard to use GCC in free software tools, quite the contrary. Would be quite interested in evidence of that.
  - fhd2 13y ago
    I think I get what you mean now, you said above that GCC doesn't want to give external tools access to intermediate formats. But is that really the "anti plugin policy" esr is talking about?
  - asdasf 13y ago
    https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00008.html https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00... RMS says "freedom" is worth sacrificing functionality for. GCC is a monolithic mess of shit that is virtually impossible to debug, and produces incorrect code very frequently. Being forced into a terrible architecture where everything is smushed into everything else just to prevent people from being able to use gcc as a front end and something else as a backend is absolutely a case of making the code worse for the sake of trying to further a political agenda.

zombie_hitler 13y ago

esr trolling the gnu mailing lists...

ahazred8ta 13y ago

ESR may be incorrect; GCC has a plugin system. (YMMV) http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html / http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html

Tuna-Fish 13y ago
However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.
- iso-8859-1 13y ago
  is it at least stable across patch levels?
- Shamanmuni 13y ago
  There's a reply to esr by Alexandre Oliva which touches this point. I'll quote what he says: "That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it up-to-date". I don't know about the subject but it seems a quite reasonable stand and it certainly doesn't hinder the Linux kernel development, I don't see why it wouldn't work in GCC.
  - bjourne 13y ago
    I believe he is talking about different kind of plugins. For example, suppose you are an editor and you want to syntax highlight c source code. You could then feed .c files to clang, get back a parsed ast and use that for awesome syntax highlighting. You can not do that with gcc and the fsf does explicitly not want you to be able to. Because you could then be writing a non-free editor to take advantage of and using gcc as a free front-end.
    - 13y ago

crististm 13y ago

ESR is comming hard on FSF to what is actually embracing "open source" movement. His arguments are technical only as a means to hide the politics. This is not going to happen. I think David Kastrup's reply was pretty clear in that sense. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html

e12e 13y ago

As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, inferior ABI for the sake your proprietary crap -- share or GTFO (And it's easier for everyone if we can just see your code, bugs and all)"). However, isn't this paragraph: "I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course." proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially) doing? I know Apple makes great contributions to (among other projects, clang) -- but is upstream clang the same as what comes with Xcode?

dalke 13y ago
As one of the commenters points out, Intel continues to develop a proprietary compiler. I think that's a better example than Apple for this case. In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive-cobol-compiler/46686 http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Group) and PGI (The Portland Group).
- dded 13y ago
  I'm not part of the Ada world, so I don't actually know, but I thought the important Ada compiler(s) were also proprietary.
  - jordigh 13y ago
    Ada is one of the poster children for early GPL success: https://en.wikipedia.org/wiki/GNAT#History https://en.wikipedia.org/wiki/GNAT#History They also sell GPL exceptions, which I think is a good thing: https://news.ycombinator.com/item?id=7027926 https://news.ycombinator.com/item?id=7027926

Devid2014 13y ago

IMHO GCC has already lost this batle. Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. GCC is just a compiler but Clang is much more as this is a very powerful compiler building library... If we talk about C++ then Clang already support C++14 but GCC still not. And yes License matters, GPL just does not allow to use GCC in most cases. But today one does not need GCC at all any more, there is Clang. gcc-xml was a hope many years ago but it just died, and today all this can be made much much easier and faster using Clang. Clang is standard on OSX. Some Linux distributions already switching to the Clang. Clang support for Windows is already on the way. So if nothing will be changes in GCC politics then it will become unnecessary in the future. Of course some will still use it but only as political reasons.

vonbladet 13y ago
> Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. By design. > And yes License matters, GPL just does not allow to use GCC in most cases. By design.
- coldcode 13y ago
  At that rate GCC will eventually die in obsolescence. By design, apparently.
- lucian1900 13y ago
  And esr is saying that perhaps it is (no longer) a good design.

jejones3141 13y ago

"I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more." Someone should tell Intel that. Don't they still do things to intentionally make AMD CPUs look bad?

ja30278 13y ago

I found the counter-argument made in the first reply to be more compelling. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.

unmole 13y ago
Hear, hear!
deleted 13y ago
[deleted]
jjindev 13y ago
This is a digression, but it is slightly more complicated. The top US software companies, by market cap, all use FSF tools, but then in turn decide their own separate levels of openness. Entrepreneurs here will use FSF tools, and then decide how far to open their own kimonos. The original FSF intent, that copyleft would provide contagion to a truly open world seems actually stalled. Apologies for the digression.
- anon1385 13y ago
  It largely stalled because of the web. Lots of SV startups for example are using GPL'd code, but because they only provide web apps they don't have to release their code. Worse still those startups often think they are on the 'good' side of the free software debate because they use some open source code in their products and maybe even contribute a bit back. In my opinion the FSF screwed up majorly by concentrating on local software and the GPL while ignoring the much greater danger of software as a service. The AGPL is too weak and the FSF never really pushed it. The GNU project have tried to create some online services/protocols themselves but they are a total joke (e.g. GNU Free Call).
  - jjindev 13y ago
    But don't most people here, at HN, want that right to decide their own openness? I mean, does everyone here plan to do a web startup and then produce a tarball of [their] full work? A full DB API? I understand that we all, or most of us, have contributed to free or open projects, but I thought the pure-souls, without a little "IP" one way or another, were very rare.

fulafel 13y ago

Sounds like this was posted without reading the linked thread. He retracted the post in a followup as he didn't know about the GCC plugin system: http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html

asb 13y ago

The idea that the FSF (and perhaps more specifically, RMS) are holding back GCC technically due to concerns about people working around the GPL dates way back. As people have pointed out, GCC now has a plugin system but I imagine ESR is thinking back to exchanges such as this one, where RMS rejected the contribution of a Java bytecode backend to GCC purely on the grounds that it could be used with proprietary tools using the bytecode as an IR http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html

Fede_V 13y ago

I doubt ESR was genuinely interested in changing GCC policy - that seems to be like a well written piece of concern trolling. If you want to make suggestions, you discuss it politely with the stakeholders, you don't make intentionally provocative suggestions on a public mailing list.

teddyh 13y ago

I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. (https://news.ycombinator.com/item?id=6146066 https://news.ycombinator.com/item?id=6146066) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.

justincormack 13y ago
Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.
- teddyh 13y ago
  The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.
  - asdasf 13y ago
    The open one would stagnate because it has over 3 times as many developers, writing over 3 times as much code? You seriously think that?
    - teddyh 13y ago
      No, I think that the proprietary one would get all the company contributors, and therefore have the lion’s share of developers.
      - asdasf 13y ago
        The apple employees working on it are the minority, that is the point. If apple decided to have their employees work on a closed source fork, they would have less than 25% of the current developers of LLVM/clang working on their compiler. LLVM/clang would still have the other 75%+.

VikingCoder 13y ago

The best part: reading ESR call others ham-handed and counterproductive.

adamtj 13y ago

As I see it, the whole disagreement seems to stem from differing opinions about what happens when free/open software and non-free/closed software meet, and which is "stronger". FSF lives on an island and worries that even one contaminated inhabitant will infect everybody. They seem to hold that non-free is a contagious disease that will overtake and destroy their freedom. FSF is worried about diminishing: what they have is perfect and it can only be reduced. FSF are Tolkein's Elves. ESR would welcome contaminated people to that island, believing strongly in it's restorative properties. He seems to hold that open-source is more powerful and will stamp out closed software whenever they meet. ESR is worried about not expanding quickly enough and dying of stagnation. ESR would probably be Aragorn. That's how I see this argument.

Aqueous 13y ago

I see GCC as performing the necessary function of defining the radical antithesis to proprietary tools, historically like Think C, C++, Borland,and Metrowerks, and presents tools like Microsoft's Visual C/C++. Without GCC staking out the position it has clang wouldn't have its middle ground to stake out. The middle ground would instead be a lot more proprietary than it is now. Without Stallman being as radical as he is, there would be no Linus' who bridge the gap between completely free and completely proprietary software. There would be nothing to react to. Many wrongs actually do make a right, as long as we're all wrong in opposite directions.

bane 13y ago

Ugh, more free software vs. open source politics. In the interest of actually collaborating and getting shit done, I'd like "freedom" from all this nonsense please.

Someone 13y ago

"The clang developers very carefully do _not_ say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals" Beliefs don't need them, but I don't see a rational argument supporting that. IMO, clang developers just won't cripple their product to prevent the potential collateral damage to gcc.