Clang vs Other Compilers

+ +

Building an entirely new compiler front-end is a big task, and it isn't + always clear to people why we decided to do this. Here we compare clang + and its goals to other open source compiler front-ends that are + available. We restrict the discussion to very specific technical points + to avoid controversy where possible. Also, software is infinitely + mutable, so we avoid mentioning anything that would be easy to fix.

+ +

The goal of this list is to describe how differences in goals lead to + different strengths and weaknesses, not to make some compiler look bad. + This will hopefully help you to evaluate whether using clang is a good + idea for your specific goals.

+ +

Please email cfe-dev if you think we should add another compiler to this + list or if you think some characterization is unfair here.

+ + +

Clang vs GCC (GNU Compiler Collection)

+ + +

Pros of GCC vs clang:

+ +

GCC supports languages that clang does not aim to, such as Java, Ada, + FORTRAN, etc.
GCC front-ends are very mature and already support C/C++/ObjC and all + the variants we are interested in. clang's support for C++ in + particular is nowhere near what GCC supports.
GCC is popular and widely adopted.

+ +

Cons of GCC vs clang:

+ +

GCC has a very old codebase which presents a steep learning curve to new + developers. The Clang ASTs and design are intended to be easily + understandable to anyone who is familiar with the languages involved + and have a basic understanding of how a compiler works.
GCC is built as a monolithic static compiler, which makes it extremely + difficult to use as an API and integrate into other tools (e.g. an IDE). + Its historic design and current + policy was + intended to make it difficult to decouple the front-end from + the rest of the compiler. Clang is designed as an API from its + inception.
Various GCC design decisions make it very difficult to reuse: its build + system is difficult to modify, you can't link multiple targets into one + binary, you can't link multiple front-ends into one binary, it uses a + custom garbage collector, uses global variables extensively, is not + reentrant or multi-threadable, etc. Clang has none of these problems. +
GCC does not track information about macro instantiations when parsing + source code, this makes it very difficult for static analysis and + refactoring tools to work in the presense of (even simple) macros.
GCC simplifies code as it parses it. As one simple example, if you + write "x-x" in your source code, the GCC AST will contain "0", with no + mention of x. This is extremely bad for a refactoring tool that wants + to rename 'x' for example.
GCC does not have a way to serialize the AST of a file out to disk and + read it back into another program. Its PCH mechanism is architecturally + only able to read the dump back into the exact same binary.
GCC is very slow and uses a large + amount of memory.
The diagnostics produced by GCC are acceptable, but are often confusing + and it does not support expressive diagnostics.
GCC is licensed under the GPL license, which makes it difficult to use + for projects that do not themselves want to be GPL. clang uses a BSD + license.

+ + +

Clang vs Elsa (Elkhound-based C++ Parser)

+ + +

Pros of Elsa vs clang:

+ +

Elsa's support for C++ is far beyond what clang provides. If you need + C++ support in the next year, Elsa is a great way to get it. That said, + Elsa is missing important support for templates and other pieces: for + example, it is not capable of compiling the GCC STL headers from any + version newer than GCC 3.4.
Elsa's parser and AST is designed to be easily composable by adding + grammar rules. Clang has a very simple and easily extensible parser, + but requires you to write C++ code to extend it.

+ +

Cons of Elsa vs clang:

+ +

The Elsa community is extremely small and major development work seems + to have ceased in 2005, though it continues to be used by other projects + (e.g. Oink). Clang has a vibrant community including developers that + are paid to work on it full time.
Elsa is not built as a stack of reusable libraries like clang is. It is + very difficult to use part of elsa without the whole front-end. For + example, you cannot use Elsa to parse C/ObjC code without building an + AST. You can do this in Clang and it is much faster than building an + AST.
Elsa does not have an integrated preprocessor, which makes it extremely + difficult to accurately map from a source location in the AST back to + its original position before preprocessing. Likewise, it does not keep + track of macro expansions.
Elsa is slower and uses more memory than GCC, which requires far more + space and time than clang.
Elsa only does partial semantic analysis. It is intended to work on + code that is already validated by GCC, so it does not do many semantic + checks required by the languages it implements.
Elsa does not support Objective-C.
Elsa does not support native code generation.

+ + + +

Clang vs PCC (Portable C Compiler)

+ + +

Pros of PCC vs clang:

+ +

The PCC source base is very small and builds quickly with just a C + compiler.

+ +

Cons of PCC vs clang:

+ +

PCC dates from the 1970's and has been dormant for most of that time. + The clang + llvm community are very active.
PCC doesn't support Objective-C and doesn't aim to support C++.
PCC's code generation is very limited compared to LLVM, it produces very + inefficient code and does not support many important targets.
PCC's does not have an integrated preprocessor, so it is extremely + difficult to use it for source analysis tools.