Hacker News Reader

Comment by tyingq | Hacker News Reader

I don't know the whole space well, but there are posts about FreeBSD and IBM today moving to clang.

Is there some tipping point where gcc has too few significant end users to stay relevant? I'd hate to lose the diversity.

View on HN

It's unlikely as up until now it was the only compiler capable of building the Linux kernel (due to its reliance on some GCC extensions to the language).

It is primarily non-GPL platforms/systems/companies that are switching to clang for it's much friendlier license.

Edit: "~now" rather than "now"

That's part of why I ask. As of late last year, clang can compile x86_64 Linux 5.x kernels.

Building the kernel with clang has been possible or a while. https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNote...:

"With support for asm goto, the mainline Linux kernel for x86_64 is now buildable (and bootable) with Clang 9. Other architectures that don’t require CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips) have been supported with older releases of Clang (Clang 4 was first used with aarch64).

The Android and ChromeOS Linux distributions have moved to building their Linux kernels with Clang, and Google is currently testing Clang built kernels for their production Linux kernels."

That was in September 2019

Yes, I consider within the past year to qualify as "now," but I've updated my post :)

Within the past year is more nuanced. Clang was building working kernels since clang-4. X86 developers decided to require asm goto around Linux 4.20, which regressed clang builds for one architecture, until clang-9 implemented it. You could still build LTS kernels without asm goto.

Clang can't compile glibc which actually a bigger problem.

In my opinion it's also time to move on from glibc.

>Is there some tipping point where gcc has too few significant end users to stay relevant? I'd hate to lose the diversity.

Yes. There will be a tipping point, as with any economic theory of sustainability. No, we wont reach that tipping point in the foreseeable future. It is still extremely widely used, and continue to be actively developed.

LLVM and GCC will likely enjoy duopoly in the Open Source Space for a very long time.

Gcc is still the default on GNU/Linux systems which are orders of magnitude more mainstream than FreeBSD.

So what? Clang under OSX compiling both OSX and iOS projects is far more widespread.

On computers-with-keyboards, maybe, probably even.

On a per-kernel basis, absolutely not, even before we consider Androids.

> The Android and ChromeOS Linux distributions have moved to building their Linux kernels with Clang, and Google is currently testing Clang built kernels for their production Linux kernels."

https://en.wikipedia.org/wiki/List_of_products_based_on_Free...

You have no idea how many places FreeBSD actually runs in.

Google uses Clang to build the kernel for Android.

Which is interesting but hardly relevant.

To quote:

> > Gcc is still the default on GNU/Linux systems which are orders of magnitude more mainstream than FreeBSD.

> So what? Clang under OSX compiling both OSX and iOS projects is far more widespread.

I'm asserting that there are more Linux kernels compiled under GCC than there are OSX kernels running Clang (so macOS) compiling OSX and iOS projects.

I think that's on pretty solid ground.

Clang is required for all of Android including Linux kernels going forward. Once devices start to age out, this will tip over time.

It doesn't increase the number of macOS kernels, or decrease the number of Linux servers (including virtualized ones, which seems fair), so I doubt it tips the balance.

All I'm saying is that, because of servers, there are more GCC'ed Linux kernels than there are Clang'ed macOS kernels, and this will probably remain true indefinitely.

If AWS starts Clangin' on their Linux kernels, then maybe not. The trend toward Clang is pretty clear at this point; could happen.

Fair point. Google is close to shipping clang built Linux kernels in their data centers (usable VM images for external users already are), but Amazon and Microsoft both have very large clouds as well. I'd guess it's still way less than mobile devices, but I don't have a good sense for how the numbers compare in terms of number of devices in existence for mobile va cloud.

Not on Android, which is an order of magnitude more mainstream than any other Linux distribution.

Without clang we would still have terrible compile error messages.

As clang implements more and more of GCC's extensions, though, I could see things reaching that tipping point.

And without a GPL compiler, we will be back to the PD and *ware days.

Sony, Apple, IBM, and plenty of other embedded vendors don't contribute 100% their improvements back to LLVM.

Apple does like 80% of the open source development of LLVM; I don't really see a valid angle to criticize their participation in LLVM at this time.

Except that they happen to have an actual portable variant of bitcode for watchOS, their clang implementation different enough from mainline clang to warrant its own column on cppreference compiler listing, and Objective-C and Swift related changes are on "just what you need to know" basis and the community should put the missing pieces.

Personally I don't care, as I am mostly a commercial software user nowadays.

Just making the point that LLVM victory over GCC, might not turn out as FOSS supporters expect.

Apple Clang gets its own column because it doesn't align with the official LLVM release schedule, which is also why it doesn't use the upstream version numbers.

That does not make sense. They could simply use the LLVM version, even if it was an old one.

I just implemented a GNU C extension in Clang today! `asm inline`

FreeBSD has been using Clang as the default build system for x86/64 since.. 2012? Version 10.0 IIRC. Not sure about mips, sparc, power but think they moved previously as well?

