
Defending GCC considered futile - ekianjo
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00457.html
======
Aqueous
Despite the inflexibility of RMS' arguments (they grate on me as much as
anyone) I feel like his position on continuing to develop GCC without modern
features like a fully exposed AST is necessary to keep the "moderate" position
where it is.

In other words, RMS' radical position is necessary for 'moderate' LLVM to
exist. Otherwise we'd still be living in the Borland/Metrowerks/Microsoft
world of the 90s - proprietary toolsets developed by private companies with
absolutely no intention or incentive to share their code.

In polisci there is a concept called the "Overton window." If a once-extremely
radical position is held and promoted by any significant number of people, it
shifts the entire conversation in that direction so that the formerly radical
position seems more moderate.

That's why RMS is very necessary. He shifts the Overton Window towards what
most of us consider the "reasonable" position.

~~~
cynicalkane
This is false--people are just as likely to respond to opposing arguments with
rejection and ideological hardening. This is replicated in psychological
studies.

In my personal experience, the less the opposing position acknowledges the
values of its opponents, the more likely it is to be rejected. Most people
reason by mood affiliation and use argumentation as a social tool, so this
should not be a surprise.

I think the "Overton window" is confusing cause and effect; it's the nature of
reasonable positions to generate unreasonable fanatics at the tail ends. But
if you pay attention to the loud fanatics at a given point of time, you find
most of them do not shift any window but instead fall into irrelevance. I
think that as RMS's software becomes less important, people will care less
about what he has to say.

~~~
Aqueous
Sure - "The loud fanatics" who have no following certainly drop into
irrelevance. I think if what you say were completely true we would not have
had any movement forward on positions that were considered radical just 10 -
20 years ago - like same-sex marriage. It is only because certain people with
large followings - Andrew Sullivan and others - began making a vocal argument
for gay marriage, which wasn't even considered a mainstream position until
very recently, that it is now the law of the land in so many states.

Radicals have to be able to articulate their position in a way that is
compelling and reasonable to a significant number of people in order for there
to be a shift. But I think political progress is largely explained by this
phenomenon.

~~~
leovonl
There's an enormous difference between having an opinion which is not aligned
with mainstream and being a radical.

The radical usually wants the world to convert to his/hers own views, which is
why they tend to get closed minded and hard to talk with as they get older.

~~~
RodericDay
_" I'll say nothing against him. At one time the whites in the United States
called him a racialist, and extremist, and a Communist. Then the Black Muslims
came along and the whites thanked the Lord for Martin Luther King."_

------
lultimouomo
ESR seems a bit over the line with this mail, but what never ceases to amaze
me is how RMS is disconnected with the present technology:

>From its name, I guess that LLDB is a noncopylefted debugger and that some
might intend it to replace GDB. But I don't know if that is so.

This is just one of many, in the recent arguments he has stated several times
that he doesn't understand how automated code refactoring works, he has not
experience with IDEs, and things of the like.

Beside the ideological point, he does not seem a person capable of steering
important projects, at least when it comes to compiler technology. He just
doesn't know enough anymore.

~~~
rayiner
We're talking about a C compiler and debugger. Lots of very technically
knowledgable people shun IDEs and automated refactoring in that space.

~~~
pjmlp
Only in the UNIX world.

In the game development world, embedded systems and desktops we like our IDEs.

~~~
vetinari
We are working with certain expensive application, developed by one big
multinational, that has virtual machine for extending the funtionality by the
user (or more realistically, contractor).

The supplied IDE for development is Emacs.

~~~
aardvark179
Is it a GIS application?

~~~
vetinari
Yes, it is.

~~~
CptMauli
Don't tell me that Smallworld is still started from Emacs???

~~~
vetinari
It is an option. However, I'm one of those guys, who like it that way :-)

------
zanny
So this was a discussion in /r/linux last week about LLVM and GCC et al, so
I'm just reposting my statements on why a world where GCC is irrelevant is
bad:

