www/comparison.html - platform/external/clang - Gitiles

 <!-- 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>
     <li>GCC does not require a C++ compiler to build it.</li>
     </ul>

     <p>Pros of clang vs GCC:</p>

     <ul>
     <li>The Clang ASTs and design are intended to be easily understandable to
         anyone who is familiar with the languages involved and who have a basic
         understanding of how a compiler works.  GCC has a very old codebase
         which presents a steep learning curve to new developers.</li>
     <li>Clang is designed as an API from its inception, allowing it to be reused
         by source analysis tools, refactoring, IDEs (etc) as well as for code
         generation.  GCC is built as a monolithic static compiler, which makes
         it extremely difficult to use as an API and integrate into other tools.
         Further, 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. </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'.</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 executable as the
         one that produced it.</li>
     <li>Clang is <a href="features.html#performance">much faster and uses far
         less memory</a> than GCC.</li>
     <li>Clang aims to provide extremely clear and concise diagnostics (error and
         warning messages), and includes support for <a
         href="features.html#expressivediags">expressive diagnostics</a>.  GCC's
         warnings are acceptable, but are often confusing and it does not support
         expressive diagnostics.  Clang also preserves typedefs in diagnostics
         consistently.</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>
     <li>Clang inherits a number of features from its use of LLVM as a backend,
         including support for a bytecode representation for intermediate code,
         pluggable optimizers, link-time optimization support, Just-In-Time
         compilation, etc.</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 C99, 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>
	<!-- 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>
	<li>GCC does not require a C++ compiler to build it.</li>
	</ul>

	<p>Pros of clang vs GCC:</p>

	<ul>
	<li>The Clang ASTs and design are intended to be easily understandable to
	anyone who is familiar with the languages involved and who have a basic
	understanding of how a compiler works. GCC has a very old codebase
	which presents a steep learning curve to new developers.</li>
	<li>Clang is designed as an API from its inception, allowing it to be reused
	by source analysis tools, refactoring, IDEs (etc) as well as for code
	generation. GCC is built as a monolithic static compiler, which makes
	it extremely difficult to use as an API and integrate into other tools.
	Further, 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. </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'.</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 executable as the
	one that produced it.</li>
	<li>Clang is <a href="features.html#performance">much faster and uses far
	less memory</a> than GCC.</li>
	<li>Clang aims to provide extremely clear and concise diagnostics (error and
	warning messages), and includes support for <a
	href="features.html#expressivediags">expressive diagnostics</a>. GCC's
	warnings are acceptable, but are often confusing and it does not support
	expressive diagnostics. Clang also preserves typedefs in diagnostics
	consistently.</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>
	<li>Clang inherits a number of features from its use of LLVM as a backend,
	including support for a bytecode representation for intermediate code,
	pluggable optimizers, link-time optimization support, Just-In-Time
	compilation, etc.</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 C99, 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>