powerpc64 switched over in late December; sparc64 never made the switch (unfortunately), and mips will make the switch with the introduction of llvm 10.

IIRC powerpc32 is currently using clang with old bfd ld, but lld in llvm 10 may be quickly reaching the point where it's suitable for powerpc32 as well.

> sparc64 never made the switch (unfortunately)

Care to elaborate?

We're maintaining sparc64 in Debian Ports and we have smashed quite a number of bugs in the SPARC backend in LLVM.

Are there any issues you are seeing?

This is specifically w.r.t. FreeBSD -- nobody put in the effort to maintain it, so it's removed in head/ as of now. As far as I'm aware, no one had tested sparc64/llvm on FreeBSD either.

I see, thanks. I know the NetBSD guys are still working on their sparc64 port.

10.0, 2014 for amd64/i386. Much later for MIPS and Power (within the last year). Sparc was deorbited as part of the GCC4.2.1 retirement effort — no one showed up to implement Sparc support in Clang, and the version of Sparc hardware FreeBSD ran on was extremely obsolete anyway.

> Sparc was deorbited as part of the GCC4.2.1 retirement effort — no one showed up to implement Sparc support in Clang, and the version of Sparc hardware FreeBSD ran on was extremely obsolete anyway.

What's missing for sparc64 in Clang? We have Clang on sparc64 in Debian Ports.

> What's missing for sparc64 in Clang?

My memory here is fuzzy because I'm very much not interested in Sparc, but, as far as technical shortcomings: there are integrated-assembler (ias) pieces missing; ld.lld support is extremely incomplete; it's missing a working stack unwinder. If you look for Sparc work in Clang upstream, it becomes obvious that it's not active.

The biggest thing missing was interest (and associated time and resources). People have had 6-12 months to step up if they wanted to work on moving platforms off of GCC4.2.1, and unlike for every other tier 2-3 arch formerly on GCC, no one showed up to work on Sparc.

> We have Clang on sparc64 in Debian Ports.

As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang?

Here's some more context around missing pieces:

https://svnweb.freebsd.org/base?view=revision&revision=35446...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233405

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236839

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239851

> As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang?

Initially, we were building Clang only. But we're also now building Clang using itself, i.e. a stage2 compiler.

There are issues though when building Clang with Clang with Gold as the linker. It works fine with BFD though.

We are not building the whole archive with Clang though. But all Rust packages are built on sparc64 as well which uses the LLVM backend.

Thanks for the links. I'll look into them. Maybe we find some more bugs than can be fixed on SPARC in LLVM/Clang.

Edit: From your first link:

> "Contemporary GCC does not build and there is currently no indication that anyone is going to address these issues."

That's odd. We're building all GCC versions on Debian/sparc64. It's still a maintained backend in GCC, after all.

We used to celebrate alternatives to gcc in the name of compiler diversity, and now we're wondering about gcc preservation in the name of compiler diversity.

This is mostly just an observation, I'm not sure how I feel about it. Compiler diversity doesn't seem more important than OS diversity to me, and none of these feel particularly important. As a user I was happy to switch to clang for the better error messages.

As other top-level posts have pointed out they're only removing it from the build process, it's still available to users. I wouldn't worry too much about about GCC going away, it's still the default compiler for most (all?) Linux distros.

It was removed from the operating system. As with most operating systems, nothing prevents users from installing third-party software including GCC.

I don't think your question is meaningful in light of why GCC exists at all. It was created to enable people to write free software and, along with binutils, it's hard to imagine any software that's been so profoundly influential in the free and open source software that we have today.

I think GCC will remain relevant for as long as there are people who care about free software.

What does that "diversity" actually gain you? LLVM is very modular so a clang monoculture won't stop competing optimisations etc. being developed, and its license is suitable for most uses.

- The GPL license for GCC is valuable for free software rights.

- just like chrome becoming the only browser, one compiler isn't good either. The implementation starts to define the language instead of the standard

- separate projects can use different methodologies and tradeoffs.

- if there is a bug or exploit that only applies to that complier and not all programs

I don't think we should have 20 major C++ compilers but we shouldn't have one.

> The GPL license for GCC is valuable for free software rights

Apparently not in practice, because LLVM's copyleft license hasn't stopped large amounts of free software from being created (for example, rustc).

The ObjC frontend was only released because Apple got sued for infringing on the GPL.

Fewer people suing each other seems better in my opinion.

How about you comply with the terms of the licence if you don't want to be sued?

But if you use a permissive licence there's no need for anyone to sue anyone at all. Seems a better situation for everyone involved?

Isn't that essentially saying "If nothing were illegal there wouldn't be anyone in prison"?

No it's essentially saying if projects like GCC published permissively we could all get along peacefully and wouldn't need to batter each other using the courts.

The issue there is it removes freedoms from your end users. Now there's a multitude of binary distributions of LLVM, and users can't mix and match pieces of them.

Except one of the things a "permissive" license allows that the "restrictive" GPLv3 doesn't is locking code behind patents.

Companies like Apple prefer BSD specifically because they want the option of taking someone to court if they want to.

