One of the major issues is that GCC started from the position of an
all-in static C compiler to which other language support has been bolted
on. In contrast LLVM is a three-phase compiler with in intermediate
representation of code. This allows different front-ends to be written
to broaden language support and different back-ends to be written to
ease porting to different hardware architectures. The back-end maps the
code into the target instruction set. This enables LLVM to support both
static and runtime compilation of a number of the newer languages
including Java, .NET, Python, Ruby, Scheme, Haskell, D and so on.
addition LLVM has also been used to create support for the OpenCL
programming language and runtime which runs on graphics processing units
(GPUs). Earlier this year Nvidia Corp announced that it had worked with
developers to enable LLVM compilation to support Cuda and other
language programming of its GPUs. This is a hot topic in computing
although not yet in microcontroller deployment.
Generally it would seem that GCC is looking a little jaded compared with LLVM.
understand that Apple, has some philosophical issues with the nature of
the General Public License, but whatever the motivation Apple has been
moving away from the use of GCC for some time.
And with the rise
and rise of Apple there is a now also business and development momentum
behind LLVM and a growing band of open-source users who will help
eradicate bugs and drive the infrastructure forward. The push for LLVM
from Apple around apps development for the iOS operating system (from
2005) has raised the significance of LLVM and Apple excluded GCC from
XCode for Mac OS X (codenamed Lion).
Given the performance
improvements reported by XMOS and the ease of support for multiple
languages it looks like LLVM is the coming thing.
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.
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.
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.
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.
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).
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.
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.