See, when a daddy loves a mommy very much, they usually get married. However, sometimes the daddy meets another woman, who is faster, uses less memory, with a significantly less complicated code base, and then the daddy decides to compile his Linux with her instead.

Does that help?

Daddy is a dick, he and mommy have grown up together. They share their complex internals with each other and were made for each other. They share even their philosophical stance on code freedom. How can you turn your back on that. Why jump to another woman just because she is thinner and more in demand with with researches?

> They share even their philosophical stance on code freedom

arguable.

BSD and commercial Unices used PCC and PCC derivitives for much of their history; by this token, GCC is the 'other woman', and this is itself ignoring the clear differences in philosophy between MIT/BSD and GPL licening

But this is about Linux.

doh. good point :)

Well, I did say ELI5. So, thanks, um, I guess.

I do strive to be age-appropriate!

> with a significantly less complicated code base

This is probably not true (because clang is in C++ it can't be less complicated than anything), and gcc is complicated in some parts because it uses much better algorithms (the LLVM register allocator is not as good as LRA). LLVM also has some very ugly DSLs like the .td files.

But GCC's codebase does have lots of added complexity from the extremely weird GNU coding style where they want you to pretend you're writing Lisp and all commits have to update a changelog file. Plus terrible GNU software like autotools and recursive make.

I like autotools. So much better than cmake.

Clang has some code base and speed advantages, but the big reason the large players like Apple are grabbing onto it is licensing. A lot of companies really want to move away from any GPL stuff. It's sad since so much of what we have in the Linux ecosystem came from GNU.

They want to get rid of Stallmann's GNU concepts

Which is always ironic, given that without Stallmann's GNU concepts, Linux would never have happened.

And most likely, given the BSD state back then, it would mean we would just keep using either commercial UNIXes, or Windows would have won the UNIX wars.

But lets get rid of Stallmann's GNU concepts.

> given the BSD state back then

you mean being persecuted by over-bearing commercial unices? (e.g. SVr4 and ATT)?

lets not mis-confuse the issues to our personal ends - the argument is just as valid that without BSD UNIX, stallman would also not have a system to base a clone on..

GNU attempts to redefine the existing cultural status quo of open-source software dating from the dawn of computing to its own personal ends

Sure they had a system, commercial UNIXes would been kept being used.

GCC only got manpower when Sun changed the way UNIX SDK used to be given to customers.

And who knows, maybe companies would have been more willing to dedicate manpower to HURD.

Now they just need to replace the kernel and almost all of the remaining userland.

Ah... thx. Found this article by Stallman that gives some context to that:

https://www.gnu.org/gnu/thegnuproject.en.html

I thought it was the *BSD folks who were known for insisting on that. Does, e.g. the NetBSD kernel build cleanly with clang?

Of course https://wiki.netbsd.org/tutorials/clang/

Though NetBSD is a bit behind on switching to the LLVM toolchain, here's a recent update https://blog.netbsd.org/tnf/entry/final_report_on_clang_lld

Meanwhile FreeBSD (on amd64, i386, armv6/7, aarch64) has been buildable with clang since some point in 9.x (2012-13), comes with clang only since 10.0 (01.2014), and since 12.0 the bootstrap linker on amd64/i386/armv7 is LLD (which was the case on aarch64 from the beginning iirc)

That's quite a strong and completely unfounded accusation.

Good riddance

Really? I would prefer more things were GPLv3/AGPLv3. Open source today is just a bunch of middleware, but few end products. People today use open source software to build closed source solutions. It's a far cry from what a lot of us envisioned back in the 90s. I wrote about this before:

https://penguindreams.org/blog/the-philosophy-of-open-source...

Compiling things with clang is faster and uses less memory.

Linux distros, package repositories, etc. are basically giant compilation farms, compiling packages making sure they work well together so that you don't have to.

So switching to clang might impact their resource usage.

---

For you, the user, the performance of binaries compiled with GCC or clang is pretty much on par. Some binaries are a bit faster with clang, others are a bit faster with GCC, often in negligible ways.

If you are doing something that's very resource intensive, recompiling that software yourself tuning it to your use cases is probably going to have a much larger impact on resource usage than whether the shipped package was compiled with gcc or clang.

Apart from compiler redundancy, it eliminates the usage of vendor (GCC or Clang) extensions and UB that the two compilers don't agree on.

Edit: last I checked (more than two years ago), GCC was faster on more micro-benchmarks.

How does choosing one compiler over another "eliminate use of vendor extensions and UB"? Whatever compiler is chosen you'll have as much UB and as many extensions to deal with, as if the other one had been chosen.

Provided you have good code coverage, you'll pick up any UB that falls outside the intersection by running tests on both compilers.

Dependency on a specific toolchain is bad for the ecosystem.

The existence of a distribution using Clang for building itself makes the ecosystem way stronger.

It's not great news. GCC is basically better in every way.

People promote Clang because it has a permissive license and opens the door for Google and Apple to inject proprietary crap into Linux.

Does GCC have a decent WebAssembly backend?

Looking around just now, there's what seems like an initial experiment from someone, but it doesn't seem to have gone anywhere. :(

https://sourceware.org/ml/binutils/2017-03/msg00044.html

Asking because with the LLVM 8.0.0 release (a few months ago) it's one of the standard supported architectures.

No, GCC has serious shortcomings in certain areas. -flto=thin is better, autofdo/bolt is better, the jit is better, but the most important point are C constexpr which are implemented as in C++, but with GCC you cannot decide at compile-time if a constexpr is constant, so it misses out on many optimizations. It only has _Static_assert, but no usable __builtin_constant_p. With GCC it errors at compile-time, with clang it returns 0. clang also has diagnose_if, e.g. to match user-defined compile-time warnings with user-defined run-time warnings.

e.g. the clang memcpy can be 100x faster than the gcc memcpy, when the size and alignment is known.

And gcc-9 added serious regressions on some platforms, that you need to blacklist it. gcc-10 probably not being better.

I have to disagree, -flto=thin is faster in compile time, but in performance I get better results with -flto=n in GCC.

Also with FDO I get better results with GCC over Clang/LLVM, my main test subjects are rendering (Blender), archivers, encoders and emulation.

However with straight up -O2/-O3 I very often get better performance with Clang/LLVM. I haven't benchmarked on ARM though, my results may be very different there.

Where do clang and gcc implement memcpy? That's part of the C library.

> opens the door for Google and Apple to inject proprietary crap into Linux

This doesn't make sense. You can compile proprietary code with gcc without problems already. Clang doesn't enable anything new here.