Extracting the abstract syntax tree from GCC

By Jake Edge
January 14, 2015

Richard Stallman recently revived a nearly year-old thread in the emacs-devel mailing list, but the underlying issue has been around a lot longer than that. It took many years before the GNU Compiler Collection (GCC) changed its runtime library exemption in a way that allowed for GCC plugins, largely because of fears that companies might distribute proprietary, closed-source plugins. But efforts to use the plugin API to add features to another GNU project mainstay, Emacs, seem to be running aground on that same fear—though there has never been any real evidence that there is much interest in circumventing the runtime library exception to provide proprietary backends to GCC.

Last March, a debate about exporting the abstract syntax tree (AST) information from GCC to Emacs (and other programs) was ongoing in various mailing lists. That discussion was about adding an Emacs feature to auto-complete various program-specific identifiers (e.g. variable names, types, structure member names, etc.). It was an offshoot of another wide-ranging discussion that we covered back in January 2014. When the conversation dropped last March, Stefan Monnier had responded to Stallman:

[...] for Emacs the issue is to get detailed info out of GCC, which is a different problem. My understanding is that you're opposed to GCC providing this useful info because that info would need to be complete enough to be usable as input to a proprietary compiler backend.

On January 2, Stallman renewed the conversation by noting that he hoped "we can work out a kind of 'detailed output' that is enough for what Emacs wants, but not enough for misuse of GCC front ends". He was looking for people to help define that "detailed output", but instead found a number of people that felt that exporting the full AST information would be more sensible.

Stallman is concerned that proprietary backends could take the AST output and generate code from it. While no one in the thread wanted to see that happen, most also saw it as an unlikely outcome. David Engster said that he had been working on a way to get the AST information out of GCC for Emacs and noted that there was no technical barrier to doing so:

Anyone can write a GCC plugin that simply outputs the AST in some form. It's not that hard. The plugin itself would have to export the symbol 'plugin_is_GPL_compatible', but of course you can't control what's done with the output. No [one] bothers with this though, because everyone just uses libclang.

While the original discussion was largely about auto-completion, Engster and others would eventually like to go further than that. Their vision is to turn Emacs into a more full-featured integrated development environment (IDE), which would require all of the AST information, at least in their eyes. Stallman would prefer providing far less information: "just enough to do the completion and other operations that Emacs needs, and NO MORE."

Engster replied that he understood Stallman's concerns, but felt that there was no real problem:

For almost five years now (since gcc 4.5 introduced plugins), access to GCC's AST is wide open for everyone. However, in all that time (and to my knowledge) no one has used that to feed non-free backends, and that is in my opinion enough evidence that your worries are unfounded. They might have been valid in the past, but not since LLVM and clang have joined the scene.

He went on to say that if Stallman was opposed to using the AST in Emacs, he would drop the work he was doing in that area (for auto-completion and other IDE-like features). Stallman remained unconvinced of the need for the AST information, saying "it is so important to avoid the full AST that I'm not going to give up on it just because someone claims that is necessary".

But Perry E. Metzger noted that he is doing "a bunch of complicated refactoring work in conjunction with my current academic research" and that the lack of AST information from GCC forced him to use Clang/LLVM. He would like to see Emacs gain more IDE-like features that other tools, such as Apple's Xcode, have:

The libclang AST manipulation functionality was originally created because Apple wanted it to enable sophisticated IDE and refactoring capabilities in XCode's editor. I have wanted to have all that stuff in Emacs forever, but it is hard without having access to tools that generate a full AST of the code being examined. For Emacs to be able to compete with non-free tools, it is important that it have access to similar capabilities as the non-free tools have.

Stallman would like to see some kind of investigation to determine what pieces of information are needed for which purposes (e.g. auto-completion, refactoring, and so on), but that seems short-sighted to some. Metzger gave several examples of things that could only be done easily by having the full AST. Object-oriented languages, in particular, have programs with complex inter-relationships that can only be untangled by using all of the information that the compiler has collected in the AST.

Even if various subsets of the AST information could be defined to enable particular IDE features, new IDE features come about regularly. As David Kastrup pointed out, adding new interfaces for each new set of requirements makes little sense and would require that the Emacs IDE features and GCC versions be tightly coupled. Either that or the GCC plugin interface needs to be stable and provide a highly general API into the guts of the compiler, which could also be used in "bad" ways:

If we want the editing modes to be able to evolve without being constrained to the GCC release cycles, we need either rather generically useful data, or generically useful GCC extension interfaces.

Keeping all of our babies while throwing out all of the bath water for evolving notions of babies and bathwater is not likely to work well.

I don't really see that we have much of a chance not to be hobbling us ourselves more in the process than currently hypothetical leeches.

There appear to be a few disconnects in the conversation. Stallman is focused on auto-completion, and believes that it can be done without access to the full AST. Others disagree, especially for languages with operator overloading such as C++. Stallman said that he has never used C++, so he is trying to understand what would be needed to support auto-completion for C++ in Emacs. However, the discussion has also included adding support for more than just auto-completion, but Stallman is not ready to look into additional features yet. Even if it is possible to handle C++ (and the other languages GCC supports) auto-completion without all of the AST information, there are plenty of examples in the thread (mostly from Metzger) of IDE features that do require the AST (or enough information in other forms that it would be functionally equivalent to the AST).

It is clear that Stallman has not used any of the "competing" IDEs (e.g. Xcode, IntelliJ IDEA), which is not a huge surprise, but he is clearly feeling browbeaten about the issue: "Rather you are trying to pressure me to do what you want, at the expense of something I consider important." But Metzger and others have clearly stated that they understand (and, in general, agree with) Stallman's concerns, they just see the tradeoff differently than he does. In fact, Metzger said, there is a freedom issue at stake:

By forbidding the editor from having advanced knowledge of the parse tree, you are intentionally crippling the ability of smart people to build better and better free software tools. You are preventing smart hackers from going in and making the system as good as they can make it, from expressing their creativity in such a way as to build the best development environment they know how.

