

Talk Of GCC 5.0 To Be Modular, More Like LLVM - al3xbio
http://www.phoronix.com/scan.php?page=news_item&px=MTA3MzE

======
haberman
GCC has resisted modularity for a while because of concerns about enabling
proprietary plugins; an unfortunate case of letting ideology come before
technical excellence. This left a big unmet need and put LLVM in a stronger
position to displace GCC purely on technical merit, by offering this
capability that GCC didn't want to offer.

<http://lwn.net/Articles/301135/>

~~~
ChuckMcM
Reading that article from lwn.net is amazing. The irony of the gcc community
users screwing over their customers in order to preserve their ideology, and
its parallel in the 'commercial' software business is really amazing.
Seriously. "We won't make plug-ins because that would open the door to making
money on GCC" vs "We require a key disk to prevent folks from copying our
software and using it for free."

~~~
gillianseed
'Screwing over their customers'? Who are these 'customers'? If you are talking
about end users then I fail to see how they are to be served by enhancements
being kept in proprietary plugins (which are the historical reasons behind the
objection against plugins, which in turn can be illustrated by the attempts of
Steve Jobs who while at NeXT tried to circumvent the GPL to have it as a
backend for his proprietary ObjC frontend).

The whole point of GCC is to have a complete compiler toolchain where all the
enhancements are being made available to _all_ end users. Catering for
companies who wants a free strong frontend/backend on which to develop their
proprietary extensions is obviously NOT what FSF is interested in and I
personally agree with their 'ideology' in this case as the last thing I want
to see is a situation where developers keep their enhancements proprietary
(likely due to the wishes of their companies who see no gain in releasing
those enhancements and instead wants to keep those enhancements as a
competitive edge).

Also I like how GCC enforces patent protection grants to be given by code
contributors, something which LLVM does not and I fear is something which
could open a big can of worms later down the road.

Off course, scoffing at the 'ideology' which lead to the creation of the
toolchain that is fueling pretty much the entire open source ecosystem not to
mention lots of proprietary projects aswell makes you look pretty stupid in my
book. Also GPL is obviously a licence through which numerous companies find it
agreeable to cooperatively develop code, hence the success of Linux and GCC.

~~~
ChuckMcM
Ok, so the point is subtle and perhaps not easily communicated. This example
is good though.

 _"The whole point of GCC is to have a complete compiler toolchain where all
the enhancements are being made available to _all_ end users." ... "the last
thing I want to see is a situation where developers keep their enhancements
proprietary."_

I believe you have correctly expressed a consensus opinion of why it would be
'bad' to allow proprietary plugins. And your claim posits a reason:

 _"(likely due to the wishes of their companies who see no gain in releasing
those enhancements and instead wants to keep those enhancements as a
competitive edge)."_

Which is also a common reason given.

However what if there was a different reason? What if there is some capability
that could be created with a plug-in that is pretty specialized, further that
plug-in would require specialized domain knowledge and would only be of use to
a small number of GCC users.

Traditionally the way the market has created such things is that a person
invests their time to create the capability, and they charge a fraction of
what it cost them to others to use the capability. The compute the fraction to
offset the cost of developing it, and the community benefits by getting access
to this capability for a fraction of what it would cost to develop in house,
and the developer benefits by having the cost of their efforts covered by the
community.

