Using LLVM As The Compiler Within Fedora?

[phoronix]

Phoronix: Using LLVM As The Compiler Within Fedora?

For those wanting to see another polarized discussion taking place within the Fedora camp, similar to the Fedora rolling-release discussion, drop by the mailing list...

http://www.phoronix.com/vr.php?view=MTA1ODA

[smitty3268]

There's 5 responses to the original post, which doesn't even advocate a switch to llvm - just wondering what the current status of llvm support in linux is.

The replies all basically come down to, "well, we'd have to have a reason to switch, like if it generated better code. and then someone would need to step up and do the work."

That's supposed to be polarizing?

[mark_]

I tried llvm/clang with several packages on my gentoo system and the result ist: there are many packages that rely on specific gcc behaviour or gcc specific extensions like this endless list: http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
So basically, many programs are not written in C anymore, but a GNU dialect. This means: those programs will not compile with clang without patching the usage of GNU extensions out of the code (or bringing those extensions to clang).
And even if a package compiles, there is no guaranty, that it will work afterwards without segfaults or other crashes (I had this especially with mesa/drivers/X).
This needs some enthusiasts (or linux developers) who compile everything with llvm/clang, test it and file bug reports to the projects, to llvm/clang and write patches to get rid of GNU extensions and bugs. Have fun :-)
BSD compiles the system with clang afaik, so my guess is: they have a more standard C codebase, some compatibility patches in other cases and thus no problems with clang.

and while there are many packages that can be compiled with clang, there are some essential packages that don't: glibc fails afair, the kernel does not support clang completely, Qt is not supported (changes with Qt 5 afaik), I had problems with X

[XorEaxEax]

There's 5 responses to the original post, which doesn't even advocate a switch to llvm - just wondering what the current status of llvm support in linux is.

The replies all basically come down to, "well, we'd have to have a reason to switch, like if it generated better code. and then someone would need to step up and do the work."

That's supposed to be polarizing?

Micheal is a huge proponent of LLVM/Clang, so he inflates anything regarding it. Whenever he brings LLVM/Clang up it's described as 'wildly popular' etc, and GCC at best as 'popular' despite it being the de facto standard compiler toolchain which pretty much the entire open source world relies on while LLVM being mostly used as a JIT solution (although a VERY GOOD solution) and Clang hardly used at all as it's still very immature. He has an agenda in his compiler reporting (and I'm guessing the poor quality of his compiler benchmarks is also a result of tailoring them to present LLVM/Clang as good as possible) and it's sad, that said it's not as if there has ever been anything even remotely objective about Phoronix reporting. This 'article' is just another piece of that LLVM/Clang propaganda.

[kraftman]

What a dumb article. There's nothing that even suggests they'll switch to that apple's crap. Not only it's usually much slower then GCC, but it can't compile many packages. Afaik apple can't ship with the latest GCC, so what's left for them? Slower and less mature llvm.

[curaga]

write patches to get rid of GNU extensions

The extensions are obviously useful, otherwise they wouldn't be used. I'm going to bet you'd have a hard time trying to convert some linux packages to more/worse code just to compile under clang.

[mark_]

The extensions are obviously useful, otherwise they wouldn't be used. I'm going to bet you'd have a hard time trying to convert some linux packages to more/worse code just to compile under clang.

I am not so sure of the usefulness; the extensions certainly make it easy for the programmer to implement something (and thus are useful from this point of view) but as we see now it complicates independance and portability, so there is a high price. As C is Turing complete, the extensions are not necessary and I personally would not want to pay that price of compiler dependence to make some coding techniques a bit easier. In fact, I never had a deeper look at the gcc extensions, always used standard C, never missed something and my code is portable.
I agree that converting the affected linux packages is hard, but I see it as an improvement in code quality, not as more/worse code - where is the freedom in free software if I cannot choose my favorite compiler? ;-)
I hope, Fedora succeeds.

[XorEaxEax]

