Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.

And FOSS folks most likely would like to enjoy those patches as well on their installations.

And they do! You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them. It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM...

> You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them.

They contribute some things, sure. But the also don't contribute some things. It is hard to know how much because it's kept secret from all of us, even their own customers.

> "It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM..."

Rust no, hut there are a lot of proprietary, semi-incompatible proprietary forks out there.

I haven't advocated for re-licensing GCC to be permissively licensed. And patching GCC is necessarily going to be much easier for vendors than to build a new C front-end which generates GCC IR. So I'm not sure what difference you think what I'm proposing would make with regard to your concerns.

gccrs is a rust implementation for gcc. Just because Rust developers don't want their users to be fully free doesn't mean there are any problems with gcc. And clang is developed by Apple which is a huge warning sign by itself.

And gccrs is not really very widely used and is not the "official" Rust compiler. The Rust project chose to base their compiler on LLVM, for good technical reasons. That's bad news for the GCC project.

I thought that most FOSS projects took multiple compiler implementations as a sign of a healthy language environment, without much prestige associated with being the "premier" compiler and instead having more of an it-takes-a-village attitude. Granted, I'm mostly extrapolating from Go and Python here - is it a sharper divide in the Rust community?

No, and I think the gccrs project is great and a sign that the language is maturing. I'm just saying that LLVM was chosen instead of GCC to build the official Rust compiler for very good technical reasons, and that ought to worry GCC.

Rust developers don't "not want their users to be fully free", they disagree with you on which license is best. Don't deliberately phrase people's motivations in an uncharitable way, it's obnoxious as hell.

It's an early implementation of a part of rust. It's not even close to being able to use as the daily compiler.

LLVM/Clang is evolving more quickly than and is a much richer base for innovation than GCC is. LLVM spawned Rust, Swift, and Zig. The most recent GCC languages are Spark and COBOL.

One of the reasons that LLVM has been able to evolve so quickly is because of all the corporate contribution it gets.

GCC users want Clang/LLVM users to know how dumb they are for taking advantage of all the voluntary corporate investment in Clang/LLVM because, if you just used GCC instead, corporate contributions would be involuntary.

The GPL teaches us that we are not really free unless we have taken choice away from the developers and contributors who provide the code we use. This is the “fifth freedom”.

The “four freedoms” that the Free Software Foundation talks about are all provided by MIT and BSD. Those only represent “partial freedom”.

Only the GPL makes you “fully free” by providing the “fifth freedom”—-freedom to claim ownership over code other people will write in the future.

Sure, the “other people” are less free. But that is the price that needs to be paid for our freedom. Proper freedom (“full freedom”) is always rooted in the subjugation of others.

Amazon and the like appreciate indeed their freedom not to contribute back, while pumping the cash register.

Some slaves were treated well, fed nicely and overall had rather good life. Yet, they remained slaves, so master could take all of that from them at any moment.

But hey, if you try hard to be nice to your master and do not demand anything, for sure they will always treat you well!

GPL gives more freedom to software users. BSD gives more freedom to software developers.

I think that's the core difference.

It's not like GCC or the embedded toolchains are a shining beacon of ISO compliance... and if you mean video game consoles, are any of them using GCC today? Sony and Nintendo are both LLVM and Microsoft is Microsoft

The difference being that vendors forks not compliant with GPL can be legally asked for the changes they haven't sent upstream.

With LLVM they don't need to fork it in the first place. But still, it doesn't matter because ISO compliance is a frontend problem.

The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all.

If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"

Forcing vendors to contribute back upstream is an attempt at making vendor toolchains not exist.

If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers.

With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch.

With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch.

Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.

gcc requires that contributors assign copyright to FSF (or at least "certify the Developer Certificate of Origin")[0], so a fork isn't gonna get upstreamed without the approval of the fork's authors. So that limits the benefit from gcc-forks to individuals keeping the fork alive.

[0]: https://gcc.gnu.org/contribute.html#legal

>making it impossible to integrate it back into LLVM

Code getting open source is not impossible. Companies do it all of the time because it's expensive to rebase.

Dude you can't just quote a fraction of a sentence and then argue against that fragment. Read the whole sentence. The part about how "the vendor could make their toolchain proprietary" is kinda important.

My comment was about proprietary software being open sourced.

My comment was about forcing companies to not make proprietary software.

Myth: GPL means more companies contribute to GCC

