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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.