diff --git a/www/comparison.html b/www/comparison.html
index e873f73..fa853fb 100644
--- a/www/comparison.html
+++ b/www/comparison.html
@@ -1,195 +1,195 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
-          "http://www.w3.org/TR/html4/strict.dtd">
-<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
-<html>
-<head>
-  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
-  <title>Comparing clang to other open source 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 Open Source 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 objective points
-       to avoid controversy where possible.  Also, software is infinitely
-       mutable, so we don't talk about little details that can be fixed with 
-       a reasonable amount of effort: we'll talk about issues that are 
-       difficult to fix for architectural or political reasons.</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 personal goals.  Because we don't know specifically what
-       <em>you</em> want to do, we describe the features of these compilers in
-       terms of <em>our</em> goals: if you are only interested in static
-       analysis, you may not care that something lacks codegen support, for
-       example.</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>
-    
-    <ul>
-    <li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li>
-    <li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li>
-    <li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li>
-    </ul>
-    
-    
-    <!--=====================================================================-->
-    <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>
-    <!--=====================================================================-->
-    
-    <p>Pro's 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.  <a href="cxx_status.html">clang's 
-        support for C++</a> in particular is nowhere near what GCC supports.</li>
-    <li>GCC supports more targets than LLVM.</li>
-    <li>GCC is popular and widely adopted.</li>
-    <li>GCC does not require a C++ compiler to build it.</li>
-    </ul>
-    
-    <p>Pro's of clang vs GCC:</p>
-    
-    <ul>
-    <li>The Clang ASTs and design are intended to be <a 
-        href="features.html#simplecode">easily understandable</a> by
-        anyone who is familiar with the languages involved and who has 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>For every token, clang tracks information about where it was written and
-        where it was ultimately expanded into if it was involved in a macro.
-        GCC does not track information about macro instantiations when parsing
-        source code.  This makes it very difficult for source rewriting tools
-        (e.g. for refactoring) to work in the presence of (even simple) 
-        macros.</li>
-    <li>Clang does not implicitly simplify code as it parses it like GCC does.
-        Doing so causes many problems for source analysis tools: 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>Clang can serialize its AST out to disk and read it back into another 
-        program, which is useful for whole program analysis.  GCC does not have
-        this.  GCC's PCH mechanism (which is just a dump of the compiler 
-        memory image) is related, but is architecturally only 
-        able to read the dump back into the exact same executable as the one 
-        that produced it (it is not a structured format).</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, ability to link in multiple code generators, etc.</li>
-    </ul>
-
-    <!--=====================================================================-->
-    <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>
-    <!--=====================================================================-->
-    
-    <p>Pro's 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 extensible by adding
-        grammar rules.  Clang has a very simple and easily hackable parser,
-        but requires you to write C++ code to do it.</li>
-    </ul>
-    
-    <p>Pro's 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 small 
-        projects
-        (e.g. Oink).  Clang has a vibrant community including developers that
-        are paid to work on it full time.  In practice this means that you can
-        file bugs against Clang and they will often be fixed for you.  If you
-        use Elsa, you are (mostly) on your own for bug fixes and feature
-        enhancements.</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.  Like GCC, it does not keep
-        track of macro expansions.</li>
-    <li>Elsa is even slower and uses more memory than GCC, which itself 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>
-    
-    <p>Note that there is a fork of Elsa known as "Pork". It addresses some of
-       these shortcomings by loosely integrating a preprocessor. This allows it
-       to map from a source location in the AST to the original position before
-       preprocessing, providing it better support for static analysis and
-       refactoring.  Note that Pork is in stasis now too.</p>
-
-    
-    <!--=====================================================================-->
-    <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>
-    <!--=====================================================================-->
-    
-    <p>Pro's 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>Pro's 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 communities 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>Like Elsa, PCC's does not have an integrated preprocessor, making it
-        extremely difficult to use it for source analysis tools.</li>
-  </div>
-</body>
-</html>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
+          "http://www.w3.org/TR/html4/strict.dtd">
+<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
+<html>
+<head>
+  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
+  <title>Comparing clang to other open source 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 Open Source 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 objective points
+       to avoid controversy where possible.  Also, software is infinitely
+       mutable, so we don't talk about little details that can be fixed with 
+       a reasonable amount of effort: we'll talk about issues that are 
+       difficult to fix for architectural or political reasons.</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 personal goals.  Because we don't know specifically what
+       <em>you</em> want to do, we describe the features of these compilers in
+       terms of <em>our</em> goals: if you are only interested in static
+       analysis, you may not care that something lacks codegen support, for
+       example.</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>
+    
+    <ul>
+    <li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li>
+    <li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li>
+    <li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li>
+    </ul>
+    
+    
+    <!--=====================================================================-->
+    <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>
+    <!--=====================================================================-->
+    
+    <p>Pro's 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.  <a href="cxx_status.html">clang's 
+        support for C++</a> in particular is nowhere near what GCC supports.</li>
+    <li>GCC supports more targets than LLVM.</li>
+    <li>GCC is popular and widely adopted.</li>
+    <li>GCC does not require a C++ compiler to build it.</li>
+    </ul>
+    
+    <p>Pro's of clang vs GCC:</p>
+    
+    <ul>
+    <li>The Clang ASTs and design are intended to be <a 
+        href="features.html#simplecode">easily understandable</a> by
+        anyone who is familiar with the languages involved and who has 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>For every token, clang tracks information about where it was written and
+        where it was ultimately expanded into if it was involved in a macro.
+        GCC does not track information about macro instantiations when parsing
+        source code.  This makes it very difficult for source rewriting tools
+        (e.g. for refactoring) to work in the presence of (even simple) 
+        macros.</li>
+    <li>Clang does not implicitly simplify code as it parses it like GCC does.
+        Doing so causes many problems for source analysis tools: 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>Clang can serialize its AST out to disk and read it back into another 
+        program, which is useful for whole program analysis.  GCC does not have
+        this.  GCC's PCH mechanism (which is just a dump of the compiler 
+        memory image) is related, but is architecturally only 
+        able to read the dump back into the exact same executable as the one 
+        that produced it (it is not a structured format).</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, ability to link in multiple code generators, etc.</li>
+    </ul>
+
+    <!--=====================================================================-->
+    <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>
+    <!--=====================================================================-->
+    
+    <p>Pro's 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 extensible by adding
+        grammar rules.  Clang has a very simple and easily hackable parser,
+        but requires you to write C++ code to do it.</li>
+    </ul>
+    
+    <p>Pro's 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 small 
+        projects
+        (e.g. Oink).  Clang has a vibrant community including developers that
+        are paid to work on it full time.  In practice this means that you can
+        file bugs against Clang and they will often be fixed for you.  If you
+        use Elsa, you are (mostly) on your own for bug fixes and feature
+        enhancements.</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.  Like GCC, it does not keep
+        track of macro expansions.</li>
+    <li>Elsa is even slower and uses more memory than GCC, which itself 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>
+    
+    <p>Note that there is a fork of Elsa known as "Pork". It addresses some of
+       these shortcomings by loosely integrating a preprocessor. This allows it
+       to map from a source location in the AST to the original position before
+       preprocessing, providing it better support for static analysis and
+       refactoring.  Note that Pork is in stasis now too.</p>
+
+    
+    <!--=====================================================================-->
+    <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>
+    <!--=====================================================================-->
+    
+    <p>Pro's 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>Pro's 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 communities 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>Like Elsa, PCC's does not have an integrated preprocessor, making it
+        extremely difficult to use it for source analysis tools.</li>
+  </div>
+</body>
+</html>