That is, of course, a hot-button issue for Stallman, who takes umbrage at that characterization. Furthermore, he wants to take some time to study the problem(s), without being pressured:

What I intend to do is investigate these issues thoroughly _one by one_ to see what options exist for each, and what is good or bad about them. I will think about refactoring when I understand it well enough to be able to judge arguments myself. First I will learn about it from people who are not trying to pressure me about it.

Metzger volunteered to help with the process, but noted that it goes well beyond auto-completion. Emacs is a powerful tool that, unlike most of the other IDEs, gives its users the ability to reprogram the way it works. But that requires flexibility:

I recognize that you don't want me to "change the subject" to refactoring, but I don't see this as a change of subject. The concern isn't as such code completion, that's just a detail. The underlying concern is being able to make Emacs the very best programmer's editor it can possibly be. Modern development environments have astonishing power, and there is an enormous desire on the part of certain parts of the Emacs community to have that power or even more available in Emacs.

Beyond that, Kastrup and others felt that Stallman was being unfair to Metzger by characterizing his comments as "changing the subject". Karl Fogel pointed out that Metzger and others have all acknowledged Stallman's concerns, but that Stallman has not done the same:

For some reason you refuse to acknowledge that others are cognizant of this tradeoff. They have been very patiently making a detailed argument for why, in this particular case, you are choosing the wrong side of that tradeoff -- the side that will be *less* effective at accomplishing our shared goal. They make this argument, with impressive clarity, and then you accuse them of bad faith.

This would be poor behavior even if those people were wrong. I think they're actually right, though, which makes it even worse, because now our goal is being damaged too.

It would seem that the goal of more IDE-like features for Emacs has suffered a setback. Based on Stallman's responses, Engster said he would not continue working on his project to incorporate AST information into Emacs:

It was you who told me to abandon libclang and choose GCC instead. And now that I'm working on that, I only get confronted with vague restrictions like "you may only export what you need for completions".

The problem that Stallman foresees is that the AST information could be used by a non-GCC backend that wouldn't use libgcc and would thus evade the GCC plugin restrictions that were added to the runtime library exemption. But as Óscar Fuentes pointed out, that has already been done by the DragonEgg project, which "is now abandoned, mostly because Clang is a better front-end than GCC". Because LLVM does not have the freedom-respecting requirements that Stallman holds dear, it also takes a much more modular approach that is easier for other projects to interface with.

Another potential problem is the possibility of a fork of Emacs to support using a GCC plugin that exports the AST, which would be legal under both the runtime library exemption and the Emacs license. The only barrier would be if Stallman was unwilling to accept the code into Emacs. Monnier said that, under those circumstances, he would be "willing to consider a fork if that's what it takes".

Kastrup noted that Stallman has laid out a plan for getting the understanding he needs to proceed with these features. That will take time, however, which may have other negative impacts:

Richard said he'll discuss the issue with people he trusts. And frankly, this sounds like a responsible thing to do even if it is frustrating to people who'd like to see a more prompt reaction to their input. It would be a pity if by the time this process comes to a conclusion there is nobody interested in making it count any more.

There appears to be a fairly wide chasm between the two sides of the debate. It is hard to see how an Emacs IDE mode for GCC can compete with the proprietary alternatives without some mechanism to extract the AST from the compiler. To Stallman, at least, that is not of paramount importance, while others see things differently. The risk is that both Emacs and GCC decline in both usage and developer mindshare while some kind of solution is found. That would seem to make it worth coming to a solution sooner rather than later, no matter which side of the debate one is on.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 2:56 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (10 responses)

If this were fifteen years ago, or even ten, RMS would have a point. At that time GCC was the only really good free compiler system, way ahead of its competitors, and there were proprietary software developers interested in exploiting GCC internals in ways RMS would find undesirable. But even then, people who just needed a flexible front end licensed EDG. Meanwhile, LLVM advanced to the point of usability, and it was designed from the very beginning to be suitable as a modular framework for static analysis and compiler research. RMS's efforts were beginning to cripple GCC and it took several years to persuade him to permit plugins; additional legal hacks were required to persuade him. But these days, anyone who wants an AST can use LLVM; they can also write a GCC plugin to dump the GCC AST but it will be basically equivalent. There is no secret sauce to protect.

GCC has been able to modernize its architecture, and I think that the LLVM/GCC competition has helped both projects. I was amazed that they were able to persuade RMS not to block the conversion to C++, and as the article points out, five years of plugins have not led to disaster; I was worried that dragonegg might really piss RMS off but it was really just a proof of concept and not the right way to do things. But all of the fights with RMS have been exhausting, a demoralizing energy suck. It would be best for the FSF if he could find others that he trusts that aren't so out of touch to manage software development issues.

The GPL was RMS's greatest hack, but copyleft is just one tool. It can promote software sharing, but it can't bend the world to RMS's will.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 4:38 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> But all of the fights with RMS have been exhausting, a demoralizing energy suck.

So much precious, expert developer time which could have been spent writing code... discussions are required, but there comes a point where the answer becomes... Just Fork.

Fork Emacs, fork GCC, both, switch to LLVM,... doesn't matter: whatever it takes to finally allow Emacs to express its potential and catch-up as an IDE, bringing it to the level where (free) Eclipse was... decades ago (for Java, not for C/C++). Quick before it loses its user and developer base. Developers always follow the best fork quickly, and soon after distributions and users do too. The github way; fork button on every page (good bzr is already gone). Leave the politics behind. "We reject kings, presidents and voting. We believe in rough consensus and running code".

If you don't want to hurt feelings, don't call it a fork. Call it "a branch for prototyping new ideas, temporarily breaking away from [ideological] licencing restrictions to facilitate experimentation. We'll be back soon, I promise". Something like that. Avoid full names like YEmacs :-)

