GCC, a 25-year old open-source compiler initiative, is facing competition from LLVM, a similar but younger initiative that is favored and pushed by Apple.
I doubt that the Gnu Compiler Collection (GCC) will go away any time soon. But it is notable that the 25-year old open-source initiative is facing some competition and rivalry – most notably from LLVM. LLVM is an open-source initiative similar to GCC but one that is favored and pushed by the significant force that is Apple.
The Free Software Foundation distributes GCC under the GNU General Public License. This is a license for royalty-free general use but requires that derived works can only be distributed under the same license terms.
GCC, which originally stood for Gnu C Compiler – because only the C software programming language was supported – has played an important role in the growth of free software and as a first port of call for those wishing to add compiler support to hardware. It therefore plays a significant role in embedded development and the world of microcontrollers.
But all things have their season and it may be that GCC's significance will now begin to reduce over time. Or it may respond to competitive pressure being brought to bear by LLVM.
One reference point I can give you is XMOS Ltd. (Bristol, England), a developer of event-driven, low latency multicore processors. XMOS has recently started to reposition the company as high-end microcontroller company. There's been no significant change in the hardware it sells as yet but the company recently reworked its entire line of development tools and moved them from GCC to LLVM.
The XMOS move reportedly produced improvements in compile time of about 40 percent, in run-time performance of about 60 percent, and reduced code size by 17 percent, over the previous GCC-based compiler.
LLVM used to stand for low-level virtual machine but now has little to do with traditional virtual machines, although it does support runtime as well as static compilation. LLVM began as a research project at the University of Illinois Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner with the goal of providing a three-phase compiler strategy capable of supporting both static and dynamic compilation of arbitrary programming languages.
As a side note, yes, LLVM is not as mature as gcc yet - it only recently supported all of C++. But it was clear that something had to be done - if not a replacement for gcc, then a complete rewrite of gcc to make it light weight again.
As touched on by other comments, the entire point of gcc is that you can fall back on it when superior industry compilers do not support your platform.
At this point, the complexity of tailoring gcc to work on a new platform has passed the knee of the exponential curve. While gcc used to be the instant "go to" for all custom targets, it is now viewed as a last resort due to implementation issues.
The primary point of LLVM was to replace gcc with something far more accessible, and something which additional can help with live syntax analysis for code editors.
The fact that its already offering better performance is just icing on the cake.
GCC is an entire ecosystem: multiple language front ends (C/C++/ObjC/Ada/Go/Java/Fortran), and multiple back ends (code generators for pretty much every architecture there is, including microcontrollers such as MSP430). It has extensive low-level facilities such as the inline asm(), so it's the only compiler that can compile the Linux kernel. That alone makes it indispensable at present, although of course could be changed some time in the future.
LLVM is a more modern design, so it incorporates optimizations that are awkward to achieve in GCC, such as global address/code/data optimizations. GCC manages to slowly track them, though, and doesn't seem to lag behind LLVM or commercial compilers in a dramatic way---compilers are a mature technology so it'd be rather hard to come up with new developments that GCC could not deal with.
I'm with DMcCunney on this one.
Beyond the licensing issue, the other big difference is that the code base is much smaller and newer. GCC with its 5MLOC can take years to learn. There are probably only 20-50 true experts worldwide, while LLVM can be picked up by any good compiler engineer in months.
At present LLVM is dominated by two targets (ARM and Intel). Other target architectures are in varying stages of maturity. Whether LLVM will remain as accessible, when, like GCC, it has 40 diverse targets to support is an interesting question.
Compilers come, and compilers go. As a company we happily support both LLVM and GCC, and wish them both well.
Ultimately the permissive BSD licensing may be LLVM's downfall. The GPL is demanding, but it does force the community to act together. When everyone is entitled to keep their improvements to themselves, it is hard to stop a project fragmenting into a collection of incompatible silos.
Being "viral" is not always a bad thing, it is interesting how the GPL can lead to software with a long, useful lifetime.
The original developers retain the rights to redistribute the original software, but the software which has been licensed to the market is guaranteed not to disappear like proprietary software has a habit of doing. What is more, the software is guaranteed to get updated or fixed for porting to new platforms.
It looks like the LLVM license would allow programs to become unavailable, since the work people do to port to new platforms is not fed back. To me this is a serious shortcoming and makes it less valuable to contribute time and effort.
Finally, we confer personhood+ rights to corporations and it is interesting to consider what kind of copyright would confer the rights of persistence to a work like a program or machine design. Copyrights have been extended beyond the life of the author*, and it would seem reasonable to protect the value for users even when the author loses interest.
50 years if the author is a person, 75 years if the author is a corporation (sigh).
LLVM has an uphill battle, and it will take more than Apple pushing it to end GCC's dominance.
GCC is the Gnu Compiler Suite, and aside from C, it compiles Ada, C++, Fortran, Java, and Go. GCC is logically separated between a front end parser and back end code generator, so you can use GCC on one platform, like Intel based Windows, to cross-compile code to run on another like an ARM Linux system.
The issue with any compiler is probably how well it optimizes for the target system. If you only develop for Windows, for example, you are probably better served to use Microsoft's compilers, or perhaps Intel's offerings, because they are tuned for those platforms.
And the commentary about GCC's license is misleading: the GPL license is "viral", and if your code links against GPLed code, it too becomes subject to the GPL. But there is nothing in GCC that prevents you from using it to build commercial closed source code.
The GPL is a license developers *choose* to apply, and there are an assortment of products issued under the GPL that offer commercial licenses as options for those who do not wish to use the GPL. If you want to get the product, use it, modify it, and redistribute it free, you are welcome to do so, but you must provide source on request and contribute patches back upstream. If you wish to do a closed source fork, you must pay the original developers for a license. The original developers retain the rights and may choose how their code is offered.
When I see someone like Red Hat decide to use LLVM instead of GCC as the compiler of choice for their Linux distro, I'll start worrying about GCC's future.
LLVM has a permissive license, which means Apple can improve LLVM by fixing bugs and adding features without having to share the results. It's the same advantage Apple gets by basing Mac OS X on Mach and BSD instead of GNU/Linux.
January 2016 Cartoon Caption ContestBob's punishment for missing his deadline was to be tied to his chair tantalizingly close to a disconnected cable, with one hand superglued to his desk and another to his chin, while the pages from his wall calendar were slowly torn away.122 comments