It takes little effort on Apples or Googles or Microsofts part to take
advantage of an LLVM dominated world to close off their own changes to it and
try to force developers to use their own proprietary LLVM distributions on
their own operating systems. It stops every other company in the future from
taking advantage of all the great LLVM tech to implement their own CPUs in
terms of LLVM IR, so they never need to publish their ISA and they can lock
down their platform with a blob LLVM of their own. The only thing stopping any
of that from happening is GCC being a still competitive alternative.

If LLVM came to dominate the compiler scene to such a degree that GCC were
irrelevant, it opens the flood gates to any major company forking LLVM into a
proprietary paid for compiler that they require on their OS to profit from. It
lets you do anything from what Apple is already doing with Swift, where you
create a programming language with a proprietary compiler, or you could go
from the other end and implement a proprietary translation unit so that you
never need to publish your ISA (something Nvidia never does) but that allows
all the LLVM compilers to target it.

Right now, nobody can close off their LLVM contributions because a hobbled and
fractured LLVM ecosystem is one that cannot overcome GCC. In the same way
Apple and Google had to cooperate on webkit until it was so dominate they were
in a position to fork and do their own things with it once Gecko was rendered
effectively irrelevant, but the difference is that webkit was LGPL and Clang
is its own permissive license - they still cannot directly modify the free
software parts without redistribution, so it is harder to make a proprietary
webkit, but Apple surely has succeeded since they have their own proprietary
patchset on top of trunk webkit nowadays.

~~~
josephg
I'm always confused by this stance. It presupposes that big companies like
Apple and Google will at some point become bad actors in the opensource world.
(They both contribute huge amounts of code). Even Microsoft is starting to
open up their codebase with the release of huge parts of the .NET ecosystem.

Frankly, I want the big boys on my side when it comes to opensource code. I
want them to use the code I write. Usually I indirectly benefit from them
using my code anyway, and they benefit, and everyone's happy. This is true
even if they decide to make proprietary changes which don't get pushed
upstream. I gain influence in my community and lucrative job offers. I get
invited to talk at tech conferences, and my projects (present and future)
attract more attention. I honestly don't see the downside here.

Apple might have a change of leadership and decide to swim against the current
and make LLVM proprietary, but if that happens can't we just fork it? As far
as I can see, MariaDB is doing just fine. And until that happens (which will
probably be never), we can get some huge compiler ecosystem improvements on
Apple's dime. All opensource.

Am I missing something, or is this fear of corporations totally unjustified?

~~~
vetinari
That pressupossition is not that unrealistic.

For example, see shader compilers for GPUs. How many open shader compilers do
you see around? Is there any motivation to open them?

On the other side, during the 90's, we have seen many vendors come with new
CPU ISAs, extensions of existing ISAs, new SOCs, etc. Many of them didn't have
resources or will to write a new C compiler, so they wanted to use someting
existing. They were willing to write new GCC backend - and GCC license
basically forced them to be open. After this, there was no point in keeping
ISA specification secret.

LLVM/clang does not have this effect. It pretty much rewards for being closed.
So today, we have shitty (especially on ARM-SoCs) shader compilers for secret
ISAs, and you aren't going to see their sources anytime soon.

~~~
j_s
I am not very familiar with the world of shader compilers, but it seems like
you have provided the most concrete example I've heard yet of how GCC
benefited in the long term in a way that LLVM/clang didn't.

I would love to hear from anyone with more expertise in this realm who might
be able to dispute this claim in any way... otherwise this seems to be a
smoking gun in GCC's favor!

~~~
GalacticDomin8r
I'm not sure about the exact conclusion you seem to draw but it seems to be
something like "GPL projects tend to have better outcomes than non-GPL". The
whole point of the thread doesn't support that conclusion coming directly from
the GCC brain trust. It's only natural that niche GCC users are going to hang
around the longest.

I'd also like to note LLVM/clang didn't gain large non-apple marketshare until
GCC adopted GPLv3 which has more to with it's stagnation than anything IMO. v2
is palatable to many business needs, v3 is not.

