--- /dev/null
+<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->\r
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" \r
+ "http://www.w3.org/TR/html4/strict.dtd">\r
+<html>\r
+<head>\r
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />\r
+ <title>Comparing clang to other compilers</title>\r
+ <link type="text/css" rel="stylesheet" href="menu.css" />\r
+ <link type="text/css" rel="stylesheet" href="content.css" />\r
+</head>\r
+<body>\r
+ <!--#include virtual="menu.html.incl"-->\r
+ <div id="content">\r
+ <h1>Clang vs Other Compilers</h1>\r
+ \r
+ <p>Building an entirely new compiler front-end is a big task, and it isn't\r
+ always clear to people why we decided to do this. Here we compare clang\r
+ and its goals to other open source compiler front-ends that are\r
+ available. We restrict the discussion to very specific technical points\r
+ to avoid controversy where possible. Also, software is infinitely\r
+ mutable, so we avoid mentioning anything that would be easy to fix.</p>\r
+ \r
+ <p>The goal of this list is to describe how differences in goals lead to\r
+ different strengths and weaknesses, not to make some compiler look bad.\r
+ This will hopefully help you to evaluate whether using clang is a good\r
+ idea for your specific goals.</p>\r
+ \r
+ <p>Please email cfe-dev if you think we should add another compiler to this\r
+ list or if you think some characterization is unfair here.</p>\r
+ \r
+ <!--=====================================================================-->\r
+ <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>\r
+ <!--=====================================================================-->\r
+ \r
+ <p>Pros of GCC vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>GCC supports languages that clang does not aim to, such as Java, Ada,\r
+ FORTRAN, etc.</li>\r
+ <li>GCC front-ends are very mature and already support C/C++/ObjC and all\r
+ the variants we are interested in. clang's support for C++ in\r
+ particular is nowhere near what GCC supports.</li>\r
+ <li>GCC is popular and widely adopted.</li>\r
+ </ul>\r
+ \r
+ <p>Cons of GCC vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>GCC has a very old codebase which presents a steep learning curve to new\r
+ developers. The Clang ASTs and design are intended to be easily\r
+ understandable to anyone who is familiar with the languages involved\r
+ and have a basic understanding of how a compiler works.</li>\r
+ <li>GCC is built as a monolithic static compiler, which makes it extremely\r
+ difficult to use as an API and integrate into other tools (e.g. an IDE).\r
+ Its historic design and <a \r
+ href="http://gcc.gnu.org/ml/gcc/2007-11/msg00460.html">current</a>\r
+ <a href="http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html">policy</a> was\r
+ intended to make it difficult to decouple the front-end from\r
+ the rest of the compiler. Clang is designed as an API from its\r
+ inception.</li>\r
+ <li>Various GCC design decisions make it very difficult to reuse: its build\r
+ system is difficult to modify, you can't link multiple targets into one\r
+ binary, you can't link multiple front-ends into one binary, it uses a\r
+ custom garbage collector, uses global variables extensively, is not\r
+ reentrant or multi-threadable, etc. Clang has none of these problems.\r
+ </li>\r
+ <li>GCC does not track information about macro instantiations when parsing\r
+ source code, this makes it very difficult for static analysis and\r
+ refactoring tools to work in the presense of (even simple) macros.</li>\r
+ <li>GCC simplifies code as it parses it. As one simple example, if you\r
+ write "x-x" in your source code, the GCC AST will contain "0", with no\r
+ mention of x. This is extremely bad for a refactoring tool that wants\r
+ to rename 'x' for example.</li>\r
+ <li>GCC does not have a way to serialize the AST of a file out to disk and \r
+ read it back into another program. Its PCH mechanism is architecturally\r
+ only able to read the dump back into the exact same binary.</li>\r
+ <li>GCC is <a href="features.html#performance">very slow and uses a large \r
+ amount of memory</a>.</li>\r
+ <li>The diagnostics produced by GCC are acceptable, but are often confusing\r
+ and it does not support <a \r
+ href="features.html#expressivediags">expressive diagnostics</a>.</li>\r
+ <li>GCC is licensed under the GPL license, which makes it difficult to use\r
+ for projects that do not themselves want to be GPL. clang uses a BSD\r
+ license.</li>\r
+ </ul>\r
+\r
+ <!--=====================================================================-->\r
+ <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>\r
+ <!--=====================================================================-->\r
+ \r
+ <p>Pros of Elsa vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>Elsa's support for C++ is far beyond what clang provides. If you need\r
+ C++ support in the next year, Elsa is a great way to get it. That said,\r
+ Elsa is missing important support for templates and other pieces: for \r
+ example, it is not capable of compiling the GCC STL headers from any\r
+ version newer than GCC 3.4.</li>\r
+ <li>Elsa's parser and AST is designed to be easily composable by adding\r
+ grammar rules. Clang has a very simple and easily extensible parser,\r
+ but requires you to write C++ code to extend it.</li>\r
+ </ul>\r
+ \r
+ <p>Cons of Elsa vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>The Elsa community is extremely small and major development work seems\r
+ to have ceased in 2005, though it continues to be used by other projects\r
+ (e.g. Oink). Clang has a vibrant community including developers that\r
+ are paid to work on it full time.</li>\r
+ <li>Elsa is not built as a stack of reusable libraries like clang is. It is\r
+ very difficult to use part of elsa without the whole front-end. For\r
+ example, you cannot use Elsa to parse C/ObjC code without building an\r
+ AST. You can do this in Clang and it is much faster than building an\r
+ AST.</li>\r
+ <li>Elsa does not have an integrated preprocessor, which makes it extremely\r
+ difficult to accurately map from a source location in the AST back to\r
+ its original position before preprocessing. Likewise, it does not keep\r
+ track of macro expansions.</li>\r
+ <li>Elsa is slower and uses more memory than GCC, which requires far more\r
+ space and time than clang.</li>\r
+ <li>Elsa only does partial semantic analysis. It is intended to work on\r
+ code that is already validated by GCC, so it does not do many semantic\r
+ checks required by the languages it implements.</li>\r
+ <li>Elsa does not support Objective-C.</li>\r
+ <li>Elsa does not support native code generation.</li>\r
+ </ul>\r
+ \r
+ \r
+ <!--=====================================================================-->\r
+ <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>\r
+ <!--=====================================================================-->\r
+ \r
+ <p>Pros of PCC vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>The PCC source base is very small and builds quickly with just a C\r
+ compiler.</li>\r
+ </ul>\r
+ \r
+ <p>Cons of PCC vs clang:</p>\r
+ \r
+ <ul>\r
+ <li>PCC dates from the 1970's and has been dormant for most of that time.\r
+ The clang + llvm community are very active.</li>\r
+ <li>PCC doesn't support Objective-C and doesn't aim to support C++.</li>\r
+ <li>PCC's code generation is very limited compared to LLVM, it produces very\r
+ inefficient code and does not support many important targets.</li>\r
+ <li>PCC's does not have an integrated preprocessor, so it is extremely\r
+ difficult to use it for source analysis tools.</li>\r
+ </div>\r
+</body>\r
+</html>\r
projects / clang / commitdiff