LLVM recently re-licensed to the Apache License (v2) which explicitly provides relevant patent grants on contributed works to consumers of the software.

If GCC had been more permissively licensed then Apple would not have released its Objective C compiler, which would have been a worse situation for everyone involved (to include Apple: they are simply wrong that a proprietary compiler is better for them).

GPL tries to make the world better, by increasing the free software commons. BSD tries to be neutral, but one should not be neutral in a war of good vs. evil: (cf. Ireland, Spain, Sweden & Switzerland in the Second World War or Sweden during the Cold War).

And that, along with FSF's earlier refusal to accept patches to let gcc build for the Mac, may be the reason LLVM got the support it did. Two egotistical jerks butt heads, and then one of them found a billion dollars at his fingertips.

Do you have a link to that discussion?

Like gcc has built on mac for longer than Apple (then next step) was using gcc.

1988–1995. https://www.gnu.org/bulletins/bull18.html#SEC13

So the reason for that was that Apple was of the legal opinion that GPLed software was incompatible with their OS. Since they didn't have process boundaries at the time, all code running on the system, even the OS was basically linked together in a big blob. Apple thought (incorrectly) that allowing any GPL software would mean that they had to GPL their OS, and were vehemently anti free software.

I think under those conditions, the FSF's boycott was fair.

Er, no, that wasn't the reason at all. FSF boycotted Apple because of https://en.wikipedia.org/wiki/Look_and_feel#Lawsuits

Do you have any source for that? I found a post[0] on Slashdot from March 2000 that Apple "plans to assign the copyright for its changes to gcc to the [FSF]." Neither the post nor the comments I skimmed seem to make reference to a victorious GPL lawsuit. (Unfortunately the original mailing list post is lost.)

The earliest snapshot[1] of opensource.apple.com on the Internet Archive suggests that the compiler sources were available (under "cc") as of October 12, 2000.

Although that snapshot suggests the first release was version cc-792, I can't find older than cc-798 on the site today. But the NOTES file[2] is interesting, detailing NeXT's/Apple's earlier changes including release codenames. (3/19/97: "This is the first fully functional compiler for the PowerPC.")

I would guess that the earliest Apple shipped gcc was with ProjectBuilder in the Mac OS X Developer Preview which was in 1999. Maybe things start to get blurry with NeXT, WebObjects, etc. but it doesn't _seem_ like Apple was shirking it's responsibilities under the GPL.

0: https://apple.slashdot.org/story/00/03/17/1656240/apple-plan...

1: https://web.archive.org/web/20001012121451/http://www.openso...

2: https://opensource.apple.com/source/cc/cc-798/NOTES.auto.htm...

Ok, so I misremembered, it didn't get to the point of a full lawsuit, only lawyers sending increasingly nasty notes at eachother, but it's still the first GPL enforcement action.

Its was NextStep. They tried for a long time to ship a proprietary GCC, then a proprietary frontend with the rest of gcc, then finally backed down and released the frontend. This was all in the early nineties.

I see. I was just using Nvidia’s CUDA compiler and it seems to be similar—-a combination of a proprietary frontend based on EDG and gcc to produce actual binaries.

It's different, NVCC emits C code, then invokes a version of GCC on that code for the local system.

NextStep was trying to link a new frontend at the same level as C, C++, or Fortran, and just give the middle finger to the terms of the GPL.

Why does good things coming from another license mean GPL isn't working? GPL guarantees a lot of rights that an important minority of developers finds valuable . If you don't care for it, Im not here to convince you, but I think you should be glad it at least exists.

You are right -- the GPL has been enormously important to the free software movement. I (perhaps wrongly) interpreted your post as being anti-permissive more than pro-copyleft. My apologies!

makes sense, I like permissive licenses too.

The existence of LLVM means that GCC's GPL can't really guarantee anything anymore. 20 years ago we got an open-source objective-C compiler because its implementers wanted to reuse GCC's backend. But today a company in the same situation would just use the LLVM backend.

Except with LLVM they wouldn't need to return their work to GCC, like NeXT was forced to do with their frontend.

That's exactly my point. GCC's copyleft was only effective when there wasn't a viable permissive-licensed alternative.

How is a more restrictive licence valuable for anybody's rights?

The GPL restricts vendor rights to protect end user rights.

Hate to pull a Godwin, but that sounds like socialism: let's improve the lives of the common folk by screwing companies. We all know it all ends.

The truth is that free licences gave us the iPhone, the PlayStation, etc.

I've just seen it repeated several times, in many spaces. Apache, for example, moved faster after Nginx started taking market share. And ideas were copied back and forth.

Also, a monoculture isn't great for security/exploits.

Clang would gave to start having better support for floating point. Right now it's at the "eh, whatever, it works for my limited case" level of support, which is not near good enough for safety-critical applications. They're starting work on that, so maybe in a few years time.

Do you have a reference for this, out of curiosity?

are you saying this in respect to GCC or in regards to commercial compilers, or both?

Reply on news.ycombinator.com