~~~
j_s
Mostly I was looking for a specific/practical current example where using LLVM
allowed a company to release something closed-source, where they would have
been forced to open it if they used GCC.

The rubber apparently meets the road with the NVidia shader compiler.

------
pekk
I strongly disagree with RMS on some issues (like Snowden) and I don't share
his hard line on proprietary software either. But RMS is just a particular
kind of animal. I respect the need for that animal in a diverse ecosystem and
I respect the reasoning behind free software.

In particular, I think gcc has played an _essential_ role in providing free
software to users _because_ it is licensed under the GPL. The BSD license is
great for less important things, but the moment giant corporations have
engineered the whole "open source" ecosystem so that they can distribute forks
of _all the basic build tools_ without contributing changes to the public
where we can see and influence them - that's the moment we've handed over the
keys to the kingdom. You have to be pretty out of touch with _history_ not to
see that point.

To hear the way HN talks about RMS, he is a nerdy, smelly, arrogant,
technically ignorant Emmanuel Goldstein, representing everything we hate most
about the nerdy computing world that pre-existed the current startup gold rush
(but which, coincidentally, entirely enabled it and us). Now a large
proportion of us here secretly harbor the belief that we are the next Steve
Jobs, so we pine for the good old days when people like that made bank on
companies whose business models were entirely based on platform lock-in.
Because so few of us actually remember how fucked up it really was for all the
users and programmers. Because we don't consider ourselves users and
programmers, just temporarily embarrassed millionaires and Chief Engineering
Architect Engineers. So it's no wonder that HN still doesn't understand the
point of GPL. Just like most of Marin county now thinks measles is something
to cultivate, like acidophilus.

~~~
twic
> The BSD license is great for less important things, but the moment giant
> corporations have engineered the whole "open source" ecosystem so that they
> can distribute forks of all the basic build tools without contributing
> changes to the public where we can see and influence them - that's the
> moment we've handed over the keys to the kingdom. You have to be pretty out
> of touch with history not to see that point.

So when in history has this actually occurred?

------
michaelhoffman
Thankfully, Emacs maintainer Stefan Monnier is being sensible about this:

> As mentioned earlier, in any case I will happily accept and install LLDB
> support into gud.el. So as long as I'm Emacs maintainer, your opinion on
> whether this might ruin the FSF's goals are not relevant.

[https://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00498.html)

~~~
dekhn
Yeah. What's especially painful is RMS is basically saying "Hey folks, I want
to block this until I can research the issue." And then his research is "I
don't know anuything about this, can anybody tell me what LLDB is?"

My guess is (based on his past statements) that he doesn't browse the web, or
browses it through emacs sending mail to him (really!) and doesn't use search
so he can't really find out what LLDB is.

Do you really want to be beholden to a person who blocks software integration
(into a unified debugger interface) and then can't even do reearch to justify
that?

~~~
longlivegnu
Yes, RMS does not "browse the web" he has a server that runs a script sort of
like wget or cURL.

~~~
protomyth
Is there a source for why he doesn't "browse the web"? I've read about how he
does it, but the articles I have seen are very light on the reason.

~~~
tjr
[https://stallman.org/stallman-computing.html](https://stallman.org/stallman-
computing.html)

I've never heard him flat-out say "why", but it sure appears to be in order to
maximize anonymity / privacy on the web.

------
sanxiyn
This is a bit over the top. As the rest of the thread points out, GCC in
general still generates faster code than LLVM.

"What does it take to get LLVM as performant as GCC" talk from 2014 LLVM
Developers' Meeting discusses details.

[http://llvm.org/devmtg/2014-10/Slides/Molloy-LLVM-
Performant...](http://llvm.org/devmtg/2014-10/Slides/Molloy-LLVM-Performant-
As-GCC-llvm-dev-2014.pdf)

"GCC versus LLVM performance analysis reveals the LLVM inliner 1) does not
inline certain hot functions unless a high threshold is provided at -O3 2)
produces larger and slower code at -Os."

