diff options
| author | Chris Lattner <sabre@nondot.org> | 2007-12-10 01:44:24 +0000 |
|---|---|---|
| committer | Chris Lattner <sabre@nondot.org> | 2007-12-10 01:44:24 +0000 |
| commit | 8310967dd0c751b7c1b58f69dae3f66e60960054 (patch) | |
| tree | c1dd746ca75bcc60b7d318cf99958048bdd70f3e /www/comparison.html | |
| parent | d2769642086de7f44d8ac9c763c0d6a3a1ba4a8b (diff) | |
Add a "comparing clang to other compilers" page, to help resolve some FAQ's.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44754 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'www/comparison.html')
| -rw-r--r-- | www/comparison.html | 153 |
1 files changed, 153 insertions, 0 deletions
diff --git a/www/comparison.html b/www/comparison.html new file mode 100644 index 0000000000..973e9758fc --- /dev/null +++ b/www/comparison.html @@ -0,0 +1,153 @@ +<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
+ <title>Comparing clang to other 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 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 technical points
+ to avoid controversy where possible. Also, software is infinitely
+ mutable, so we avoid mentioning anything that would be easy to fix.</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 specific goals.</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>
+
+ <!--=====================================================================-->
+ <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>
+ <!--=====================================================================-->
+
+ <p>Pros 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. clang's support for C++ in
+ particular is nowhere near what GCC supports.</li>
+ <li>GCC is popular and widely adopted.</li>
+ </ul>
+
+ <p>Cons of GCC vs clang:</p>
+
+ <ul>
+ <li>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.</li>
+ <li>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 <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> 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.</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>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.</li>
+ <li>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.</li>
+ <li>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.</li>
+ <li>GCC is <a href="features.html#performance">very slow and uses a large
+ amount of memory</a>.</li>
+ <li>The diagnostics produced by GCC are acceptable, but are often confusing
+ and it does not support <a
+ href="features.html#expressivediags">expressive diagnostics</a>.</li>
+ <li>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.</li>
+ </ul>
+
+ <!--=====================================================================-->
+ <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>
+ <!--=====================================================================-->
+
+ <p>Pros 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 composable by adding
+ grammar rules. Clang has a very simple and easily extensible parser,
+ but requires you to write C++ code to extend it.</li>
+ </ul>
+
+ <p>Cons of Elsa vs clang:</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 projects
+ (e.g. Oink). Clang has a vibrant community including developers that
+ are paid to work on it full time.</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. Likewise, it does not keep
+ track of macro expansions.</li>
+ <li>Elsa is slower and uses more memory than GCC, which 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>
+
+
+ <!--=====================================================================-->
+ <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>
+ <!--=====================================================================-->
+
+ <p>Pros 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>Cons of PCC vs clang:</p>
+
+ <ul>
+ <li>PCC dates from the 1970's and has been dormant for most of that time.
+ The clang + llvm community are very active.</li>
+ <li>PCC doesn't support 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>PCC's does not have an integrated preprocessor, so it is extremely
+ difficult to use it for source analysis tools.</li>
+ </div>
+</body>
+</html>
|