<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" | |
"http://www.w3.org/TR/html4/strict.dtd"> | |
<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ --> | |
<html> | |
<head> | |
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> | |
<title>Comparing clang to other open source compilers</title> | |
<link type="text/css" rel="stylesheet" href="menu.css" /> | |
<link type="text/css" rel="stylesheet" href="content.css" /> | |
</head> | |
<body> | |
<!--#include virtual="menu.html.incl"--> | |
<div id="content"> | |
<h1>Clang vs Other Open Source Compilers</h1> | |
<p>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 objective points | |
to avoid controversy where possible. Also, software is infinitely | |
mutable, so we don't talk about little details that can be fixed with | |
a reasonable amount of effort: we'll talk about issues that are | |
difficult to fix for architectural or political reasons.</p> | |
<p>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 personal goals. Because we don't know specifically what | |
<em>you</em> want to do, we describe the features of these compilers in | |
terms of <em>our</em> goals: if you are only interested in static | |
analysis, you may not care that something lacks codegen support, for | |
example.</p> | |
<p>Please email cfe-dev if you think we should add another compiler to this | |
list or if you think some characterization is unfair here.</p> | |
<ul> | |
<li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li> | |
<li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li> | |
<li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li> | |
</ul> | |
<!--=====================================================================--> | |
<h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2> | |
<!--=====================================================================--> | |
<p>Pro's of GCC vs clang:</p> | |
<ul> | |
<li>GCC supports languages that clang does not aim to, such as Java, Ada, | |
FORTRAN, etc.</li> | |
<li>GCC front-ends are very mature and already support C/C++/ObjC and all | |
the variants we are interested in. <a href="cxx_status.html">clang's | |
support for C++</a> in particular is nowhere near what GCC supports.</li> | |
<li>GCC's codegen is much more mature than clang's right now and supports | |
more targets than LLVM.</li> | |
<li>GCC is popular and widely adopted.</li> | |
<li>GCC does not require a C++ compiler to build it.</li> | |
</ul> | |
<p>Pro's of clang vs GCC:</p> | |
<ul> | |
<li>The Clang ASTs and design are intended to be <a | |
href="features.html#simplecode">easily understandable</a> by | |
anyone who is familiar with the languages involved and who has a basic | |
understanding of how a compiler works. GCC has a very old codebase | |
which presents a steep learning curve to new developers.</li> | |
<li>Clang is designed as an API from its inception, allowing it to be reused | |
by source analysis tools, refactoring, IDEs (etc) as well as for code | |
generation. GCC is built as a monolithic static compiler, which makes | |
it extremely difficult to use as an API and integrate into other tools. | |
Further, its historic design and <a | |
href="http://gcc.gnu.org/ml/gcc/2007-11/msg00460.html">current</a> | |
<a href="http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html">policy</a> | |
makes it difficult to decouple the front-end from the rest of the | |
compiler. </li> | |
<li>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. | |
</li> | |
<li>For every token, clang tracks information about where it was written and | |
where it was ultimately expanded into if it was involved in a macro. | |
GCC does not track information about macro instantiations when parsing | |
source code. This makes it very difficult for source rewriting tools | |
(e.g. for refactoring) to work in the presence of (even simple) | |
macros.</li> | |
<li>Clang does not implicitly simplify code as it parses it like GCC does. | |
Doing so causes many problems for source analysis tools: 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'.</li> | |
<li>Clang can serialize its AST out to disk and read it back into another | |
program, which is useful for whole program analysis. GCC does not have | |
this. GCC's PCH mechanism (which is just a dump of the compiler | |
memory image) is related, but is architecturally only | |
able to read the dump back into the exact same executable as the one | |
that produced it (it is not a structured format).</li> | |
<li>Clang is <a href="features.html#performance">much faster and uses far | |
less memory</a> than GCC.</li> | |
<li>Clang aims to provide extremely clear and concise diagnostics (error and | |
warning messages), and includes support for <a | |
href="features.html#expressivediags">expressive diagnostics</a>. GCC's | |
warnings are acceptable, but are often confusing and it does not support | |
expressive diagnostics. Clang also preserves typedefs in diagnostics | |
consistently.</li> | |
<li>GCC is licensed under the GPL license. clang uses a BSD license, which | |
allows it to be used by projects that do not themselves want to be | |
GPL.</li> | |
<li>Clang inherits a number of features from its use of LLVM as a backend, | |
including support for a bytecode representation for intermediate code, | |
pluggable optimizers, link-time optimization support, Just-In-Time | |
compilation, ability to link in multiple code generators, etc.</li> | |
</ul> | |
<!--=====================================================================--> | |
<h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2> | |
<!--=====================================================================--> | |
<p>Pro's of Elsa vs clang:</p> | |
<ul> | |
<li>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.</li> | |
<li>Elsa's parser and AST is designed to be easily extensible by adding | |
grammar rules. Clang has a very simple and easily hackable parser, | |
but requires you to write C++ code to do it.</li> | |
</ul> | |
<p>Pro's of clang vs Elsa:</p> | |
<ul> | |
<li>The Elsa community is extremely small and major development work seems | |
to have ceased in 2005, though it continues to be used by other small | |
projects | |
(e.g. Oink). Clang has a vibrant community including developers that | |
are paid to work on it full time. In practice this means that you can | |
file bugs against Clang and they will often be fixed for you. If you | |
use Elsa, you are (mostly) on your own for bug fixes and feature | |
enhancements.</li> | |
<li>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.</li> | |
<li>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. Like GCC, it does not keep | |
track of macro expansions.</li> | |
<li>Elsa is even slower and uses more memory than GCC, which itself requires | |
far more space and time than clang.</li> | |
<li>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.</li> | |
<li>Elsa does not support Objective-C.</li> | |
<li>Elsa does not support native code generation.</li> | |
</ul> | |
<p>Note that there is a fork of Elsa known as "Pork". It addresses some of | |
these shortcomings by loosely integrating a preprocessor. This allows it | |
to map from a source location in the AST to the original position before | |
preprocessing, providing it better support for static analysis and | |
refactoring. Note that Pork is in stasis now too.</p> | |
<!--=====================================================================--> | |
<h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2> | |
<!--=====================================================================--> | |
<p>Pro's of PCC vs clang:</p> | |
<ul> | |
<li>The PCC source base is very small and builds quickly with just a C | |
compiler.</li> | |
</ul> | |
<p>Pro's of clang vs PCC:</p> | |
<ul> | |
<li>PCC dates from the 1970's and has been dormant for most of that time. | |
The clang + llvm communities are very active.</li> | |
<li>PCC doesn't support C99, Objective-C, and doesn't aim to support | |
C++.</li> | |
<li>PCC's code generation is very limited compared to LLVM. It produces very | |
inefficient code and does not support many important targets.</li> | |
<li>Like Elsa, PCC's does not have an integrated preprocessor, making it | |
extremely difficult to use it for source analysis tools.</li> | |
</div> | |
</body> | |
</html> |