The problem of LLVM inliner has been known for a long time. One of the best
discussion is "Optimization in LLVM" talk from 2013 European LLVM Conference.

[http://www.irill.org/videos/euro-llvm-2013/carruth-
hires](http://www.irill.org/videos/euro-llvm-2013/carruth-hires)

~~~
darkpore
Does it?

[http://imagine-rt.blogspot.co.uk/2014/12/c-compiler-
benchmar...](http://imagine-rt.blogspot.co.uk/2014/12/c-compiler-
benchmarks.html)

~~~
sanxiyn
Yes it does. Did you read my links?

Small benchmarks can go either way, but for large codebase (especially C++)
inliner is more important than just about anything else. So GCC wins, because
it has better inliner.

~~~
darkpore
Yep - you evidently didn't read mine as 165 k lines of c++ isn't exactly a
small benchmark :)

Anecdotal, but I've seen similar improvements over g++ in my code.

~~~
sanxiyn
There are many measures of benchmark sizes. One important measure is size of
codes that account for 99% of execution time. If your codebase is a million
lines but your hotspot is a thousand lines, benchmark result is sensitive to
optimization quirks and in some sense benchmark is small.

More on this idea here: [http://blog.pyston.org/2014/12/05/python-benchmark-
sizes/](http://blog.pyston.org/2014/12/05/python-benchmark-sizes/)

------
hywel
> Already my own experiments suggest that LLVM is a superior compiler, by
> every metric I know of

Except that it isn't copyleft, which is one of the most important metrics to
Stallman, FSF et al, and is why they're unlikely to stop defending it.

~~~
Htsthbjig
It is copyleft. In fact they leave you more rights to copy the source than
GPL.

~~~
hywel
From
[http://llvm.org/docs/DeveloperPolicy.html#license](http://llvm.org/docs/DeveloperPolicy.html#license):

"LLVM’s license is not a “copyleft” license like the GPL."

Rights to copy the source is not what copyleft means.

------
nothrabannosir

        Obsolescence happens; this is nobody's fault.  It will happen to
        clang/LLVM someday, too, but today is not that day.
    

This is a beautiful line. Very wise, and it will hopefully help soothe the
otherwise pretty harsh message.

------
josteink
This quarrel should be considered in context of the LLDB patch being submitted
to gud.el.

For those who want to read it from the start:
[http://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg002...](http://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00274.html)

What made it a mega-thread was when RMS weighed in:
[http://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg003...](http://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00360.html)

------
phkahler
Reading ESR tends to make me angry in a special way. I can understand people
who prefer a BSD/MIT license over the GPL - they usually seem to understand
the difference and claim the former are "more free" while kind of
understanding the point of the later but disagreeing with its importance. But
when I read ESR, he seems to have it in for the FSF and doesn't really seem to
respect or even understand the philosophy at all. I've come to view him as a
formerly-high-profile troll.

~~~
GFK_of_xmaspast
Remember that ESR writes things like this:
[http://esr.ibiblio.org/?p=5001](http://esr.ibiblio.org/?p=5001) in all
apparent seriousness.

------
alayne
I don't know why you would make this argument now. Stallman argued clearly in
January why copyleft was more important to him than technical superiority.
[https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html](https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html)

~~~
cwyers
Everybody already knew that copyleft was more important to Stallman than
technical superiority. The problem is that there are a lot of people who put a
higher value on technical superiority than copyleft. Those people could be
counted upon as GCC users and contributors as long as GCC was the technically
best compiler available as open source (all free software is open source, not
all open source is free software, etc.).

RMS's goal seems to be to have GCC not be replaced by LLVM. From a reply
downthread of ESR's post:

> This means it is more than a potential problem.

> The possible harm is to replace copylefted GNU package with noncopylefted
> code. They must have worked for a long long time to replace the capabilities
> GDB already had.

So RMS thinks it's a "problem" and "harmful" if lldb replaced gdb. So RMS
cares not just about what GCC does, but whether or not other people adopt GCC
as well. In terms of that goal, it _does not matter_ what RMS considers more
important. RMS is not going to convince everyone else to use GCC instead of
LLVM by simply restating his arguements about copyleft forcefully again and
again. That doesn't mean he has to sacrifice his feelings about copyleft. But
it does mean he has to give a damn about being technically superior to LLVM
and lldb if he wants to beat them.

~~~
vidarh
He does not need to beat LLVM for GCC to remain available.

It would be detrimental to GCC to lose developers, sure, but I think one of
the reasons for the disconnect between RMS and others is that RMS' goals does
not require a large user base, and so he is willing to make decisions that
seems counterproductive to anyone who cares about usability and user
acceptance first.

The mere continued existence of GCC (and the other GNU tools) in many ways
safeguards the freedoms he cares about: It allows users to jump ship if they
in the future are prevented from doing what they want with the alternatives.
It's not the ideal scenario, but it better serves his goals than giving in,
and potentially see these freedoms slipping away at some future point.

Of course he'd be better served by GCC outcompeting LLVM. But if that isn't
happening, his goals are better served by slowing developer migration than
"capitulating" in a way that might affect developer mindshare by putting LLVM
tools in front of more people.

As you say, of course the problem with this is that a lot of us care more
about the technical superiority. _Especially_ when the competition is a
project that is as open as LLVM.

------
ajarmst
I continue to be amazed at people buying into the ESR-authored consensual
hallucination about his role and importance. His primary creative contribution
to the community has been a fictional mythology starring himself.

------
arca_vorago
Can someone explain to me what all the hubub is about. As far as I understand
it and even as RMS himself states, isn't this mostly about them trying to
block clang/LLVM tie ins to the debugger more than anything else?

I don't understand whats with all the _gcc sucks_ attitude these days. It's
worked for quite some time, and yes it's showing some age due to the lack of
development so it has lagged behind others, but we should all be worried when
people very influential in the GNU community start talking about why GCC is
bad.

I don't like this line of thinking at all.

If GCC is behind, fork it and do what needs to be done to make it competitive.

~~~
phkahler
>>Can someone explain to me what all the hubub is about. As far as I
understand it and even as RMS himself states, isn't this mostly about them
trying to block clang/LLVM tie ins to the debugger more than anything else?

The "problem" RMS has with llvm is its non-copyleft license. And yes, the
issue is that he doesn't want to support llvn with GNU tools. When LLVM
started they used GCCs front end to compile C code until their own matured
enough. So parts of GCC were being used to develop the middle and back ends of
llvm. The LLVM ecosystem is systematically replacing the GNU toolchain with
non-copyleft licensed versions and RMS does not want to support that in any
way.

>> I don't understand whats with all the gcc sucks attitude these days. It's
worked for quite some time, and yes it's showing some age due to the lack of
development so it has lagged behind others, but we should all be worried when
people very influential in the GNU community start talking about why GCC is
bad.

I don't understand it either. GCC is still a great compiler. Developers seem
to prefer the modular design of LLVM and they're probably right in that. Users
like some of the features enabled by that design as well - IDE integration and
cross compilation come to mind. GCC is starting to move, but slowly.

>> I don't like this line of thinking at all.

>> If GCC is behind, fork it and do what needs to be done to make it
competitive.

You make it sound like there are lots of compiler developers with time on
their hands for open source development AND who share the licensing philosophy
AND are unhappy with GCCs development path. Apparently there are not.

~~~
Htsthbjig
"I don't understand it either. GCC is still a great compiler. Developers seem
to prefer the modular design of LLVM and they're probably right in that."

There are lots of things that are simply very hard to do with GCC, but are
easily doable with LLWM.

IDE integration is just one, because it has the ability to compile just
lines(at least the Apple's version).

Things we have done with LLVM:

Millions of mollecules 3D paths' rendering.

Automatic testing of software and hardware.

Simulation of military vehicles doing all kinds of things.

Digital crash test.

Natural language(speech) understanding.

Before LLVM doing all this took years, now it takes months or weeks.

This exploits the ability of understanding languages of a compiler, but is not
just compiling c or c++ like gcc does.

~~~
arca_vorago
Could you please expand on what particular features of LLVM enabled you to do
this in months/weeks instead of years (presumably with gcc)?

------
wspeirs
I was under the impression that GCC would stick around as long as the Linux
Kernel was in existence because there was a tight requirement for GCC to
compile the Linux Kernel... well I was wrong!
[http://llvm.linuxfoundation.org/](http://llvm.linuxfoundation.org/) shows the
status of getting the Linux Kernel to compile using CLANG... and according to
the stats as of 1/28/2015 there are only 41 patches required to make this
work.

I wonder if any of the big distros will start compiling with CLANG instead of
GCC?

------
copsarebastards
I agree with Eric Raymond that GCC probably can't beat Clang.

However, I don't agree that this means we should just jump on the LLVM train.
The world still needs GNU. And LLVM isn't GNU.

The GNU community has historically held dominance in the compiler field, so
this is an uncomfortable time. We can no longer rely on the popularity of GCC
to keep GNU in the forefront. However, this doesn't mean we should just give
up--I think the solution is to start again from first principles and build a
better system, an alternative to GCC that is also released under the GPL.

I'm not saying we should drop support for GCC. But we need to innovate: GCC
became dominant because it was innovative and it lost dominance because it
stopped innovating. LLVM isn't the only non-GNU competitor. It's telling that
none of the major new languages (Go, Rust, Clojure, Scala) are released under
the GPL.

~~~
kibwen
The implementations of new languages aren't being released as GPL because the
process of introducing a new programming language is already a nearly
insurmountable task. To this end, language authors seek every advantage they
can get. Nobody's ever chosen a programming language by virtue of the fact
that its implementation was GPL, but I can easily see people ruling out such a
programming language out of fear that the use of such an implementation will
infect their own code with GPL (I fully acknowledge that this fear is
unwarranted if your licensing is set up properly, but it actually _can_ be
rather tricky to get right and most people are rightfully fearful of
interpreting this sort of thing on their own).

At the same time no developer of a fledgling language is going to worry about
someone coming in and taking their permissively-licensed code without
contributing back, because getting to the stage where someone cares enough to
seriously fork your language already implies an enormous relative degree of
success.

------
jhildings
Nice to see some classic maillist arguing instead of those hipster medium.com
articles or posts full of memes/gif/clipart to make a point

------
vezzy-fnord
This is pretty much the perfect moment for two egos like RMS and ESR to clash.
RMS is already getting a lot of flak for expressing his fear of GCC being
displaced in such a manner, whereas ESR is well known for his disliking RMS,
to put it mildly.

~~~
neindanke
It is not clear that RMS is driven by ego. He's motivated by a very clear goal
to keep free software free. Free as in freedom free. As for ESR, well, yup,
that's an ego that is sufficient in size to have a gravitational pull.
[http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN](http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN)

~~~
hga
I think this is an unuseful definition of ego. I had a significant degree of
contact with RMS in the period leading up to the launch of GNU, including
being one of his roommates when he formally launched it, and I assure you he's
very seriously ego driven. Are not his expounding etc. of his Free Software
philosophy, a rather big thing as in a set of principles etc., the actions of
a man very certain about himself?

I think you're just perceiving a difference in how it's expressed by each of
them, e.g. one reply is that ESR has a very clear goal of increasing the
quality of software. Which for me is the big difference between "Free" and
"Open" software.

~~~
ekianjo
> seriously ego driven

Oh, he is certainly ego-driven, but not in the same way as Jobs was, for
example. RMS does not put his person before everyone else, but he lives rather
through his principles and tries to convince everyone why it makes sense to
follow them. And he has a very solid rationale he has developed through the
years, making him very articulated.

------
danieldk
_Already my own experiments suggest that LLVM is a superior compiler, by every
metric I know of,_

I know OpenMP/Clang, but as far as I know OpenMP is not upstreamed in clang
yet, is it? If not, it's not superior yet in scientific computing :).

But it will happen soon. And at the very least, LLVM's approach has created a
large ecosystem that gcc did not have.

~~~
dekhn
OpenMP only covers a subset of scientific computing.

------
DannyBee
Eric is right, but not for the right reasons.

For starters, Apple's money is not the main driver of LLVM (In fact, publicly,
Apple is not the #1 contributor anymore).

Second, "but merely the fact that compiler technology has advanced
significantly in ways that GCC is not well positioned to exploit. " is simply
false

In fact, that's exactly the problem for GCC: Compiler technology has not
advanced _roughly at all_.

GCC caught up to everyone else for the same reason.

Time for a history lesson.

About 14 years ago,a group of folks including Diego Novillo, Jeff Law, Richard
Henderson, Andrew MacLeod, me, and Sebastian Pop (along with bug fixes/changes
from a lot of others) sat around and build a "middle end" for GCC.

Prior to that, GCC had a frontend, and a backend. The frontend was very high
level (and had no real common AST between the frontends), the backend was very
low level.

There was nothing in between.

We cherry picked the state of the art in compilers and research, and build a
production quality IR and optimizer out of it.

This research has not really changed that much in about 10-15 years. Most of
the research these days focuses not on straight compiler opts, but on things
like serious loop transforms, and helping runtimes (GPU, GC, etc), or dynamic
languages.

You can see all the tree ssa work here: [https://github.com/gcc-
mirror/gcc/blob/master/gcc/ChangeLog....](https://github.com/gcc-
mirror/gcc/blob/master/gcc/ChangeLog.tree-ssa)

This covers only until the branch was merged. At that point, it was "not a
piece of crap", but this was before people added all the stuff on top of this
architecture. On top of that architecture, it took another few years to get
good, and a few years after that to get really good.

Bringing us to today.

LLVM was started around the same time, but had less contributors back then.

Essentially, you could view it as "instead of build something in between two
really old parts, what could we do if we just redid it all". People thought it
was a waste of time for the most part, but Chris Lattner persevered, found a
bunch of crazy people to help him over the years, and here we are.

Because you see, it turns out compiler technology has not really changed at
all. So, algorithmically, LLVM and GCC _implement the same optimization
techniques_ in the middle of their compilers. Because there is nothing better
to do. Just slightly different engineering tradeoffs. To put it another way:
Outside of loop transforms, essentially static language compilers targeting
CPU architectures are solved. We know how to do everything we want to do, and
do it well. It just has to be implemented.

So given enough time/effort, LLVM and GCC will produce as good of code as each
other there. The question becomes "will they keep up with each other as
engineering/tuning happens" and "who can generate great code faster".

The problem for GCC on this front is three fold 1\. The backend, despite being
pretty heroic at this point, really needs a complete rewrite, but people value
portability over fast code.

LLVM, having started completely from scratch, has a modern, usable backend.
They are not afraid to throw stuff away.

2\. For any given thing you can implement, it's a lot easier to do it in LLVM
than GCC, so, given time, LLVM will produce faster code because it takes less
work to make it do so than it does to make GCC do so.

3\. Because it was architected differently and more modernly, clang/LLVM are
significantly faster at compiling than GCC. GCC can remove most if not all of
the middle end time (and does), but it's still slow in other places, and
that's really really hard to fix without fundamental changes (See #1)

~~~
deong
There are still plenty of open problems in compilers. For instance, writing a
program to effectively use all four of my CPU cores is pretty tedious. It
would be awfully nice if my compiler could automatically parallelize
operations, do effective register allocation across cores, distribute data for
best use of L1 cache, etc.

Certainly researchers who are working on this sort of thing today are doing it
in LLVM or some custom framework. I can't imagine GCC has any significant
traction at least.

~~~
DannyBee
The only open problem here is the one i stated "serious loop transforms".
Parallelization is not even "hard", it's just hard for languages like C++.
Fortran compilers have been parallelization for 20+years

The rest (effective cache/register/op usage) is all subsumed by cost models
for polyhedral loop transforms. See PLUTO
([http://www.ece.lsu.edu/jxr/pluto/](http://www.ece.lsu.edu/jxr/pluto/)) and
PLUTO+
([http://dl.acm.org/citation.cfm?id=2688512](http://dl.acm.org/citation.cfm?id=2688512))

------
lwh
Making your own tool suck/break/be-difficult when license-compatible patches
are submitted to improve the program seems counter productive for everyone.

------
bmuk
I tend to agree with RMS, at least on his philosophy of free software. That
being said, I don't think adding LLDB support to emacs is a bad thing, and I
don't think the rise of clang/LLVM will be a big hit to free software.

As long as there are people who care about freedom, people will maintain GCC.
Even if the worst case happens, and there is extreme fragmentation of
proprietary patch-sets to LLVM, we can always still use GCC, or even still use
the free parts of LLVM/clang.

While there is some issue with fragmentation of the developer community, I see
this as a non-issue. These things generally work themselves out through the
natural ebb and flow of chaotic systems (just like the economy is largely
self-regulating).

We can always still use GCC. I don't really see where the issue is, am I
missing something?

------
madmax96
Isn't RMS' main issue with LLVM that people can create proprietary plugins and
those plugins benefit when LLVM benefits? How exactly is this different than
if a company were to make proprietary extensions to Emacs and sell them? Does
the Emacs license forbid against non-free extensions? Ultimately, it's not
LLVM's problem if people create non-free extensions. You could argue all of
Gnu/Linux is bad because some proprietary software runs on it. I don't think
that's a route we want to take.

------
Elzair
Has anyone considered creating a new libre compiler suite in Rust? That would
be pretty cool. I have wanted to do this, but I have so many other projects to
work on.

------
_pmf_
> If the clang/LLVM people decide they want to eat GCC's lunch, they _will_ do
> it

They have about 5-10 architectures and about 40-50 architecture variants to
catch up to GCC. It's doable, but it will take about the time it took GCC to
get there, and the result will be that LLVM becomes the kind of unmaintainable
mess that GCC is considered to be now.

One would assume that the author of "The Cathedral and the Bazaar" would know
a bit or two about the lifecycle of open source software.

~~~
hga
As I understand it, the counter arguments are:

Not all of those architectures and variants are important going forward (I'd
actually be very interested in lists of them).

GCC was designed for and has been thoroughly maintained to be less
maintainable (one of the major points of these recent prominent debates).

C++ is more maintainable than C. (I don't know that I buy this at _all_ , in
fact, I'm about to dive into LLVM's source code to see if it could possibly
prompt me to revoke my oath to never program in C++ and Perl again unless
_absolutely_ necessary :-).

The last two, plus LLVM's Bazaar model of development in part enabled by those
technological differences, means it won't be an unmaintainable mess if and
when it grows out like that.

I have no idea if this will be true. I'd like to hear from seasoned developers
who are also seriously familiar with the LLVM architecture, development model
and code base (per the above, I rather hope I won't become one of the latter).

------
osw
gnu software considered harmful

------
markhahn
Reading stuff from ESR considered a waste of time.

------
ForHackernews
Anyone see the header on Stallman's response?
[https://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-02/msg00488.html)

> [[[ To any NSA and FBI agents reading my email: please consider ]]]

> [[[ whether defending the US Constitution against all enemies, ]]]

> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

He's such an adorable ideologue.

------
glass-
GCC is a technically inferior compiler that has been deliberately neutered to
enforce its license. When software has technical limitations to enforce its
license that is DRM, ergo GCC is defective by design.

