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