In a GPL world where the work would be considered derivative, you remove the
opportunity for people to charge for their work, and thus you remove the
economic motivation for getting something built. This damages the community as
a whole with a somewhat 'invisible' "didn't go there" sort of damage (you only
miss something if you had it and then you don't, not if you never had it). It
is an unfortunate byproduct of GPL like licenses that they poison[1] the
market for those specialized tools.

I completely understand the motivation behind the FSF and GCC communities for
wanting to keep GCC available for all.

But you have to also note that people who sell software make very much the
same arguments in defense of copy protection. They (the software producers)
argue that they want everyone to have the same experience and they can't
control that experience if people are out there making bootleg copies and
changes they don't know about. So they deny something their customers want
"software unburdened by loathsome copy protection" to preserve their stated
goal of giving everyone the same experience with their software.

So if the FSF and GCC communities are denying something their customers want
"modularized GCC tools for easy customization through plug-ins" in order to
preserve their stated goal of giving everyone the same experience with their
software, well it strikes me as ironic.

[1] Sorry for inflammatory way that sounds, my thesaurus is coming up blank on
terms that mean 'something which kills an existing organism and keeps it
dead'. Using 'nuke' seemed worse.

~~~
Jach
You're wrong that the GPL prohibits one from selling software as software. It
doesn't. It does make it harder, because anyone can come in and buy one copy
to distribute to everyone else, but this happens very often in the non-open-
source world too. Maybe you've heard of pirates?

The only difference is legal ability to sue, but then again when your unwanted
re-distributors/pirates are the masses whose real-world identities are hard to
discover, this difference doesn't mean that much. You can also gain some
(though not all) of the same legal rights to sue unwanted re-distributors by
trademarking your application, which forces any re-distributors to have to
redistribute under a different name (CentOS instead of RedHat) which puts them
at a marketing disadvantage.

Is your example of developing a niche feature for a niche domain really the
traditional way? I guess so, but since the GPL has been around there have been
numerous examples of what-would-have-been-proprietary features still being
developed, released, and open sourced. e.g. if you own all the copyright to a
GPL program, some niche domain representative can come along and you can sell
them a non-GPL license to develop their addon for which they can then resell.
As another e.g., look at all the companies who have contributed to the Linux
Kernel. The company wants a particular feature because they can use it to make
money for some other reason, so they pay developers to write the code which
then gets GPL'd. The company still makes money from the code, the developers
make money by writing the code, and the users directly, obviously benefit from
the code being there as opposed to the company having estimated indirect
guesses at how much value they could capture by selling the code for what the
market could bear.

Edit: I do agree with you about the irony, though.

------
eklitzke
I'm really happy to see this sort of discussion happening within the GCC
project. While LLVM/Clang are nicer and more usable than GCC in a lot of ways,
in my experience GCC is still much more mature, generates better code, and has
been implementing features new features from C++11 more quickly. I also like
that GCC, glibc, and the GNU libstdc++ are all developed together so that as
the compiler implements new optimizations and language features, the runtime
environment also takes advantages of those features. I've been impressed with
the last few GCC releases (I'm already using 4.7 for my own work).

Competition is good, and it's great to see that GCC development is going
strong.

------
loeg
If you don't want to give ad money to the disgusting pile of slop that is
phoronix, here are the relevant upstream mailing list links:

"GCC 5?" <http://gcc.gnu.org/ml/gcc/2012-03/msg00256.html> "GCC 5 &
modularity": <http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html>

~~~
moonchrome
OT but what's your beef with phoronix ? I'm not a regular reader but it seems
a nice site about opensource stuff.

~~~
wmf
(Different poster here.) I like to call it "Moronix" because their analysis is
so shallow, but OTOH they cover topics that _no other site_ cares about, so
it's probably a net win as long as you read with a critical eye.

~~~
JDShu
I have always wondered why there has never been a competitor site to Phoronix.
My guess is that very few people with the interest and ability to understand
things like mesa and llvm are motivated to make a website about it.

~~~
ruediger
What about lwn.net?

------
wmf
Or they could rename LLVM to GCC 5.0; that strategy worked for EGCS. :-)

------
kingkilr
Small world, Dave and I just ran into issues related to this a week ago (I
suppose it may have motivated his email). Namely that there was no single API
to get the assembler generated for an RTL (register-transfer-language, GCC's
final IR) node without going through some destructive APIs.

------
mdiep
Is there a reason I should care about GCC anymore? Admittedly, I mostly code
ObjC on OS X, where GCC is no longer relevant, but LLVM seems to have
leapfrogged GCC so dramatically that I'm unsure why I would even care about
GCC.

LLVM integrates better with tools, has an amazing static analyzer, and AFAIK
generates code that is on average as fast and small as GCC. (I believe who
wins depends on the code.)

~~~
gillianseed
I'd say that in 9 out of 10 GCC creates faster code than LLVM/Clang (I see
typically 5-10% difference in performance oriented code), add to this that
LLVM/Clang lacks strong special optimization strategies like PGO (profile
guided optimization) then it's a clear win for GCC. GCC also supports more
languages and architectures than Clang which simply mirrors the needs of Apple
(ObjC, C, C++). If you are on OSX then yes, there's likely little reason for
you to use GCC since OSX ships with a (5 year?) old GCC version and also
obviously because Clang/LLVM integrates much better with Apple's proprietary
XCode.

That said I use both, and at work we test our code against both toolchains
(and some other compilers aswell). The static analyser in Clang is a welcome
addition and the error diagnostics/reporting is top notch so it certainly has
strong features even though it falls behind GCC in code optimization.

~~~
pohl
PGO will probably come to LLVM soon, for what it's worth. They added branch
probability and basic block frequency support in 3.0 with an eye towards it,
anyway.

~~~
gillianseed
Great, yes there's been propositions made towards it for quite some time but
no actual code so I was almost thinking it wouldn't happen, here's hoping it
will happen now. Every other major compiler I can think of has it, GCC, ICC,
Open64, MSVC, and the optimization often has a great impact on performance
dependant code.

------
stock_toaster
Competition is a great thing. :)

------
sanxiyn
While reading this it is useful to know that David Malcolm is the author of
GCC Python Plugin so he has seen the potential of modular, pluggable GCC.

<https://fedorahosted.org/gcc-python-plugin/>

------
mmisu
I think I prefer to see a faster and complete standard implementation for
C++11 and C11 than to see a modular GCC.

Making the project more modular, while not a bad idea in itself, could
potentially delay the implementation of the latest standards.

------
forgottenpaswrd
Why?

We already have llvm as a c++ monster(hundreds or thousands of MBytes on my
mac), witch is modular, and have a more permissive license.

So you are going to risk the only advantages of gcc,(written in c and
relatively small and stability), so you could copy the new kid on the block?

If you are going to copy them, copy the more permissive license. It will give
commercial companies like Apple the option to improve your software like they
do with llvm(Apple hired llvm creator).

~~~
berkut
I think you might want to check your facts:

LLVM + Clang source code: 9.9MB + 6MB = C, C++ and Obj-C compiler and linker

GCC source = 69MB = just C compiler and linker

G++ source = 6.6MB = C++ additions to GCC

So I'm curious as to where you're getting the "hundreds or thousands of MBytes
on my mac" from.

~~~
m3koval
On OS X, you get clang and llvm-gcc in XCode 4.1, which is a solid 1.4 GB
download. You're absolutely right about clang being pretty lightweight, so
it's getting a bad wrap by association. I'm honestly not sure why XCode is so
large: perhaps the IDE and iOS simulator?

~~~
derleth
> a bad wrap

This is perfect; the actual idiom is 'bad rap' but this actually makes more
sense in context. ;)

