We aren't just talking about proprietary software developers using llvm. The projects most hurt by GCC being crippled by design are those like emacs that want to do more advanced things using GCC AST but can't. Emacs is being deliberately harmed to prevent other proprietary developers doing something they can already do anyway.

If you are saying GPL advocates believe they are correct to deliberately cripple their software for political reasons, then what kind of lesson do you think that is teaching an entire generation of CS postgrads and academics who are forced to use LLVM for their work because RMS thinks they shouldn't be allowed to do compiler research using Free Software. The damage to mindshare and reputation is huge here. To be honest I'm not sure it's even recoverable at this point. To a lot of people GNU software is turning into "stuff you don't use because it's crippled for political reasons and they want to control what you can do with software". Very morally pure I'm sure, but also suicidal.

Why not reverse the argument? If llvm can already be used for that sort of task, why not simply use it in place of Gcc for that very precise task? I'm pretty sure RMS would not mind it as much as opening gcc's AST, and he would certainly embrace the idea of making Gcc able to match llvm feature wise to make sure that whatever becomes possible in emacs is handled at compilation by Gcc.

Yes, you'd think that, wouldn't you... But the only reason for this discussion is that RMS had already prevented the inclusion of clang-based tools in the Emacs code base. He thinks it'd undermine GCC, and by extension his cause.

Hmmm, Charybde and Scylla. There's no solution I suppose, or maybe just go by what RMS wants: produce a data structure for the necessary data for the simplest possible improvement, then define a more involved data structure for a more ambitious feature, and reiterate again and again, until the data structure becomes isomorphic to what Gcc deals with. No need to actually code all these steps, just specifying them should help RMS understand that it's inevitable at some point.

In what way is Emacs being "deliberately harmed"?

It has worse code completion and refactoring support for C and C++ than it should have. Emacs users are forced to switch to other tools (like proprietary IDEs or LLVM based tools) when they need to do complex refactoring to c++ codebases. It could be improved (should have been years ago) but RMS has stated that he would block the inclusion of code to do those things if they use a GCC plugin that exports the full AST.

This is all discussed in the original mailing list thread and it's why one of the core emacs devs suggested forking.

See the thread that prompted this: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

Basically, an Emacs maintainer thinks that this gcc restriction is so harmful to important emacs features that he would be willing to "consider a fork"