[volta83]

> but not nearly as LLVM would in the same situation.

LLVM has the support of most compiler research groups across the globe, so in contrast with GCC, there is a steady flow of "LLVM PhD"s coming out of academia in need of a job, and "LLVM PhD"s becoming professors and continuing doing research with LLVM, and then a large set of CS students doing all kind of works with those professors on LLVM, which creates a steady flow of "BSc"/"MSc" LLVM professionals.

On top of that, many technology companies have built their whole platforms on top of LLVM.

GCC doesn't really have that. If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.

[bluescarni]

> On top of that, many technology companies have built their whole platforms on top of LLVM.

That is irrelevant, as most of those companies are keeping their modifications to LLVM closed-source. They are not at all interested in fostering a healthy open-source ecosystem around LLVM.

> GCC doesn't really have that.

This is just wrong. Just as a single example, the first ever C++ concepts implementation was written for GCC by Andrew Sutton, a University professor and co-author with Bjarne of the concepts proposal. LLVM's implementation came years later, and it's not as stable or complete to this day.

> If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.

Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.

[volta83]

> That is irrelevant, as most of those companies are keeping their modifications to LLVM closed-source. They are not at all interested in fostering a healthy open-source ecosystem around LLVM.

AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.

> GCC doesn't really have that. This is just wrong. Just as a single example,

If that's your main example, you are in for a ride. Since asutton branch is over 15 years old almost at this point, and it was by design that no work should happen in LLVM until concepts make it into the standard.

I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.

> Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.

From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc. It was not until after 2016 where some open source companies, like redhat, started pouring more money into GCC that this started to change. The moment these companies are out, the same thing will happen.

[bluescarni]

> If that's your main example, you are in for a ride. Since asutton branch is over 15 years old almost at this point, and it was by design that no work should happen in LLVM until concepts make it into the standard.

Nice strawman, what does this have to do with anything that I wrote?

You went on and on about how there's heaps of "LLVM PhDs" (whatever that might mean) coming out of academia, so I gave you an example of someone working in academia who developed and contributed a key C++ feature to GCC.

> I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.

That's not my experience, and I have been using GCC and Clang daily on modern C++ codebases targeting the latest standard for the last 10 years.

> From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc.

Yes, GCC's diagnostics have been trailing Clang's, though they have mostly caught up in the last few versions. But "much slower than clang" is flat out wrong, unless you mean compile-time performance. GCC has for years consistently produced more optimised code than Clang's, and it only in the last couple of years that the two compilers are essentially on performance parity.

> AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.

I seriously doubt that AMD/Intel/ARM engineers are doing substantial work on C++20 features, but I'd be happy to be proven wrong :)