granicus.if.org Git - clang/blob - www/comparison.html

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