Live data from Hacker News

Clang and FSF's strategy

gcc.gnu.org

21–30 of 143 posts

Re: Clang and FSF's strategy

#22

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/msg00181.html

However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.

is it at least stable across patch levels?

Re: Clang and FSF's strategy

#23

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/msg00181.html

However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.

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.

Re: Clang and FSF's strategy

#24
post #14

Earlier quoted context omitted.

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

Re: Clang and FSF's strategy

#25
post #6

Earlier quoted context omitted.

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…

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…

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.

Re: Clang and FSF's strategy

#26
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?

Re: Clang and FSF's strategy

#27
post #6

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 wit…

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…

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.

Re: Clang and FSF's strategy

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

Re: Clang and FSF's strategy

#29
"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?

Re: Clang and FSF's strategy

#30

Earlier quoted context omitted.

However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.

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 u…

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.

Post reply on HN