Of course they are useful, and the reason they were added was at the behest of programmers so it's obvious that they will be used. Many if not the vast majority were added at the request (to put it mildly) of kernel devs who wanted better control of the resulting code (mainly in order to improve performance) than what C can in itself offer without having to resort to assembly code.

I can't recall ever having use of anything other than the gcc vector type extensions but I have also never written anything remotely as low level as a kernel, drivers, etc. And your argument that they 'aren't necessary' holds no water as it's up to the programmers decide what is necessary. Is C99 necessary? C11? C++11? Should programmers not use the features offered by them if their compiler supports it because say VS2010 doesn't support them fully? The argument is even more hollow when you take into account that anyone can download GCC and use it for free.

And for the record Clang supports lots of extensions, so it's not 'pure' by any means. And I'm certain that eventually it will support all extensions necessary for it to compile the Linux kernel without having to rewrite the kernel code which is what the BSD devs had to do to it to compile with Clang/LLVM. For them it was obviously worth it as they were stuck with shipping GCC 4.2.1 due to refusing GPLv3 and also because of them identifying themselves with the BSD licence. Obviously there are no such issues for the Linux kernel and it's software ecosystem so for them it's a practical/technical issue and I've seen no indication of the kernel devs being interested in removing compiler extensions from their code.

That said I don't mind the possible rewriting of code without extensions as long as it doesn't impact the performance which is (most likely) why they were used in the first place and thus unlikely to happen, of course again the BEST solution is if Clang/LLVM simply adds the same extensions and thus became fully compatible with GCC, it's not as if the extensions are proprietary.

And you can certainly use your favourite compiler, however what you are proposing is that other people shouldn't be able to use all the features made available of _their_ favourite compiler just so that you can compiler their code with _your_ favourite compiler because it doesn't support the same range of features.

[Sidicas]

Of course they are useful, and the reason they were added was at the behest of programmers so it's obvious that they will be used. Many if not the vast majority were added at the request (to put it mildly) of kernel devs who wanted better control of the resulting code (mainly in order to improve performance) than what C can in itself offer without having to resort to assembly code.

I agree... Just like any product, it needs to meet the needs of the users (programmers) or they'll find something more appropriate to use.

Last I heard, LLVM/Clang was a *long* way away from being able to compile the entire Debian repository.. So until then, I think it's pretty silly to be discussing it as a replacement for GCC. If GCC provides extensions / features that kernel developers want and LLVM/Clang doesn't, then LLVM/Clang is going to need to find a way to provide equivalent or better functionality.. Forcing the programmers to use assembly where they didn't before is not a solution. GCC will be around for a long time.

[mark_]

XorEaxEax: The essence of your posting is, that the gcc language set has to be treated like a language standard (which it is NOT; it might barely be an unofficial one). So every programmer that uses these extensions, forces the users to use that compiler too and depending on your definition of freedom, this makes the users less free than before (example: the BSD guys). This is equal to like using a non standard library in your program (think of early KDE days: KDE was free, Qt was not).

I claim that it might be very convenient for the programmer to choose such extensions, but as I said, there is a price.
If you stick to the standard, you don't pay the price and your users don't pay it either. I don't think, that there are really good technical reasons for using the gcc extensions, BSD obviously works without them and I bet their code and their performance did not get worse.

Btw, just for fun let's exaggerate your argument, that gcc is free and therefore implementing a dialect is ok:
What if I write 100 free programs and you want to use them all, but every program uses another, free language with it's own free compiler... it is nice to install 100 compilers to compile 100 programs, isn't it? If you had the choice, you would never use these programs of mine. Do you see the importance of standards? If you needed to prove the correctness of a program you would hate every single version of all compilers that differ from the standards in any way (like bugs or even convenient extensions, compare it with http://lwn.net/Articles/478657/; could be a bug or an extension or whatever... anyway, it breaks code as it is not standard, so it is good to use another compiler... oh wait).

So: if you want to justify excessive use of a language extension to me, create an official standard like GNU C first. Then your program uses GNU C which is not C and then I have no problem anymore, if clang cannot compile your code.