Previous reality: companies write fully proprietary code to avoid GCC

Current reality: companies choose Clang over GCC because of the license and then contribute many of their changes back.

So are you aware how many contributions have actually been upstream by Sony, Nintendo, IBM, ARM, Green Hills, Codegear, TI, Microchip, Codeplay, NVidia, AMD, Intel, HP,.... ?

Because Apple certainly isn't alone.

The question is less what's upstream than what's not.

The question is who is leeching clang while pumping the cash register.

Venders who use llvm quickly discover the cost of mainaining their own fork is too high and end up contributing back.

The point was the whole clang package, and no they don't, plenty of examples.

Except they do, plenty of examples (many already provided)

Examples yes, I provided the examples of everyone taking advantage while not contributing.

I am still waiting for the counter examples regarding clang contributions.

Clang is in git with good tracking of who each contributor is - there are more than 4000.

GCC has very good ISO compliance and ISO C23 is better supported than in Clang (which I expect to catch up soon though)

Knowing the history of GCC (more focused on C) and Clang (more focused on C++), it makes sense to me that GCC has better ISO C compliance.

Clang has a very nice specific page for ISO C version compliance: https://clang.llvm.org/c_status.html#c2x

I could not find the same for GCC, but I found an old one for C99: https://gcc.gnu.org/c99status.html

CppRef has a joint page, but honestly, I am more likely to believe a page directly owned/controlled/authored by the project itself: https://en.cppreference.com/w/c/compiler_support/23

Finally, is there a specific feature of C23 that you need that Clang does not support?

I would not say that GCC is more focused on C. Also in GCC there is a lot more effort going into C++ than C. C is generally neglected, which is sad given its importance.

GCC's support for C23 is essentially complete. Clang is mostly catching up, but features I need that I am missing are storage class in compound literals and tag compatibility. It is also sad that Clang does not implement strict aliasing correctly (it applies C++'s rules also in C).

"substantially complete" C99 even

Apple, Arm, OpenBSD, FreeBSD have all switched to Clang.

Why did OpenBSD switch to clang? Licensing issues?

Could be. They stuck with GPL2 GCC 4.x for a while. IIRC, they never switched to GPL3 GCC5+

Swichting wasn't the point.

What exactly do you mean by "UNIX"? Commercial UNIX vendors other than Apple have basically a rounding error from 0% of market share.

Yet IBM, Oracle, HP and POSIX RTOS vendors keep enough customers happy with that rouding error.

Are you from 2001? Sorry, but Apple at servers' market it's non-existent. RH and Canonical make tons of money thanks to being THE platform of the ubiquituous internet. Support is not free.

Are you calling Linux a UNIX? I mean GNU/Linux is certainly a UNIX-like system, but aren't "UNIXes" typically used to refer to operating systems which stem from AT&T's UNIX, such as the BSDs and Solaris and HP-UX and the like? GNU's Not UNIX after all

I have good memories associated with OpenSolaris. Oracle ruined it.

I have not tried OpenIndiana, however.

GNU isn't Unix as NT isn't Win32.

Gnu promotes Unix, but also promotes Emacs on top. NT can run Win32 on top of it, but there's far more than Win32 with NT systems. Just get ReactOS and open the NT object explorer under explorer.exe.

Far more advanced than Windows 95/98.

Win32 is an API, while UNIX, NT and GNU are all operating systems made by AT&T, Microsoft and the GNU Project respectively. I agree that the GNU operating system isn't the UNIX operating system, and I agree that the NT operating system isn't the Win32 API, but I have no idea what comparison you're trying to draw.

It almost sounds like you think UNIX is an API like Win32, and that GNU is an operating system which "implements UNIX" like NT is an operating system which "implements Win32"? Are you confusing UNIX with POSIX?

GNU was made to replace UNIX, not to promote it.

No, I'm not confusing Unix with POSIX, but POSIX today superseded old Unix. What I mean both NT and GNU enhanced and modernized their own subsystems.

Even OpenBSD is not as 'pure Unix' as Unix V7.

Gnu/Linux and UNIX are not the same thing. Yes I understand that RHEL and Ubuntu are popular.

Apple is not a UNIX vendor. They checked off enough of a compliance list to pass in the legal and marketing sense, but in any real practical sense it's not usable as a UNIX system. It's not designed to serve anything. Most of it is locked down and proprietary. No headless operation, no native package manager, root is neutered... and so on. It's not UNIX.