"The computer industry is the only industry that is more fashion-driven than women's fashion. " (Larry Ellison)

Right now LLVM is fashionable and gcc is not. Little details, as in actually generating better code, are minor in comparison.

- You can do cross-language LTO between clang and Rust

- You can cross-compile from anything to Windows. (To MSVC ABI!)

Performance isn’t one global thing. For some projects it’ll be better, for some it’ll be worse (based on my personal experience).

Clang has much better error reporting and warnings. It's maybe not enough to switch completely, but worth it to compile in both compilers to catch more bugs. Then you can still release the binaries that are faster and throw away the binaries that are slower.

Firefox isn't moving to build with both, though — it's moving to Clang exclusively. It will not get the best of both worlds.

The difference isn't that large anymore. gcc has also implemented color diagnostics and caret highlighting, and they have continuously added new helpful warnings, e.g. the upcoming -Winit-list-lifetime in gcc 9 (nothing comparable available for clang)

GCC implementation is gross and many compiler people prefer working on and with clang/llvm even if the generated code is inferior.

Despite many technical reasons, I think license is also one of the biggest motivations.

Though not for Firefox, certainly, whose own codebase is already less permissive and more copyleft (MPL) than LLVM.

How so? GCC can (and is) used to compile all sorts of proprietary software. I can't imagine a scenario where its license would be any kind of an issue with the toolchain of a Free project.

GCC was designed to be extensible and portable (after all it ended up ported to more architectures than any other compiler). The political limitation was more subtle.

Originally FSF did not want to make it easy let GCC store its intermediate language and read it back. That was because it would let others to build proprietary frontends and back-ends which is against RMS' vision. This has changed and LTO does precisely that (and indeed in addition to technical difficulties this political issue delayed its arrival in GCC). So this political block of extensibility is long gone (and I am happy for that).

A lot has changed in compilation between mid 1980's GCC was started and early 2000's. LLVM design reflects its time. Almost 20 years passed since that and both projects needs to evolve and develop strategies of doing so.

Regardless of the LTO relaxation, I believe it is still the position of the FSF and GCC that any middleware that links in to GCC itself is GPL-infected. Obviously, this is not the case for LLVM/Clang.

GCC was intentionally designed to be hard to extend with proprietary extensions (there's an email from RMS somewhere explicitly stating that)

Whereas llvm/clang was designed as a library to be open and extensible, which lead to a lot of tooling being built around it.

Unrelated to license, clang also has far better error messages than gcc.

> clang also has far better error messages than gcc.

This was true a number of years ago, but I believe GCC's diagnostics have gotten much better in response to competition and don't believe it to be true anymore (although my experience is with C code, not C++ — maybe Clang is better there).

Another distinction is that GCC continues to hold a significant lead in producing accurate debuginfo, which is invaluable to me as a developer.

I think both compilers give good error messages (C++14 and C++17). Sometimes one is clearer, sometimes the other, so what I usually do if I can't immediately figure out what the compiler is complaining about is to try the other one and see if that clears things up or at least narrows it down a bit. Works surprisingly often :)