This is not going to happen. I think David Kastrup's reply was pretty clear in that sense.
Clang and FSF's strategy
21–30 of 143 posts
Re: Clang and FSF's strategy
#22ESR 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.
Re: Clang and FSF's strategy
#23ESR 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.
"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
#24Earlier 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?
Looks quite dead to me, and I recall reading that the author do not recommend using it anymore.
Re: Clang and FSF's strategy
#25Earlier 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…
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
#26However, 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
#27esr 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…
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
#28So 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
#29Someone should tell Intel that. Don't they still do things to intentionally make AMD CPUs look bad?
Re: Clang and FSF's strategy
#30Earlier 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…
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.