| <!-- 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>Pros of clang vs GCC:</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> | |
| makes 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. clang uses a BSD license, which | |
| allows it to be used by projects that do not themselves want to be | |
| GPL.</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>Pros of clang vs Elsa:</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>Pros of clang vs PCC:</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> |