It is not GPL3 licensed. Most of the projects that have moved from gcc to llvm did it because of the license not for technical reasons.
That isn't to say there are not technical reasons to say llvm is better - there are good ones. However they are not compelling like the license is. Llvm has a better internal design which should be better long term, but so far gcc generally compiles faster code which is for most people more important that internal design.
Note that linux distributions are mostly built by the types of people who like the GPL3 license. Using gcc is the correct decision for most linux distributions.
Am I understanding it correctly that you're saying those projects switch because of the license of their compiler?
As far as I know the GPL doesn't "infect" the program compiled with a GPL-licensed compiler, I can have my proprietary binary-only software compiled with the GPLed gcc just fine...
It's a factor if you're writing a compiler for a new programming language. LLVM has been a pretty common target for that (see also: Julia and Rust) both for technical reasons and because it means the language itself can be released under a non-GPL license.
It's also a factor if you're distributing a compiler with your operating system. This has already driven FreeBSD (IIRC) to LLVM, and OpenBSD is starting to adopt it for a few platforms (GCC is still required due to certain OpenBSD targets that aren't supported by LLVM, but if that's ever fixed - whether because OpenBSD drops those targets or because LLVM eventually supports them - then I'd be very surprised if a switch doesn't happen for all platforms).
Yes. Apple (NeXT at the time) had to make their objective-c frontend for gcc GPL, and they did not like that. that is why apple spent a lot of money making clang good: it allows them to do have patches they don't want to make available why still getting a good compiler. (I don't know if those patches exist, but they have that ability if they want it)
*BSD has in generally hated having anything GPL in their base system. OpenBSD played with creating their own C compiler for a while (the goal was just a compiler with only minimal optimizations - they expected everyone would just use that to build gcc and then build everything with gcc)
It's widely viewed as better designed (though that's obviously somewhat subjective); it's more modular, and a lot of innovative work on optimization now happens there rather than in GCC.
The "licensing" and "better design" arguments are not really compelling. As for "licensing", basically no commercial operating system distribution ships the compiler in the base system. As for "better design", LLVM still doesn't generate code as well as GCC, especially for the kernel; but over the years as the codegen has become better, the performance has come down to match GCC. LLVM has some pinhole optimizations which don't exist on GCC, and some slightly different behaviours around exotic non-standard types, but they are largely becoming the same compiler.
Turns out that GCC is actually really fast for the quality of the code it generates, and Clang/LLVM take almost exactly the same amount of time to generate similar code.
Licensing was THE reason Apple didn't update their GCC version in Xcode and switched over to Clang/LLVM. IANAL and my history is a bit hazy but the things that Apple wanted to support and the way they wanted to go about doing it was not compatible with the GPL.
Apple first used LLVM for their graphics stack, and it became more attractive to them because of the JIT stuff. Bringing Clang along is more or less an artifact of that. Maybe they weren't interested in GPLv3 since the tivoization clause prohibits them from distributing the compiler on devices which can't be flashed, but I don't think it's exactly rational. They also don't update the version of Emacs that they ship, and there you could make the argument for it since it ships with the operating system.
They wanted the freedom to make the base system read only, and I get that, but if LLVM weren't there they would be shipping GPLv3 GCC and Emacs 25.
> tivoization clause prohibits them from distributing the compiler on devices which can't be flashed
The tivoization clause has an explicit exception that allows for devices which can't be flashed. What the clause prohibits is the case when devices can only be flashed if you got the right developer password, and the publisher deny the owner of the device to have that password.
rms used to tell a story about NeXT approaching him to come to a deal to throw money at the FSF in order to avoid having to open source the Objective C gcc toolchain. The FSF (predictably) refused.
I wouldn't be surprised if the decision to go all-in on Clang was a reaction to a decade old grudge.
While I'm sure there would be benefits to LLVM from having such a well funded depend on it, the kernel has driven a lot of patches for GCC, I imagine the kernel would benefit more. Here is a list of advantages copy and pasted from llvm.linuxfoundation.org
Why use Clang/LLVM with the Linux Kernel?
Fast Compiles (making you able to work faster)
LLVM/Clang is a fast moving project with many things fixed quickly and features added.
LLVM is a family of tools used in many problem domains leading to one code base being able to build tools to work on just about anything you need: one place to add features, or fix bugs.
BSD License (some people prefer this license to the GPL)
Built in static analyzer
Great error reporting and Fix-it hints
LLVM technology can be embedded into many tools (even yours!)
Already in wide used in OSS projects and in industry
It leads to lock-ins, like the current kernel is locked into GCC. Some of those GCC Extensions used are effectively proprietary because "the code is the documentation" so nobody can replicate it for their own compiler.
But only supporting one compiler has the advantage that you're aren't limited to the lowest common denominator of compiler features.
You'll notice this especially with C++ codebases which try to support GCC, Clang, Intel and Visual C++. You'll need a lot of macros and workarounds for each compiler's quirks.
When I'm doing a new C project I usually go out of my way to make sure it compiles clean with GCC and clang. Each compiler has its strength and weaknesses. GCC tends to produce faster code in some situations where clang has great static code analysis tools and asan is amazing. I've heard GCC has made major improvements in build speed since the last time I've started a new C project from scratch but that used to be on my list of reasons too.
C can be a hard to wrangle beast and the more checks I have on my code quality the better I sleep at night.
At least from the outside, GCC asan seems comparable to clang's right now. I haven't done back-to-back checking to see if clang finds things it doesn't. I haven't really used the undefined and thread sanitizers though.
LLVM is an extremely open backend. So it can be used for many projects a short list of its usages:
* Compiling SPIR-V shaders to GPU executables
* Compiling C
* Compiling C++
* Compiling Rust
* Compiling Haskell
* Compiling Swift
* JIT compilers for databases
* JVM JIT
Effectively once you translate to LLVM-IR you are basically home free, the LLVM can handle the rest. Which means you have a board range of people providing optimization passes, and catching bugs.
---
With the GCC its IR is tightly coupled to the C front end. While there has been some decoupling, this is generally considered a feature as it doesn't allow for a corporation to _run away_ with part of the project.
---
The LLVM is more modular, you can pick and take what you need. You can embed it, or call it externally. It is a hybrid BST/MIT/X11 license so it is open source, and embedding it in your project doesn't mean your project becomes GPL'd.
more portability, and some of the santiziers that clang has (ubsan, asan). They have gcc equivalents or ports but being able to use more of these kinds of tools is a good thing in the end since it'll allow more bugs to be found without an exploit.
It means that you won't end up relying on a specific compiler's quirks or implementation of the language. You can expect different compilers to handle undefined behavior in different ways which will help you catch where you're doing things you shouldn't be. And since you're no longer relying on a single compiler you are more likely to be able to support other platforms and compilers that don't have a gcc port (they do exist, even if they aren't common).
Do they end up finding the same issues/bugs? I thought they didn't always find the same things last I tried using them, so I'd build in both compilers to end up running tests/checks.