PS: thanks for the amazingly clear summary. Great illustration (in reverse) of Blaise Pascal's "shorter letter" quote. One of these LWN articles which makes you feel like it _alone_ is worth your subscription.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 21:13 UTC (Thu) by Fats (guest, #14882) [Link]

>> But all of the fights with RMS have been exhausting, a demoralizing energy suck.
>
> So much precious, expert developer time which could have been spent writing code... discussions are required, but there comes a point where the answer becomes... Just Fork.

I vote for egcs II !

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 4:57 UTC (Thu) by rahvin (guest, #16953) [Link] (5 responses)

I would have thought he would have at least used C++. Good lord, he's like 20+ years out of date and not up to speed with what's happened with IDE's or compilers in that time. One of these people that he trusts should show him what clang or one of the proprietary IDE's can do these days.

The elephant in the room is that GCC and emacs aren't competing against proprietary compilers so much as they are against LLVM and clang. Whichever one has better features and support for programming is going to win mindshare and without mindshare you are dead. This is compounded by the fact that there are several major corporations helping LLVM along so you need steady contributions and use just to stay even with them.

More than anything he needs a 101 on LLVM and clang and what's happened in the last 20 years that he hasn't paid attention to. There is almost no risk at this point of anyone taking GCC and using it for proprietary software because LLVM allows them to do what they would want without the GPL in the way. Some would even argue that LLVM is better than GCC.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 7:34 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (4 responses)

Yeah, and LLVM / Clang have already won a lot of mindshare in programming tools, with Qt Creator, Doxygen, AspectC++ and others switching to it. Clang has the only modular FLOSS C/C++/ObjC parsing / sema code able to deal with recent standards, and that state of fact doesn't look like about to change...
Even if the GCC parsing / sema code became suitably modular overnight, adding a GCC parser backend into the existing tools which have already switched to Clang would only make these tools' code bases both more complex and not less subject to licensing restrictions, for extremely dubious functionality gains. Too late ?

Clang is also gaining direct mindshare among end users thanks to improved functionality. Just to mention two examples:
* though GCC now offers them as well, AddressSanitizer and UndefinedBehaviourSanitizer first became usable in Clang;
* Clang now consistently implements C++11/14/17 standard (draft) features before GCC does. Though GCC pulled a PR stunt by backporting the remaining missing features to 4.8.1 slightly before Clang 3.3 was officially released, Clang had had those features in SVN for a while.
Clang 3.4 offered full draft C++14 support in an official release in January 2014, while C++14 support in GCC 4.9, released later, still had multiple important holes. Clang 3.6 (more frequent release rate) will offer some C++17 draft support by the time GCC 5.0 with full C++14 support is released.
Modules are being prototyped on Clang, and although the latest Concepts Lite prototype is based on GCC, there was a Concepts prototype based on Clang.

Agreed about the fact that making proprietary GCC extensions has become basically pointless with the advent of LLVM / Clang. The proprietary extensions are happening no matter what, only with another toolchain, and GCC has zero control over it.
GCC also has zero control of Apple's and Microsoft's SDKs, both of which are now based on LLVM / Clang to variable extent, at least for some platforms.

I still love emacs: Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 1:36 UTC (Fri) by linuxbox (guest, #6928) [Link]

For what it's worth, I would never trade emacs for any of these fat ides. That said, the prospect of emacs modes informed by the kind of information libclang could provide, not to mention, the notion that -people are chomping at the bit to write them-, blows me away.

Emacs AST integration overlords, bring it on.

Matt

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 12:10 UTC (Fri) by meyert (subscriber, #32097) [Link]

I actually would like to see Code-Pointer Integrity - http://nebelwelt.net/publications/1431c3/ - as an GCC plugin! But they decided to implement it as an LLVM extension.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 9:07 UTC (Mon) by Frej (guest, #4165) [Link] (1 responses)

Clang error messages tend to be more helpful as well.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 16:30 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Everybody's diagnostics have been getting better. Over my career we've gone from "Oh! This new system tells you where the problem is, rather than just saying Syntax Error" to GCC telling me that (a) My fscanf() format string seems not to match the provided parameters (b) what the format seems to ask for (c) what the parameter I supplied is (d) how to turn off the warning if I don't care.

The tools I have today are many times better than the tools I had twenty, ten, even five years ago.

Extracting the abstract syntax tree from GCC

Posted Jan 21, 2015 3:05 UTC (Wed) by edelsohn (guest, #16472) [Link]

Richard unfortunately does not recognize that the more he tries to prevent uncomfortable changes to GNU Software, the more pain he causes himself and the GNU Project.

Richard's approach hinges on the now false premise that software such as GCC have such a high barrier to recreate that developers will come to the FSF plantation. As Joe said, there is no secret sauce to protect, but leaders of both proprietary products and FLOSS projects from an earlier era cling to that as the foundation of their "businesses".

Extracting the abstract syntax tree from GCC

Posted Jan 22, 2015 14:57 UTC (Thu) by mlopezibanez (guest, #66088) [Link]

I agree wholeheartedly with your whole comment except for:

"But these days, anyone who wants an AST can use LLVM; they can also write a GCC plugin to dump the GCC AST but it will be basically equivalent."

The problem is that they are not equivalent at all, and this simple fact makes the whole "debate" pointless. GCC AST is simply still not good enough to do the kind of source code analysis that editors and refactoring tools require. Not even accessing GCC internals will give you that. RMS blessing is not going to change that.

Also, my experience after 10 years working on GCC's C/C++ FEs tells me that a GCC plugin is definitely not the right approach to achieve this. If the issues with GCC's AST were fixed today, then the next step would be to create a library within GCC's source repository that wrapped GCC's internals in a nice interface. This is precisely what the GDB devs have done for the new compile command:

* https://sourceware.org/gdb/current/onlinedocs/gdb/Compili...
* https://github.com/gcc-mirror/gcc/tree/master/libcc1

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 4:10 UTC (Thu) by aaron (guest, #282) [Link] (11 responses)

I'm sure I'm missing something but...
It looks like RMS would rather cripple GCC than have it be used in "unauthorized" ways. I somehow recall that this is what Free Software was born to fight in the first place.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 4:41 UTC (Thu) by marcH (subscriber, #57642) [Link] (10 responses)

We always knew that the GPL was a temporary hack just to fight back and that BSD licences are actually more free; less restrictions. LLVM: Q.E.D.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 5:14 UTC (Thu) by pabs (subscriber, #43278) [Link]

It all depends on who you think should have the freedom to inspect and modify software. If you think only developers should, BSD is great. If think everyone should, the GPL is great. The global software freedom situation has gotten both better and much worse over the years, some say we are in the dark ages of software freedom:

http://www.youtube.com/watch?v=s2LNcaEEhDU
http://upsilon.cc/~zack/talks/2014/20140823-dc14-darkages...

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 10:54 UTC (Thu) by etienne (guest, #25256) [Link] (4 responses)

> BSD licences are actually more free; less restrictions. LLVM: Q.E.D.

Yes, buggy proprietary LLVM backend (on OpenCl video cards) are a real improvement to the software countryside... they force you to remember the time where C compilers were buggy and proprietary, with no support even if you paid for support.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 19:57 UTC (Thu) by flussence (guest, #85566) [Link] (3 responses)

> Yes, buggy proprietary LLVM backend (on OpenCl video cards) are a real improvement to the software countryside...

Yes it is, when the status quo for a tolerably fast and standards-conformant OpenGL/CL stack is called "nvidia.ko" and it's apparent nobody else is even trying.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 20:39 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Nvidia isn't standards conforming (they allow all sorts of things the spec says shouldn't be possible). They also care very little about OpenCL.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 19:05 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

My point being the alternative in the GNU/Free monoculture etienne is pining for is non-existent.

Acting *offended* that LLVM exists and allows FOSS to work for its users is a repulsive attitude.

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 11:13 UTC (Tue) by etienne (guest, #25256) [Link]

> My point being the alternative in the GNU/Free monoculture etienne is pining for is non-existent.

I was not talking about Nvidia but Ati.
My point was you look at their very powerful hardware, you say I want to play with that.
You look at how to program the hardware, you do not see a locked-down proprietary language but something reasonably described (OpenCl), you begin to look at the different hardware configurations you can buy.
You look at the compiler, you see LLVM, you say great! an open source compiler: I shall not have too many problems, and even if I have I will be able to fix them. You buy the hardware you have selected.

Then you realize, when you finally achieve to configure the hardware to work as a basic video card on your distribution (did take a long time, had to disable package management and other dirty things), that the version of LLVM used is completely out of date, that most of the toolchain is completely proprietary and no part can be re-generated, then you hit your first compiler bug (usually it locks down the PCIe bus so forces a hardware reboot with unclean filesystems because the disks are on PCIe Sata interface).

Then you understand that they declared their compiler BugFree (TM), and that they will not consider a bug if you cannot reproduce it on the latest video game (which do not seem to use OpenCl but the "intermediate" representation directly).

> Acting *offended* that LLVM exists and allows FOSS to work for its users is a repulsive attitude.

*offended* is a big word, that is not the first time I spent money on hardware I cannot really use, and I have seen a lot of broken compilers where the supplier denies officially that a bug may exists.

I am also *not saying* LLVM is buggy, I am saying the version they used has been so modified it now has a bug that bite me hard - I can't do anything about it.

I think LLVM gets bad advertisement with that story, final user should really understand the difference of:
- compiler based on "Open Source" software
- compiler itself "Open Source"
- compiler itself "Open Source" and can be fixed (regenerated) locally
- compiler GPL

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 12:02 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link] (3 responses)

I take the totally agnostic view that the various licensing regimes exist to support the various motives people have for coding.

What matters is not whether license A is "more gooder" than license B.

Rather, that people retain liberty to choose among them, as preserved by the legal system.

Licensing is the uber-bikeshed argument: crucial to the passionate; ho-hum to the onlookers.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 16:03 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

For your next tea/coffee break at work, I recommend the machine which is located in the middle of your legal department.

Extracting the abstract syntax tree from GCC

Posted Jan 17, 2015 2:30 UTC (Sat) by smitty_one_each (subscriber, #28989) [Link]

They have one? I'd always understood legal to take refreshment from the neck. . .

Extracting the abstract syntax tree from GCC

Posted Jan 23, 2015 12:40 UTC (Fri) by blujay (guest, #39961) [Link]

And like politics, everyone is affected by it, even the onlookers. Therefore everyone has an interest in it, even if they have no interest in it. It's a bikeshed we all live in, even if we don't realize it.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 10:25 UTC (Thu) by xnox (guest, #63320) [Link] (11 responses)

I remember going to RMS talk in London, and I was so hyped up about it. However, I came out of that talk with a strong opinion that RMS is very extreme in his position and it carries too much hidden agenda.

I have no secret agenda to make the whole world open source.

Shame that my complier and my editor are being crippled. I should really start looking into alternative IDE for myself.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 13:37 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (10 responses)

RMS's agenda to make the whole world open source is not secret or hidden. It's been well known for at least as long as I've been aware of GNU.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 17:25 UTC (Thu) by bronson (subscriber, #4806) [Link] (2 responses)

No, but his technique of crippling implementations and keeping features in the stone age isn't widely advertised. :)

Serious question: why not just implement some of the Emacs features using libllvm? That way RMS can see first-hand exactly what is needed and why. That seems more productive and maybe even faster than spending years discussing it...?

I'd rather be coding!

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 6:55 UTC (Fri) by MKesper (subscriber, #38539) [Link] (1 responses)

As I understood the article, the implementer started with something like that but was asked by RMS to use gcc instead.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 7:37 UTC (Fri) by bronson (subscriber, #4806) [Link]

Ah, you're right. It's in a quote further down:

> It was you who told me to abandon libclang and choose GCC instead. And now that I'm working on that, I only get confronted with vague restrictions like "you may only export what you need for completions".

What a mess. Seriously, why not just go with llvm and ship something great? Once RMS comes to his senses (it can take years, and egcs demonstrates that having working code helps), the whole thing can be ported back to GCC.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 21:14 UTC (Thu) by Fats (guest, #14882) [Link] (6 responses)

> RMS's agenda to make the whole world open source is not secret or hidden

Wrong, his agenda is to make the whole world free software. Open source is for people without principles...

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 18:04 UTC (Fri) by k8to (guest, #15413) [Link] (5 responses)

How even-handed.

Extracting the abstract syntax tree from GCC

Posted Jan 25, 2015 13:39 UTC (Sun) by dakas (guest, #88146) [Link] (4 responses)

Uh, Eric Raymond explicitly created the "Open Source" label exactly to appeal to industry players who considered bothering with principles suspicious. So yes, Open Source is for people without principles. That's not Stallman's pitch, but an explicit design goal of the Open Source agenda. To replace the appeal to principles, a bunch of technical and marketing criteria are propounded.

The dearth of actually successful Open Source companies (where Open Source is part of a permanent rather than an exit strategy) makes it pretty clear that this "realistic" advertising strategy is not actually founded in much realism.

Laws and society still largely favor proprietary solutions. RedHat is one company that is doing a lot for free software based on a proprietary service model. Google may be bleeding money from its Android enterprise, but comparatively little compared to the size of the project. But then the Android universe is not much interested in enabling free software. You may be able to get the source for much of the stuff, but tinkering with it requires jailbreaking and lots of work.

So even where Open Source/Free Software is successful in deployment, the financing has to come from less than free models.

Which means that principles are required after all to keep the freedom a running part of the whole: it does not pull its weight in the market all by itself. Never mind on whether you call it "Open Source".

Extracting the abstract syntax tree from GCC

Posted Jan 25, 2015 14:22 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (3 responses)

Few Open Source companies as compared to none whatsoever in the Free Software camp says what?

Extracting the abstract syntax tree from GCC

Posted Jan 25, 2015 15:58 UTC (Sun) by spaetz (guest, #32870) [Link] (2 responses)

> Few Open Source companies as compared to none whatsoever in the Free Software camp says what?

PLEASE! Can we leave the snarky infighting polemics out?

There are not 'none' free software companiess by the way. Think of g10 code (gnupg), Igalia (calling themselves bnoth open source and Free software consultancy etc).

There are companies out there if you look for them, just no 800 pound gorillas.

Extracting the abstract syntax tree from GCC

Posted Jan 25, 2015 15:59 UTC (Sun) by cortana (subscriber, #24596) [Link] (1 responses)

Plus Redhat, Fluendo...

Extracting the abstract syntax tree from GCC

Posted Jan 25, 2015 22:32 UTC (Sun) by dlang (guest, #313) [Link]

Are those Free Software companies (as Stallman defines it) or Open Source Software companies?

I'm pretty sure that Stallman wouldn't count them as Free Software companies.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 11:04 UTC (Thu) by directhex (guest, #58519) [Link]

"I need time to think about this!!!" says man who sat on the conversation for TEN MONTHS, ensuring that as much developer time as possible would be wasted

You really want to store this information in a big database

Posted Jan 15, 2015 11:15 UTC (Thu) by error27 (subscriber, #8346) [Link]

[ I haven't used C++ either and I use vim. So I may be naive. ]

In my work with Smatch, I have create a 10GB cross function database of the kernel every day. It takes about three hours on my computer. But it's *SO* worth it and I wish this information were integrated into my IDE.

Say you have code like:

foo = atoi(xxx);

Then "foo" is user controlled data. It could make the "foo" variable red until you put an upper and lower bound on it. If you had a line "x = 100/foo;" then the IDE could draw a circle around the divide and if you hovered the mouse over it, it was say that it was a divide by a user controlled variable that might be zero.

That example works without cross function information but the Smatch database can tell you, "This function is called with a user controlled range of [0-5]."

Or say you have a variable "foo->bar" then you could hover the mouse over it and it could tell you every possible place that sets this variable and what the possible ranges are.

Or you could hover your mouse over a function parameter and it would tell you the call tree from where the parameter was allocated up to now.

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 14:31 UTC (Thu) by butcher (guest, #856) [Link] (1 responses)

Maybe I'm thinking of this too simplistically, but does anyone else see the irony in the effort to deny information from GCC being worked by the very folks who advocate completely open access to programs' source code?

Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 14:36 UTC (Thu) by anselm (subscriber, #2796) [Link]

It is ironic but there is no way RMS will be able to keep people from doing the GCC-Emacs integration if they really want to. We may end up with forks of GCC and Emacs but it's not as if that hadn't happened before, on both the GCC and Emacs sides.

I've abandonded Emacs for serious development

Posted Jan 15, 2015 14:39 UTC (Thu) by pflugstad (subscriber, #224) [Link] (7 responses)

About 10 years ago I got involved in some large Java programming and started using Eclipse. I was BLOWN AWAY by how easy many common tasks were - refactoring, renaming, simply navigating around (alt-Left, alt-Right for going forward and backward in your "editor history"), automatically generating getters/setters, etc. All the grunt work of programming.

At the time, I tried to use Eclipse on some C/C++ code, but the CDT just wasn't ready yet.

Then a couple of years ago, I got started on a new pure C code project and used Eclipse for everything, including an incredibly ancient Cygwin GCC (EGCS anyone) based cross-compiler, modern Cygwin GCC, Linux GCC, MinGW, Visual Studio's compilers, etc. Eclipse CDT generates the makefiles for all of those (decent ones, not recursive make, and parallel builds work correctly), integrates with version control, etc - I can even run my executable under gdb-server on my target hardware and debug from Eclipse.

I've also recently used it on a very complex C++ application (boost, eigen and libPCL) - I initially had to get the bleeding edge CDT to survive it (older CDTs run out of stack), but that's been released now, so now the stable Eclipse survives probably the most complex and templated C++ code I've ever seen.

I've used Eclipse for Android development as well, and TI's Code Composer (based on Eclipse) as well - and I believe WR's vxWorks dev IDE is as well, but Ive not used that. It's clear to see that its openness and momentum was allowing for a huge explosion in development and use, by both commercial AND open source users.

At the end of the day, it's about getting stuff done, and tools like Eclipse let me be more productive. Oh I still use Emacs for smaller things - quick edits, shell scripts, editing on a remote server, etc... but for serious development, Eclipse wins hands down.

(Queue the responses the point out the myriad Emacs add-ons, plug-ins, etc, that make it kind of work like Eclipse... sorry guys, about 5 years too late).

I've abandonded Emacs for serious development

Posted Jan 15, 2015 19:53 UTC (Thu) by alvieboy (guest, #51617) [Link] (6 responses)

I have used Eclipse myself, in a few projects, for Java and C++. I ditched it completely, because it's slow, uses too many resources, and overall the editor is not as good as I want (btw, I gave up on complex IDEs a long time ago, and use FTE as my primary editor).

Google, fortunately, decided to ditch Eclipse too. I never managed to get it to properly work for Andriod development in my system. IDEA works much better than Eclipse in that respect.

Some vendors still use Eclipse, because they need an extensible IDE, but they chose it because there's nothing else (free) to choose from. Texas Instruments, Cypress, many others still base their development environment in Eclipse. Some have command line tools to do the job (compiling, debugging, uploading), some do not, or do not work well (TI debugger for TMS320F in Eclipse is a mess, as well as the provided API).

Eclipse does have some nice features, but it became a mess.

Unfortunately, there's no decent, full-featured IDE using another framework (Qt for example).

I've abandonded Emacs for serious development

Posted Jan 15, 2015 20:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Eclipse does have some nice features, but it became a mess.
> Unfortunately, there's no decent, full-featured IDE using another framework (Qt for example).
There is. It's IntelliJ IDEA and that's what Google now uses for Android.

And yes, they have a C++ IDE (currently in alpha: http://blog.jetbrains.com/clion/ )

I've abandonded Emacs for serious development

Posted Jan 15, 2015 21:14 UTC (Thu) by pflugstad (subscriber, #224) [Link] (1 responses)

IDEA itself doesn't do C/C++. I just saw the announcement on CLion - I'll have to check it out when it matures some more. I'm not sure I like it depending on cmake, but I admittedly haven't used cmake much, and it's certainly better than autoconf.

I don't disagree that Eclipse has gotten bloated, but I think that's mostly the extra crap they load on on the default Java version for doing RCP development and lots of other extra stuff. I just get the CDT(C/C++) version without all that. I'm running it on a 3+ year old PC right now with 8GB of RAM and it runs just fine.

In any case, my point was that I agree with what others have said about RMS: he's dangerously out of date w.r.t. modern tooling and languages - C++ is over 20 years old at this point. I respect him a lot, and I don't want him to go away (unlike some others), but he needs to recognize his shortcomings and step back from controlling the development of things so much.

If not, well, I really do hope someone forks GCC (and Emacs) - it's happened before (with BOTH of them) and it was a good thing in both cases (IMO). The increased competition with clang/LLVM would certainly improve BOTH products.

I've abandonded Emacs for serious development

Posted Jan 15, 2015 21:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

IntelliJ is a platform, kinda like Eclipse. There'll probably be a plugin version of C++ for IDEA, but later. Right now it's available as a separate IDE but it's the same IntelliJ underneath.

It will also support other build systems once it matures a bit.

I've abandonded Emacs for serious development

Posted Jan 16, 2015 11:02 UTC (Fri) by macson_g (guest, #12717) [Link]

I wouldn't call QtCreator a "full-featured IDE", but it's definitely "decent". It hits a sweet spot between simplicity and power. I use it happily at home and at work.

I can strongly recommend it to anyone, it's easy to get started, you don't need to spent time on configuring "workspaces" or "projects", you can just point it to your Makefile/CMakeLists.txt and get going.

And the clang-based code model is sooo nice!

I've abandonded Emacs for serious development

Posted Jan 21, 2015 14:29 UTC (Wed) by mgedmin (subscriber, #34497) [Link]

> Unfortunately, there's no decent, full-featured IDE using another framework (Qt for example).

GNOME Builder aims to become such, and is currently having a pretty successful fundraiser: https://www.indiegogo.com/projects/builder-an-ide-of-our-...

I've abandonded Emacs for serious development

Posted Feb 2, 2015 18:40 UTC (Mon) by yoe (guest, #25743) [Link]

It depends on what you call 'full-featured', but qt-creator is pretty good.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 6:57 UTC (Fri) by MKesper (subscriber, #38539) [Link] (1 responses)

Is there any policy when sending a free link to other sites (Hacker News etc.) is ok?

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 15:37 UTC (Fri) by jake (editor, #205) [Link]

> Is there any policy when sending a free link to other sites (Hacker News etc.) is ok?

There is some information in the FAQ: https://lwn.net/op/FAQ.lwn#slinks

It says:

Where is it appropriate to post a subscriber link?

Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.

I don't think we have seen really any abuse of the subscriber links over the years. We should probably be a bit more explicit in the FAQ about things like G+, Hacker News, etc. -- links have been posted to those places without any noticeable problems, at least so far ...

jake

Reality check

Posted Jan 16, 2015 8:26 UTC (Fri) by oldtomas (guest, #72579) [Link] (6 responses)

Folks, I need a reality check. Reading the discussion, I'm a bit horrified by the downright hostile tone towards RMS. I mean -- one might disagree with him (and in this one point I do personally disagree[1]), but this guy deserves more respect than that, and a civil discussion.

He's stubborn, but world might be a worse place to be in without his stubbornness.

And hey -- I've disagreed with him before at times to just find out in hindsight that he was right after all. Perhaps he's a better visionary than I am.

Reality check: is my perception of the general tone off? Do I need to re-calibrate my detectors?

[1] The gcc-melt [http://gcc-melt.org/] project is just too terrific a toy to not want to play with it, right?

Reality check

Posted Jan 16, 2015 8:51 UTC (Fri) by josh (subscriber, #17465) [Link]

I don't see anyone in this discussion unfairly maligning RMS. Rather, I see a pile of people all reading statements like the one that best sums up this article:

and reacting with appropriate amounts of disgust.

As pointed out in the very first comment on this story, this whole notion is out of date. I personally prefer the GPL to permissive licenses, but that isn't the issue at hand. GCC long-since missed its opportunity to provide a useful tool for extensible language parsing and processing, not due to any licensing decision but due to mismanagement.

Yes, decades ago the GPL on GCC worked well with Apple and Objective C. Today, however, there's *already* a library providing full C/C++ parsing, syntax handling, and many other useful tools: libclang. Using that would make sense, but fine, emacs is a GNU project, it's understandable to promote use of GNU GCC, even though GCC is ill-equipped to solve this problem precisely because it has been hamstrung.

But to then turn around after requesting that and reject usage of GCC for the same purpose, for any functionality but what one developer can personally envision anyone wanting (because nobody could possibly have any other needs or workflow), based on precisely the same outdated premise that makes GCC less suitable than libclang for this application, simply spits in the face of developers interested in contributing to emacs. It's hostile, disrespectful, and short-sighted, and it deserves precisely one reaction:

"Thank you for demonstrating that libclang was the right choice to begin with, and that GCC is still not suitable for this kind of project."

Reality check

Posted Jan 16, 2015 9:16 UTC (Fri) by rsidd (subscriber, #2582) [Link] (3 responses)

It's not about respect, it's frustration over one man blocking progress for months now on programs that HE originated: programs that were path-breaking in the 1980s but no longer are. It appears that RMS considers it more important to hinder non-free software than to improve free software. Even if you agree with him on that (and few would), the point is that ship has sailed -- other compiler tools (LLVM) and IDEs (Eclipse etc) are way ahead and have been for a while, are preferred today by most commercial vendors, and are continuing to improve (with significant help from those same commercial vendors), so nothing can be gained by keeping gcc behind. The frustrated comments come from people who want to see GCC and emacs improve. Of course, forking is always an option, and GCC even has one successful precedent for it (in the sense of being able to re-merge eventually).

Reality check

Posted Jan 17, 2015 2:01 UTC (Sat) by rahvin (guest, #16953) [Link] (2 responses)

Something that's been bothering me about this is I thought RMS lost his "overlord" role with GCC with the former split and that the only software he still only had any real control over (as in project dictator/director/decision maker) was emacs.

It would seem my memory of history is either distorted or out of date because he must have a role or no one would be consulting him about what GCC can do. (as google is failing me here) Is RMS still the main decision maker for GCC these days or hold a key decision making role? Because I thought the whole egcc split thing sidelined him into an advisory role when they re-merged.

Honestly if he's so out of date that he's never even used C++ he really shouldn't be in any management role for software which is used in programming, either GCC or emacs for that matter. To provide a car analogy, I wouldn't find myself qualified to design race tracks if the only thing I'd ever driven was a go-cart (or vice-versa if you don't like C++ being the race track). The differences between programming 20 years ago and today are vast and if you haven't stayed up to date you don't even really know what the issues are let alone the proper feature set.

Don't get me wrong, I like RMS. Free software needs an uncompromising evangelist to keep the movement steered towards the goals. But that doesn't mean he needs to be making feature decisions on a software package if his knowledge and actual programming experience is dated.

Reality check

Posted Jan 20, 2015 4:46 UTC (Tue) by k8to (guest, #15413) [Link]

Personally, I think avoiding C++ shows good taste.

However, not really knowing much about it at all isn't as encouraging.

Reality check

Posted Jan 22, 2015 13:45 UTC (Thu) by Wol (subscriber, #4433) [Link]

> or vice-versa if you don't like C++ being the race track

Race tracks don't go anywhere, or at least, only in circles :-)

Cheers,
Wol

Reality check

Posted Jan 16, 2015 18:14 UTC (Fri) by k8to (guest, #15413) [Link]

I'd rather say that RMS is disrespecting everyone else, by insisting that things he hasn't put any effort into understanding (for decades) must go through his personal understanding and say-so on grounds that are not really technical at all nor practical.

There is certainly a relationship between the RMS extreme stubbornness and this behavior where he believes that his sole arbitration of technology he does not seem to be interested in understanding is reasonable. The personality traits can be beneficial sometimes, but they're certainly not right now.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 12:05 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]

>Stallman would like to see some kind of investigation to determine what pieces of information are needed for which purposes (e.g. auto-completion, refactoring, and so on), but that seems short-sighted to some.

In other words, somebody be a prophet and predict all future, currently unanticipated, uses.
With all the massive respect due RMS, this seems a trifle myopic.

Extracting the abstract syntax tree from GCC

Posted Jan 17, 2015 0:00 UTC (Sat) by rdc (guest, #87801) [Link] (2 responses)

I am glad to see people pointing out the hypocrisy of Stallman's position, in protecting freedom he is limiting freedom of devs, users and usefulness of the tools he has championed for decades, and appears unable to see the problem

Extracting the abstract syntax tree from GCC

Posted Jan 17, 2015 12:53 UTC (Sat) by seyman (subscriber, #1172) [Link] (1 responses)

> he is limiting freedom of devs, users

He is doing no such thing. If others feel that Emacs badly needs a specific feature, they are free to fork it or fund someone else to do so.

Saying that FLOSS users are as helpless before the editor of their software as users of proprietary software is a confession that the speaker understands very little about Free Software.

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 4:48 UTC (Tue) by k8to (guest, #15413) [Link]

I don't think it was claimed that proprietary software is equivalent to this situation.

However, it's *also* not as simple as "just fork if you want" when that would be a pretty expensive action for a project with the history and culture of Emacs.

It's not like we don't have history to go by here.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 16:01 UTC (Mon) by danieldk (subscriber, #27876) [Link]

> It is clear that Stallman has not used any of the "competing" IDEs (e.g. Xcode, IntelliJ IDEA), which is not a huge surprise,

Note, in contrast to what Metzger says, IntelliJ itself is open source under the Apache 2 License:

http://www.jetbrains.org/display/IJOS/Ultimate+Edition+vs...

They have proprietary extensions, which are bundled in the Ultimate edition.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 20:15 UTC (Mon) by ms_43 (subscriber, #99293) [Link] (6 responses)

This is quite tragic, because it's not like corporations were in any way prevented from hooking up GCC's front end to a proprietary optimizer in the past.

For example, Sun had a "GCC for SPARC Systems" product:

https://gcc.gnu.org/ml/gcc/2006-03/msg00140.html

This blog claims that (at the time) the proprietary PathScale compiler was based on a GCC front-end:

http://tirania.org/blog/archive/2004/Apr-18.html
https://web.archive.org/web/20080103174738/http://pathsca...

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 2:25 UTC (Tue) by dgm (subscriber, #49227) [Link] (5 responses)

The FSF is the proprietor of all copyrights to GCC. Maybe they licensed the GCC front end?

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 2:32 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Are you honestly suggesting that FSF allowed a vendor to get a proprietary license for any software from them?

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 7:56 UTC (Tue) by mfukar (subscriber, #70215) [Link]

Imagine all the ruckus it would raise if that were true, huh?

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 11:40 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Highly unlikely!

That FSF didn't make a violation stink about this back in the day suggests it must have been GPL compatible someway. I'd assume by way of the exception in the GPL that allows linking to system libraries. ??

Though, reading the thread it seems to me the libs GCC was modified to work with were delivered by the Sun Studio compiler packages - which weren't ever part of base Solaris, certainly not then anyway.

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 18:32 UTC (Tue) by ms_43 (subscriber, #99293) [Link] (1 responses)

The obvious way to do it is modify GCC to dump some intermediate representation (there are several at different levels, including the AST the article is about) to a file, and then read that file with a second process that contains the proprietary secret sauce. No linkage necessary.

Extracting the abstract syntax tree from GCC

Posted Jan 22, 2015 13:56 UTC (Thu) by mlopezibanez (guest, #66088) [Link]

This widespread misconception seems to come from an idealized view of how a compiler works. GCC at least does not work this way: the FE often calls the back-end to get some values and the middle-end calls into the FE to get others. Moreover, there is not "an" intermediate representation, but a collection of data structures tightly coupled. It is possible to serialize some of this data into an on-disk representation (in fact, LTO is doing precisely this), but many issues remain to be solved and the representation would still be tightly coupled with GCC internals.

Any company seriously thinking about using such an approach to extend GCC is doomed to fail (and they have failed in the past) and, in the case of proprietary extensions, they will get no help from the community in solving their issues.

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 23:31 UTC (Tue) by pinskia (guest, #98458) [Link]

I have not seen one discussion about this on the GCC mailing list. So until someone actually start programming this up, there is no way really to say if it is going to have the issues that RMS is talking about.

Why not get the AST from LLVM ?

Posted Jan 22, 2015 10:07 UTC (Thu) by moltonel (guest, #45207) [Link] (1 responses)

If there's such a political barrier about gcc ast, why doesn't the author of the emacs completion work switch to using llvm, and get on with life ?

I can understand the desire to remain "GNU-pure" by using gcc with emacs, but at some point a pragmatism check is needed. Switching backend sounds like a much less dramatic outcome than abandoning the project.

But maybe the contributor has been burned once too many, and doesn't have the energy to refactor and/or justify himself again. Such a waste :(

Why not get the AST from LLVM ?

Posted Jan 22, 2015 20:58 UTC (Thu) by rodgerd (guest, #58896) [Link]

If I've understood the saga correctly, she was going to use LLVM until Stallman persuaded her to use the full GNU toolchain, and *then* he sat on his hands before coming out against the idea. I think that's what rankles so much for people - he's wasted a lot of this developer's time.

Extracting the abstract syntax tree from GCC

Posted Jan 22, 2015 13:44 UTC (Thu) by mlopezibanez (guest, #66088) [Link]

What is missing from the discussion and the article (and what any *active* GCC developer will tell you) is that the AST of GCC C/C++ FEs has fundamental limitations for source code analysis, specially for refactoring, thus, nobody should expect that dumping GCC AST will somehow magically allow Emacs hackers to not need to "hack on GCC for every feature we want to add to Emacs". Even motivated devs such as AdaCore and Mozilla have tried to use GCC AST and given up because it is not complete enough. It is not a question of dumping the AST or not: There is a huge amount of work to do before GCC's AST can be useful for any source code analysis.

In my humble opinion, given Clang vs. GCC status as FEs, even if GCC dumped its AST today, nobody in their sane mind will spend any effort whatsoever to build a GCC AST reader just to enable some proprietary source code analysis, middle-end optimization or target backend. (There are good reasons why each of these potential uses would not become easier by dumping GCC's AST).

As one of the GCC developers working during the last ten years on reducing the gap between GCC and Clang, I would suggest that Emacs developers who are happy with Clang should just use it to improve Emacs (I'm also an Emacs user!) and those that are unhappy with Clang should just join the GCC team and help us such that in some years, GCC could be an alternative. Anything else is just noise.