Developing a GCC frontend is a massive PITA, and the worst of all it was made purposefully so complicated because of RMS' concerns about closed compilers. He actually brought LLVM's existence onto himself, because it was somewhat clear no one would have bothered writing a new compiler if it had been possible to use it's frontend for other things (even from free software it's hard) and they kept the license as "GPLv2 or later" instead of pushing for v3 that arguably makes 0 sense with GCC (it's not like it's going to be put in a closed box any time soon).

Sometimes in life it's better to be a bit heterodox, but have influence and leverage, than being alone on your high castle. GCC can be as open as it gets, but pushing people away in the name of freedom has actually only given reasons to the industry to move away from it, which is sad and could be avoided.

The fear of GPLv3 is just an excuse to pull things into proprietary. They became aware of the success of GPL and started to actively lobby against it with what they were able to come up with.

It doesn't matter.

Sometimes in order to achieve your goals you must compromise or risk loosing the footing you already have, because you have close to zero chances of succeeding.

If RMS had compromised on GCC in the '00s, i.e. if GNU had spun off the C/C++/ObjC front end as a separate GPLv2-or-later library upon which something like clangd could have been made, Clang would have never existed. Yes, LLVM would have still been present, but as a special-case backend that used GCC as its frontend instead than its own, as they were planning to do since the beginning. All these improvements you talk about would have been done under the GPL, and not BSD licenses or proprietary. IDEs like Xcode and such would still be proprietary like they are nowadays, because there was a 0% chance of getting Apple or whomever to release them under the GPL.

It doesn't matter how much strong your moral principles are, or how much you value integrity. The world is definitely more pragmatic about software and values different things than RMS; while this might or might not be beneficial to our overall society, that's the way it is. Ignoring it is myopic, if it does not outright amount to shooting yourself in the foot.

The change also means libgcc is now GPLv3 as well, making licensing for anything embedded that uses glibc (which has a hard dependency on libgcc_s) a royal PITA to figure out since GCC’s linking exception. Okay, so a proprietary program can link against libgcc without coming afoul of the GPL, but do we still have to make libgcc_s itself replaceable according the the anti-tivo clause?

The FSF is shooting themselves in the foot with the way they handle many of their projects today, GCC is no exception. Free software purity is a great goal and all, but what use is it when nobody uses it or it falls behind more permissively licenses projects.

Sure, now you get to enjoy all those PS4 optimizations, and watchOS bitcode portability fixes in LLVM.

The point is, these things would have happened no matter what. RMS simply overplayed its leverage, and the magic that kept GCC at the centre of everything for decades broke.

If he could just stop being a zealot for a split second and actually tried to understand the situation, he could have maybe been able to foresee that Apple had the people, resources and will to reimplement a whole compiler infrastructure that could threaten GCC's dominance, but he neglected it (it famously didn't care about Apple's offer to merge LLVM into GCC under the GPL).

Sometimes even the best of intents are shadowed by people's inability to compromise.

RMS didn't overplay anything there. His GPL idea has just become too influential and they started fighting it.

That magic was UNIX vendors started to charge for their compilers, and as we have seen by the BSDs have taken the world of UNIX clones.

Sometimes the hate for a license prevents people to grasp what is ahead of them.

Something like that?

https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...

or that:

https://reviews.llvm.org/D15624

No, something like the PS4 CPU features that don't get upstreamed because they might provide clues how to bipass PS 4 security.

There are some talks from Sony at LLVM meetings regarding those.

That PR from Apple has nothing to do with the bitcode reference I made.

Why do i want a PS4 specific cpu-drm feature in a generic Compiler?

I did not said it was a cpu-drm feature, rather optimizations that could reveal hints about it.

I don't know, maybe other AMD users would like to get them?

You wrote:

>might provide clues how to bipass PS 4 security

>AMD users would like to get them

They got em:

https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-10-...

https://www.phoronix.com/scan.php?page=news_item&px=Sony-LLV...

Why do i want ANY PS4 specific security feautures in the Compiler??

Why bother explaining to those that refuse to understand....

All of those frontends live inside the GCC source tree. Which requires copyright assignment to contribute to. And for a long time, it was difficult to "casually contribute" to GCC; you had to work towards "commit access", and it wasn't anyone's job to review other people's patches, so often it just didn't happen. And there are various other barriers to contribution as well.

LLVM's license was certainly a factor, and I'd never suggest otherwise, but there were many other reasons that GCC couldn't help kick off a wave of language design and experimentation the way LLVM did.

No they do not.

GNU Pascal, Modula-2, Modula-3, BASIC and plenty of OEM derived ones were never part of GCC source tree.

I had to study GIMPLE and GCC integration as part of my compiler design studies back in the 90's, using those nice Walnut Creek CD-ROMs.

Sure, you could also fork all of GCC as part of your frontend. That's still a massive undertaking compared to a framework that's designed to be used as a library.