It is not for nothing that I have termed this blog post comparing GCC vs Clang as the battle of behemoths. I know GCC from version dating back to year 2K and I know Clang/LLVM circa 2K+10. It is not trivial to compare them, but I will give it a try. Of course, if you are interested in me picking a favorite – I state this upfront: both are excellent software and I use them daily to get my work done.
GCC: Not a Single Compiler but a Collection!
Let us discuss GCC first. When Richard Stallman started the GNU project in 1984, the purported aim was to make a complete Unix-like operating system as free software. (Remember – this was before the advent of Linux and an operating system that can be a drop-in replacement for Unix while being free was a noble goal indeed.) C was the reigning language for developing system software then and Richard started with writing a compiler for C which he named GNU C Compiler (GCC). As of this month (April 2021), GCC is in version 10.3 and is no longer just a compiler for C. It supports:
It is available in almost all Unix-like systems and through MinGW on Windows. GCC itself is written in C with autotools, Bison, and Make as its build system. It is very well maintained with a clear vision and mission which you can take a look at here. To make sure the project maintains its free software spirit major releases are supervised by a steering committee of highly accomplished individuals from different organizations.
Clang/LLVM: Let There Be Dragons
Clang/LLVM is a compiler toolchain that supports C, C++, and Objective-C natively. This sentence does not justify the power of Clang/LLVM. To understand why I rave about this compiler toolchain, I need to describe a bit more about how the modern compiler architecture looks like:
Clang/LLVM is a textbook case of such an architecture. (No wonder, LLVM started as a research project at the University of Illinois). Here Clang is the frontend and LLVM is the backend. LLVM defines a common intermediate representation (IR) based on the single static assignment (SSA) form. This makes many optimizations to be easily performed on the IR. It is also possible to add an LLVM IR pass to add custom optimizations. All in all, this makes Clang/LLVM an excellent compiler toolchain for modern times.
GCC Vs Clang
Let us now get into the GCC Vs Clang head-to-head comparisons between these two behemoths.
- FOSS software – It is true that both GCC and Clang are free and open-source software. But their licenses differ quite a bit. GCC is licensed under GPL (GNU public license) whereas Clang/LLVM is licensed under Apache License. GCC Vs Clang comparison under the head of the license should be best left to the lawyers.
- Supported platforms – Both GCC and Clang support almost all the modern platforms. Clang/LLVM compiles natively on Windows whereas GCC needs a subsystem like MinGW to work under Windows. Clang Vs GCC comparison here wouldn’t be fair as GCC has no plans to natively support Windows.
- Code complexity – GCC is a very complicated software with more than 15 million lines of code. Although it has well-defined frontend/backend stages, the software in itself is more monolithic in nature. Let us now see how Clang Vs GCC would look. Clang is more of modular architecture with well-defined extension points.
- Standardization support – GCC has experimental support for C++20, the next version of the C++ standard. It has the full support of C++17 as well as C17, the latest C standard. Clang has the full support of the C++17 standard and is fast catching up with the C++20 standard.
- Efficient Code generation – Space and time complexity of generated code in both Clang and GCC are comparable. GCC Vs Clang comparison doesn’t make sense under this head as both optimizers are based on a tight Single Static Assignment form.
- Language Independent Type System – Clang Vs GCC makes perfect sense under this heading. Since Clang/LLVM uses a language-independent type system for all supported languages, the exact semantics of instruction can be determined. GCC does not have the design goal of a language-independent Type system.
- Parser frontend – GCC used to have Bison based LR parser. It later moved to a handwritten recursive descent parser. Clang always used a deterministic recursive descent hand-written parser with backtracking.
- Linker backend – GCC Vs Clang is the most prominent here. GCC uses ld as the linker with support for ld-gold. Clang uses lld as its linker. With some benchmarks, it is seen that lld is faster than ld and even the newer ld-gold.
- Build tool – Perhaps another place where Clang Vs GCC difference comes to the forefront. GCC uses autotools and Make as its build tools whereas Clang/LLVM uses CMake as its build tool.
- Debugger Support – GCC has an excellent GDB debugger. It is time-tested and works well. Clang has the LLDB debugger build as a set of reusable components over LLVM.
An easier comparison format is tabular as given below:
|License||GNU GPL||Apache 2.0|
|Supported platforms||*inx, Windows (MinGW)||*inx, Natively in Windows|
|Supported language standards||C++20 in experimental stage, C++17 fully complaint||C++17 support available. C++20 underway|
|Generated Code Characteristics||Efficient with a lot of compiler options to play around with||Efficient due to the SSA form used by LLVM backend|
|Language independent type system||No||Yes (One of the design goal for LLVM)|
|Build tool||Make based||CMake|
|Parser||Previously Bison LR. Now recursive descent.||Hand-written recursive descent|
This blog post should help you understand the major differences considering GCC Vs Clang. GCC is a mature compiler with support for many languages. As can be seen from the name Clang supports mostly C, C++, and Objective-C. But the framework underlying Clang called LLVM is extensible enough to support newer languages like Julia and Swift. From the perspective of C++, both are excellent compilers supporting the C++17 standard.
From Incredibuild perspective, both are great tools. That’s why we support both Clang and GCC. Incredibuild seamlessly distributes Clang and GCC compilation processes across hundreds of remote cores in the network, resulting in a drastic acceleration of compilation time for both Clang and GCC.