Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 1 | <!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
|
| 2 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
| 3 | "http://www.w3.org/TR/html4/strict.dtd">
|
| 4 | <html>
|
| 5 | <head>
|
| 6 | <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
|
| 7 | <title>Comparing clang to other compilers</title>
|
| 8 | <link type="text/css" rel="stylesheet" href="menu.css" />
|
| 9 | <link type="text/css" rel="stylesheet" href="content.css" />
|
| 10 | </head>
|
| 11 | <body>
|
| 12 | <!--#include virtual="menu.html.incl"-->
|
| 13 | <div id="content">
|
| 14 | <h1>Clang vs Other Compilers</h1>
|
| 15 |
|
| 16 | <p>Building an entirely new compiler front-end is a big task, and it isn't
|
| 17 | always clear to people why we decided to do this. Here we compare clang
|
| 18 | and its goals to other open source compiler front-ends that are
|
| 19 | available. We restrict the discussion to very specific technical points
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 20 | to avoid controversy where possible. Also, since software is infinitely
|
| 21 | mutable, so focus on architectural issues that are impractical to fix
|
| 22 | without a major rewrite, instead of talking about little details that
|
| 23 | can be fixed with a reasonable amount of effort.</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 24 |
|
| 25 | <p>The goal of this list is to describe how differences in goals lead to
|
| 26 | different strengths and weaknesses, not to make some compiler look bad.
|
| 27 | This will hopefully help you to evaluate whether using clang is a good
|
Chris Lattner | c222f93 | 2007-12-10 06:01:32 +0000 | [diff] [blame] | 28 | idea for your personal goals. Because we don't know specifically what
|
| 29 | <em>you</em> want to do, we describe the features of these compilers in
|
| 30 | terms of <em>our</em> goals: if you are only interested in static
|
| 31 | analysis, you may not care that something lacks codegen support, for
|
| 32 | example.</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 33 |
|
| 34 | <p>Please email cfe-dev if you think we should add another compiler to this
|
| 35 | list or if you think some characterization is unfair here.</p>
|
| 36 |
|
Chris Lattner | ac7e090 | 2007-12-10 05:23:01 +0000 | [diff] [blame] | 37 | <ul>
|
| 38 | <li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li>
|
| 39 | <li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li>
|
| 40 | <li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li>
|
| 41 | </ul>
|
| 42 |
|
| 43 |
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 44 | <!--=====================================================================-->
|
| 45 | <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>
|
| 46 | <!--=====================================================================-->
|
| 47 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 48 | <p>Pro's of GCC vs clang:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 49 |
|
| 50 | <ul>
|
| 51 | <li>GCC supports languages that clang does not aim to, such as Java, Ada,
|
| 52 | FORTRAN, etc.</li>
|
| 53 | <li>GCC front-ends are very mature and already support C/C++/ObjC and all
|
| 54 | the variants we are interested in. clang's support for C++ in
|
| 55 | particular is nowhere near what GCC supports.</li>
|
| 56 | <li>GCC is popular and widely adopted.</li>
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 57 | <li>GCC does not require a C++ compiler to build it.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 58 | </ul>
|
| 59 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 60 | <p>Pro's of clang vs GCC:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 61 |
|
| 62 | <ul>
|
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame^] | 63 | <li>The Clang ASTs and design are intended to be <a
|
| 64 | href="features.html#simplecode">easily understandable</a> by
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 65 | anyone who is familiar with the languages involved and who have a basic
|
| 66 | understanding of how a compiler works. GCC has a very old codebase
|
| 67 | which presents a steep learning curve to new developers.</li>
|
| 68 | <li>Clang is designed as an API from its inception, allowing it to be reused
|
| 69 | by source analysis tools, refactoring, IDEs (etc) as well as for code
|
| 70 | generation. GCC is built as a monolithic static compiler, which makes
|
| 71 | it extremely difficult to use as an API and integrate into other tools.
|
| 72 | Further, its historic design and <a
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 73 | href="http://gcc.gnu.org/ml/gcc/2007-11/msg00460.html">current</a>
|
Chris Lattner | ff11fa3 | 2007-12-10 02:05:32 +0000 | [diff] [blame] | 74 | <a href="http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html">policy</a>
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 75 | makes it difficult to decouple the front-end from the rest of the
|
| 76 | compiler. </li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 77 | <li>Various GCC design decisions make it very difficult to reuse: its build
|
| 78 | system is difficult to modify, you can't link multiple targets into one
|
| 79 | binary, you can't link multiple front-ends into one binary, it uses a
|
| 80 | custom garbage collector, uses global variables extensively, is not
|
| 81 | reentrant or multi-threadable, etc. Clang has none of these problems.
|
| 82 | </li>
|
Chris Lattner | 42f956b | 2007-12-10 02:24:44 +0000 | [diff] [blame] | 83 | <li>For every token, clang tracks information about where it was written and
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 84 | where it was ultimately expanded into if it was involved in a macro.
|
Chris Lattner | 42f956b | 2007-12-10 02:24:44 +0000 | [diff] [blame] | 85 | GCC does not track information about macro instantiations when parsing
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 86 | source code. This makes it very difficult for source rewriting tools
|
| 87 | (e.g. for refactoring) to work in the presence of (even simple)
|
| 88 | macros.</li>
|
Chris Lattner | 42f956b | 2007-12-10 02:24:44 +0000 | [diff] [blame] | 89 | <li>Clang does not implicitly simplify code as it parses it like GCC does.
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 90 | Doing so causes many problems for source analysis tools: as one simple
|
Chris Lattner | 42f956b | 2007-12-10 02:24:44 +0000 | [diff] [blame] | 91 | example, if you write "x-x" in your source code, the GCC AST will
|
| 92 | contain "0", with no mention of 'x'. This is extremely bad for a
|
| 93 | refactoring tool that wants to rename 'x'.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 94 | <li>GCC does not have a way to serialize the AST of a file out to disk and
|
| 95 | read it back into another program. Its PCH mechanism is architecturally
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 96 | only able to read the dump back into the exact same executable as the
|
| 97 | one that produced it.</li>
|
| 98 | <li>Clang is <a href="features.html#performance">much faster and uses far
|
| 99 | less memory</a> than GCC.</li>
|
| 100 | <li>Clang aims to provide extremely clear and concise diagnostics (error and
|
| 101 | warning messages), and includes support for <a
|
| 102 | href="features.html#expressivediags">expressive diagnostics</a>. GCC's
|
| 103 | warnings are acceptable, but are often confusing and it does not support
|
| 104 | expressive diagnostics. Clang also preserves typedefs in diagnostics
|
| 105 | consistently.</li>
|
Chris Lattner | ff11fa3 | 2007-12-10 02:05:32 +0000 | [diff] [blame] | 106 | <li>GCC is licensed under the GPL license. clang uses a BSD license, which
|
| 107 | allows it to be used by projects that do not themselves want to be
|
| 108 | GPL.</li>
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 109 | <li>Clang inherits a number of features from its use of LLVM as a backend,
|
| 110 | including support for a bytecode representation for intermediate code,
|
| 111 | pluggable optimizers, link-time optimization support, Just-In-Time
|
| 112 | compilation, etc.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 113 | </ul>
|
| 114 |
|
| 115 | <!--=====================================================================-->
|
| 116 | <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>
|
| 117 | <!--=====================================================================-->
|
| 118 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 119 | <p>Pro's of Elsa vs clang:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 120 |
|
| 121 | <ul>
|
| 122 | <li>Elsa's support for C++ is far beyond what clang provides. If you need
|
| 123 | C++ support in the next year, Elsa is a great way to get it. That said,
|
| 124 | Elsa is missing important support for templates and other pieces: for
|
| 125 | example, it is not capable of compiling the GCC STL headers from any
|
| 126 | version newer than GCC 3.4.</li>
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 127 | <li>Elsa's parser and AST is designed to be easily extensible by adding
|
| 128 | grammar rules. Clang has a very simple and easily hackable parser,
|
| 129 | but requires you to write C++ code to do it.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 130 | </ul>
|
| 131 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 132 | <p>Pro's of clang vs Elsa:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 133 |
|
| 134 | <ul>
|
| 135 | <li>The Elsa community is extremely small and major development work seems
|
| 136 | to have ceased in 2005, though it continues to be used by other projects
|
| 137 | (e.g. Oink). Clang has a vibrant community including developers that
|
Chris Lattner | c222f93 | 2007-12-10 06:01:32 +0000 | [diff] [blame] | 138 | are paid to work on it full time. In practice this means that you can
|
| 139 | file bugs against Clang and they will often be fixed for you. If you
|
| 140 | use Elsa, you are (mostly) on your own for bug fixes and feature
|
| 141 | enhancements.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 142 | <li>Elsa is not built as a stack of reusable libraries like clang is. It is
|
| 143 | very difficult to use part of elsa without the whole front-end. For
|
| 144 | example, you cannot use Elsa to parse C/ObjC code without building an
|
| 145 | AST. You can do this in Clang and it is much faster than building an
|
| 146 | AST.</li>
|
| 147 | <li>Elsa does not have an integrated preprocessor, which makes it extremely
|
| 148 | difficult to accurately map from a source location in the AST back to
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 149 | its original position before preprocessing. Like GCC, it does not keep
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 150 | track of macro expansions.</li>
|
| 151 | <li>Elsa is slower and uses more memory than GCC, which requires far more
|
| 152 | space and time than clang.</li>
|
| 153 | <li>Elsa only does partial semantic analysis. It is intended to work on
|
| 154 | code that is already validated by GCC, so it does not do many semantic
|
| 155 | checks required by the languages it implements.</li>
|
| 156 | <li>Elsa does not support Objective-C.</li>
|
| 157 | <li>Elsa does not support native code generation.</li>
|
| 158 | </ul>
|
| 159 |
|
| 160 |
|
| 161 | <!--=====================================================================-->
|
| 162 | <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>
|
| 163 | <!--=====================================================================-->
|
| 164 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 165 | <p>Pro's of PCC vs clang:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 166 |
|
| 167 | <ul>
|
| 168 | <li>The PCC source base is very small and builds quickly with just a C
|
| 169 | compiler.</li>
|
| 170 | </ul>
|
| 171 |
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 172 | <p>Pro's of clang vs PCC:</p>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 173 |
|
| 174 | <ul>
|
| 175 | <li>PCC dates from the 1970's and has been dormant for most of that time.
|
| 176 | The clang + llvm community are very active.</li>
|
Chris Lattner | 6c9a70d | 2007-12-10 02:18:15 +0000 | [diff] [blame] | 177 | <li>PCC doesn't support C99, Objective-C, and doesn't aim to support
|
| 178 | C++.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 179 | <li>PCC's code generation is very limited compared to LLVM, it produces very
|
| 180 | inefficient code and does not support many important targets.</li>
|
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 181 | <li>Like Elsa, PCC's does not have an integrated preprocessor, making it
|
| 182 | extremely difficult to use it for source analysis tools.</li>
|
Chris Lattner | 8310967 | 2007-12-10 01:44:24 +0000 | [diff] [blame] | 183 | </div>
|
| 184 | </body>
|
| 185 | </html>
|