Revert a bad edit from r52095.
[oota-llvm.git] / docs / ReleaseNotes.html
index bc711bedf87c0b02f3ce6872a9ccd1e4bed540e2..1e05ac7bea75196ab82018679991c59aef958af4 100644 (file)
@@ -1,17 +1,19 @@
+
 <!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=utf-8">
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 1.8 Release Notes</title>
+  <title>LLVM 2.3 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 1.8 Release Notes</div>
+<div class="doc_title">LLVM 2.3 Release Notes</div>
  
 <ol>
   <li><a href="#intro">Introduction</a></li>
+  <li><a href="#changes">Major Changes and Sub-project Status</a></li>
   <li><a href="#whatsnew">What's New?</a></li>
   <li><a href="GettingStarted.html">Installation Instructions</a></li>
   <li><a href="#portability">Portability and Supported Platforms</a></li>
@@ -23,6 +25,8 @@
   <p>Written by the <a href="http://llvm.org">LLVM Team</a><p>
 </div>
 
+<!-- Done through Week-of-Mon-20080324.txt -->
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="intro">Introduction</a>
 <div class="doc_text">
 
 <p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.8.  Here we describe the status of LLVM, including any
-known problems and major improvements from the previous release.  The most
-up-to-date version of this document (corresponding to LLVM CVS) can be found
-on the <a
-href="http://llvm.org/releases/">LLVM releases web site</a>.  If you are
-not reading this on the LLVM web pages, you should probably go there because
-this document may be updated after the release.</p>
+infrastructure, release 2.3.  Here we describe the status of LLVM, including
+major improvements from the previous release and any known problems.  All LLVM
+releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM
+releases web site</a>.</p>
 
 <p>For more information about LLVM, including information about the latest
 release, please check out the <a href="http://llvm.org/">main LLVM
@@ -46,532 +47,582 @@ web site</a>.  If you have questions or comments, the <a
 href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
 list</a> is a good place to send them.</p>
 
-<p>Note that if you are reading this file from CVS or the main LLVM web page,
-this document applies to the <i>next</i> release, not the current one.  To see
-the release notes for the current or previous releases, see the <a
-href="http://llvm.org/releases/">releases page</a>.</p>
+<p>Note that if you are reading this file from a Subversion checkout or the 
+main LLVM web page, this document applies to the <i>next</i> release, not the
+current one.  To see the release notes for a specific releases, please see the
+<a href="http://llvm.org/releases/">releases page</a>.</p>
 
 </div>
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
-  <a name="whatsnew">What's New?</a>
+  <a name="changes">Major Changes and Sub-project Status</a>
 </div>
 <!-- *********************************************************************** -->
 
 <div class="doc_text">
 
-<p>This is the nineth public release of the LLVM Compiler Infrastructure. This
-release incorporates a large number of enhancements and new features,
-including DWARF debugging support (C and C++ on Darwin/PPC), improved inline
-assembly support, a new <a href="http://llvm.org/nightlytest/">nightly 
-tester</a>, llvm-config enhancements, many bugs
-fixed, and performance and compile time improvements.
-</p>
+<p>This is the fourteenth public release of the LLVM Compiler Infrastructure. 
+It includes a large number of features and refinements from LLVM 2.2.</p>
 
 </div>
 
+<!-- Unfinished features in 2.3:
+  Machine LICM
+  Machine Sinking
+  LegalizeDAGTypes
+ -->
+
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="newfeatures">New Features in LLVM 1.8</a>
+<a name="changes">Major Changes in LLVM 2.3</a>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="dwarf">DWARF debugging 
-support </a></div>
-
 <div class="doc_text">
 
-<p>The llvm-gcc4 C front-end now generates debugging info for C and C++.  This
-information is propagated through the compiler and the code generator can
-currently produce DWARF debugging information from it.  DWARF is a standard
-debugging format used on many platforms, but currently LLVM only includes 
-target support for Mac OS X targets for the 1.8 release.
-</p>
+<p>LLVM 2.3 no longer supports llvm-gcc 4.0, it has been replaced with
+   llvm-gcc 4.2.</p>
 
-</div>
+<p>LLVM 2.3 no longer includes the <tt>llvm-upgrade</tt> tool.  It was useful
+   for upgrading LLVM 1.9 files to LLVM 2.x syntax, but you can always use a
+   previous LLVM release to do this.  One nice impact of this is that the LLVM
+   regression test suite no longer depends on llvm-upgrade, which makes it run
+   faster.</p>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="inlineasm">Inline Assembly
-Support</a></div>
+<p>The <tt>llvm2cpp</tt> tool has been folded into llc, use
+    <tt>llc -march=cpp</tt> instead of <tt>llvm2cpp</tt>.</p>
 
-<div class="doc_text">
+<p>LLVM API Changes:</p>
 
-<p>Inline assembly support is substantially improved in LLVM 1.8 over LLVM 1.7.
-Many unsupported features are now supported, and inline asm support in the X86
-backend is far better.  llvm-gcc4 now supports global register variables as 
-well.</p>
+<ul>
+<li>Several core LLVM IR classes have migrated to use the
+    '<tt>FOOCLASS::Create(...)</tt>' pattern instead of '<tt>new 
+    FOOCLASS(...)</tt>' (e.g. where FOOCLASS=<tt>BasicBlock</tt>).  We hope to
+    standardize on <tt>FOOCLASS::Create</tt> for all IR classes in the future,
+    but not all of them have been moved over yet.</li>
+<li>LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to
+   IRBuilder.</li>
+<li>MRegisterInfo was renamed to TargetRegisterInfo.</li>
+<li>The MappedFile class is gone, please use MemoryBuffer instead.</li>
+<li>The '<tt>-enable-eh</tt>' flag to llc has been removed.  Now code should 
+    encode whether it is safe to omit unwind information for a function by
+    tagging the Function object with the '<tt>nounwind</tt>' attribute.</li>
 
+</ul>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="loopopt">Loop Optimizer Improvements</a></div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="otherprojects">Other LLVM Sub-Projects</a>
+</div>
 
 <div class="doc_text">
-
-<p>The loop optimizer passes now uses "Loop-Closed SSA Form", which makes it
-easier to update SSA form as loop transformations change the code.  An 
-immediate benefit of this is that the loop unswitching pass can now unswitch
-loops in more cases.
+<p>
+The core LLVM 2.3 distribution currently consists of code from the core LLVM
+repository (which roughly contains the LLVM optimizer, code generators and
+supporting tools) and the llvm-gcc repository.  In addition to this code, the
+LLVM Project includes other sub-projects that are in development.  The two which
+are the most actively developed are the new <a href="#vmkit">vmkit Project</a>
+and the <a href="#clang">Clang Project</a>. 
 </p>
-
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="jumptab">Jump Table Support for Switches
-</a></div>
-
-<div class="doc_text">
-
-<p>The code generator now lowers switch statements to jump tables, providing
-significant performance boosts for applications (e.g. interpreters) whose
-performance is highly correlated to switch statement performance.</p>
-
+<!--=========================================================================-->
+<div class="doc_subsubsection">
+<a name="vmkit">vmkit</a>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="jitrelease">Deallocation of JIT'd 
-Machine Code
-</a></div>
-
 <div class="doc_text">
+<p>
+The "vmkit" project is a new addition to the LLVM family.  It is an
+implementation of a JVM and a CLI Virtual Machines (Microsoft .NET is an
+implementation of the CLI) using the Just-In-Time compiler of LLVM.</p>
+
+<p>The JVM, called JnJVM, executes real-world applications such as Apache
+projects (e.g. Felix and Tomcat) and the SpecJVM98 benchmark.  It uses the GNU
+Classpath project for the base classes.  The CLI implementation, called N3, is
+its in early stages but can execute simple applications and the "pnetmark"
+benchmark. It uses the pnetlib project as its core library.</p>
+
+<p>The 'vmkit' VMs compare in performance with industrial and top open-source
+VMs on scientific applications.  Besides the JIT, the VMs use many features of
+the LLVM framework, including the standard set of optimizations, atomic
+operations, custom function provider and memory manager for JITed methods, and
+specific virtual machine optimizations. vmkit is not an official part of LLVM
+2.3 release. It is publicly available under the LLVM license and can be
+downloaded from:
+</p>
 
-<p>The LLVM JIT now allows clients to deallocate machine code JIT'd to its code
-buffer.  This is important for long living applications that depend on the JIT.
+<p>
+<tt>svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit</tt>
 </p>
 
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="other">Other Improvements</a></div>
+<!--=========================================================================-->
+<div class="doc_subsubsection">
+<a name="clang">Clang</a>
+</div>
 
 <div class="doc_text">
 
-<p>This release includes many other improvements, including improvements to
-   the optimizers and code generators (improving the generated code) changes to
-   speed up the compiler in many ways (improving algorithms and fine tuning 
-   code), and changes to reduce the code size of the compiler itself.</p>
+<p>The <a href="http://clang.llvm.org/">Clang project</a> is an effort to build
+a set of new 'LLVM native' front-end technologies for the LLVM optimizer
+and code generator.  Clang is continuing to make major strides forward in all
+areas.  Its C and Objective-C parsing support is very solid, and the code
+generation support is far enough along to build many C applications.  While not
+yet production quality, it is progressing very nicely.  In addition, C++
+front-end work has started to make significant progress.</p>
 
-<p>More specific changes include:</p>
+<p>At this point, Clang is most useful if you are interested in source-to-source
+transformations (such as refactoring) and other source-level tools for C and
+Objective-C.  Clang now also includes tools for turning C code into pretty HTML,
+and includes a new <a href="http://clang.llvm.org/StaticAnalysis.html">static
+analysis tool</a> in development.  This tool is automatically focused on finding
+bugs in C and Objective-C code.</p>
 
-<ul>
-<li>LLVM 1.8 includes an initial ARM backend.  This backend is in early 
-    development stages.</li>
-<li>LLVM 1.8 now includes significantly better support for mingw and 
-    cygwin.</li>
-<li>The <a href="CommandGuide/html/llvm-config.html">llvm-config</a> tool is 
-    now built by default and has several new features.</li>
-<li>The X86 and PPC backends now use the correct platform ABI for passing 
-    vectors as arguments to functions.</li>
-<li>The X86 backend now includes support for the Microsoft ML assembler 
-    ("MASM").</li>
-<li>The PowerPC backend now pattern matches the 'rlwimi' instruction more 
-    aggressively.</li>
-<li>Most of LLVM is now built with "-pedantic", ensuring better portability 
-    to more C++ Compilers.</li>
-<li>The PowerPC backend now includes initial 64-bit support.  The JIT is not
-    complete, and the static compiler has a couple of known bugs, but support
-    is mostly in place. LLVM 1.9 will include completed PPC-64 support. </li>
+</div>
 
-</ul>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="whatsnew">What's New?</a>
 </div>
+<!-- *********************************************************************** -->
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="changes">Significant Changes in LLVM 1.8</a>
+<a name="majorfeatures">Major New Features</a>
 </div>
 
 <div class="doc_text">
+
+<p>LLVM 2.3 includes several major new capabilities:</p>
+
 <ul>
-<li>The LLVM "SparcV9" backend (deprecated in LLVM 1.7) has been removed in 
-LLVM 1.8.  The LLVM "Sparc" backend replaces it.</li>
-<li>The --version option now prints more useful information, including the
-    build configuration for the tool.</li>
+<li><p>The biggest change in LLVM 2.3 is Multiple Return Value (MRV) support.
+    MRVs allow LLVM IR to directly represent functions that return multiple
+    values without having to pass them "by reference" in the LLVM IR.  This
+    allows a front-end to generate more efficient code, as MRVs are generally
+    returned in registers if a target supports them.  See the <a
+    href="LangRef.html#i_getresult">LLVM IR Reference</a> for more details.</p>
+    
+ <p>MRVs are fully supported in the LLVM IR, but are not yet fully supported in
+    on all targets.  However, it is generally safe to return up to 2 values from
+    a function: most targets should be able to handle at least that.  MRV
+    support is a critical requirement for X86-64 ABI support, as X86-64 requires
+    the ability to return multiple registers from functions, and we use MRVs to
+    accomplish this in a direct way.</p></li>
+
+<li><p>LLVM 2.3 includes a complete reimplementation of the "<tt>llvmc</tt>"
+    tool.  It is designed to overcome several problems with the original 
+    <tt>llvmc</tt> and to provide a superset of the features of the
+    '<tt>gcc</tt>' driver.</p>
+
+<p>The main features of <tt>llvmc2</tt> are:
+    <ul>
+    <li>Extended handling of command line options and smart rules for
+    dispatching them to different tools.</li>
+    <li>Flexible (and extensible) rules for defining different tools.</li>
+    <li>The different intermediate steps performed by tools are represented
+    as edges in the abstract graph.</li>
+    <li>The 'language' for driver behavior definition is tablegen and thus
+    it's relatively easy to add new features.</li>
+    <li>The definition of driver is transformed into set of C++ classes, thus
+    no runtime interpretation is needed.</li>
+    </ul></p>
+    </li>
+
+<li><p>LLVM 2.3 includes a completely rewritten interface for <a
+    href="LinkTimeOptimization.html">Link Time Optimization</a>.  This interface
+    is written in C, which allows for easier integration with C code bases, and
+    incorporates improvements we learned about from the first incarnation of the
+    interface.</p></li>
+
+<li><p>The <a href="tutorial/LangImpl1.html">Kaleidoscope tutorial</a> now
+    includes a "port" of the tutorial that <a 
+    href="tutorial/OCamlLangImpl1.html">uses the Ocaml bindings</a> to implement
+    the Kaleidoscope language.</p></li>
+
 </ul>
+
 </div>
 
 
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="portability">Portability and Supported Platforms</a>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="llvm-gcc">llvm-gcc 4.2 Improvements</a>
 </div>
-<!-- *********************************************************************** -->
 
 <div class="doc_text">
 
-<p>LLVM is known to work on the following platforms:</p>
+<p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end.</p>
 
-<ul>
-  <li>Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD 
-      (and probably other unix-like systems).</li>
-<li>Sun UltraSPARC workstations running Solaris 8.</li>
-<li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
-    support is available for native builds with Visual C++).</li>
-<li>PowerPC and X86-based Mac OS X systems, running 10.2 and above.</li>
-<li>Alpha-based machines running Debian GNU/Linux.</li>
-<li>Itanium-based machines running Linux and HP-UX.</li>
-</ul>
+<p>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
+front-end.  Objective-C now works very well on Mac OS/X.</p>
 
-<p>The core LLVM infrastructure uses
-<a href="http://www.gnu.org/software/autoconf/">GNU autoconf</a> to adapt itself
-to the machine and operating system on which it is built.  However, minor
-porting may be required to get LLVM to work on new platforms.  We welcome your
-portability patches and reports of successful builds or error messages.</p>
+<p>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</p>
+
+<p>llvm-gcc 4.2 includes many other fixes which improve conformance with the
+relevant parts of the GCC testsuite.</p>
 
 </div>
 
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="knownproblems">Known Problems</a>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="coreimprovements">LLVM Core Improvements</a>
 </div>
-<!-- *********************************************************************** -->
 
 <div class="doc_text">
+<p>New features include:
+</p>
 
-<p>This section contains all known problems with the LLVM system, listed by
-component.  As new problems are discovered, they will be added to these
-sections.  If you run into a problem, please check the <a
-href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
-there isn't already one.</p>
 
+Common linkage?
+
+Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize", 
+"__sync_val_compare_and_swap", etc
+
+<ul>
+<li>The C and Ocaml bindings have received additional improvements. The
+bindings now cover pass managers, several transformation passes, iteration
+over the LLVM IR, target data, and parameter attribute lists.</li>
+</ul>
+  
 </div>
 
-<!-- ======================================================================= -->
+<!--=========================================================================-->
 <div class="doc_subsection">
-  <a name="experimental">Experimental features included with this release</a>
+<a name="optimizer">Optimizer Improvements</a>
 </div>
 
 <div class="doc_text">
 
-<p>The following components of this LLVM release are either untested, known to
-be broken or unreliable, or are in early development.  These components should
-not be relied on, and bugs should not be filed against them, but they may be
-useful to some people.  In particular, if you would like to work on one of these
-components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
+<p>In addition to a huge array of bug fixes and minor performance tweaks, the 
+LLVM 2.3 optimizers support a few major enhancements:</p>
 
 <ul>
-<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in in a 
-    future release.</li>
-<li>The IA64 code generator is experimental.</li>
-<li>The Alpha JIT is experimental.</li>
-<li>"<tt>-filetype=asm</tt>" (the default) is the only supported value for the 
-    <tt>-filetype</tt> llc option.</li>
+
+<li>Loop index set splitting on by default.<p>
+This transformation hoists conditions from loop bodies and reduces loop's
+iteration space to improve performance. For example, <p>
+<pre>
+for (i = LB; i &lt; UB; ++i)
+  if (i &lt;= NV)
+    LOOP_BODY
+</pre>
+is transformed into
+<pre>
+NUB = min(NV+1, UB)
+for (i = LB; i &lt; NUB; ++i)
+  LOOP_BODY
+</pre>
+</li>
+
+<li>LLVM includes a new <tt>memcpy</tt> optimization pass which removes
+dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and performs
+return slot optimization.  The LLVM optimizer now notices long sequences of
+consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
+
+<li>Alignment detection for vector memory references and for <tt>memcpy</tt> and
+<tt>memset</tt> is now more aggressive.</li> 
+
+<li>The aggressive dead code elimination (ADCE) optimization has been rewritten
+to make it both faster and safer in the presence of code containing infinite
+loops.  Some of its prior functionality has been factored out into the loop
+deletion pass, which <em>is</em> safe for infinite loops.</li>
+
+<li>Several optimizations have been sped up, leading to faster code generation
+    with the same code quality.</li>
+    
+<li>The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
+    functions for C-based languages, has been rewritten to be a FunctionPass
+    instead a ModulePass.  This allows it to be run more often and to be
+    included at -O1 in llvm-gcc.  It was also extended to include more
+    optimizations and several corner case bugs were fixed.</li>
+
+<li>LLVM now includes a simple 'Jump Threading' pass, which attempts to simplify
+    conditional branches using information about predecessor blocks, simplifying
+    the control flow graph.  This pass is pretty basic at this point, but
+    catches some important cases and provides a foundation to build on.</li>
+    
+<li>Several corner case bugs which could lead to deleting volatile memory
+    accesses have been fixed.</li>
 </ul>
 
 </div>
 
-<!-- ======================================================================= -->
+<!--=========================================================================-->
 <div class="doc_subsection">
-  <a name="build">Known problems with the Build System</a>
+<a name="codegen">Code Generator Improvements</a>
 </div>
 
 <div class="doc_text">
 
+<p>We put a significant amount of work into the code generator infrastructure,
+which allows us to implement more aggressive algorithms and make it run
+faster:</p>
+
 <ul>
-<li>none yet</li>
+<li>MemOperand in the code generator: describe me!.</li>
+
+<li>The target-independent code generator infrastructure now uses LLVM's APInt
+    class to handle integer values, which allows it to support integer types
+    larger than 64 bits. Note that support for such types is also dependent on
+    target-specific support. Use of APInt is also a step toward support for
+    non-power-of-2 integer sizes.</li>
+    
+<li>LLVM 2.3 includes several compile time speedups for code with large basic
+    blocks, particular in the instruction selection phase, register allocation,
+    scheduling, and tail merging/jump threading.</li>
+
+<li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
+    visualization of scheduling dependency graphs easier to understand.</li>
+    
+<li>The code generator allows targets to write patterns that generate subreg
+    references directly in .td files now.</li>
+    
+<li><tt>memcpy</tt> lowering in the backend is more aggressive, particularly for
+    <tt>memcpy</tt> calls introduced by the code generator when handling
+    pass-by-value structure argument copies.</li>
+    
+<li>Inline assembly with multiple register results now returns those results
+    directly in the appropriate registers, rather than going through memory.
+    Inline assembly that uses constraints like "ir" with immediates now use the
+    'i' form when possible instead of always loading the value in a register.
+    This saves an instruction and reduces register use.</li>
+
+<li>Added support for PIC/GOT style tail calls on x86/32 and initial support
+    for tail calls on PowerPC 32 (it may also work on ppc64 but not
+    thoroughly tested).</li>
 </ul>
+
 </div>
 
 
-<!-- ======================================================================= -->
+<!--=========================================================================-->
 <div class="doc_subsection">
-  <a name="core">Known problems with the LLVM Core</a>
+<a name="x86specific">X86/X86-64 Specific Improvements</a>
 </div>
 
 <div class="doc_text">
+<p>New target-specific features include:
+</p>
 
 <ul>
-  <li>In the JIT, <tt>dlsym()</tt> on a symbol compiled by the JIT will not
-  work.</li>
-</ul>
-</div>
+<li>llvm-gcc's X86-64 ABI conformance is far improved, particularly in the
+    area of passing and returning structures by value.  llvm-gcc compiled code
+    now interoperates very well on X86-64 systems with other compilers.</li>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="c-fe">Known problems with the C front-end</a>
-</div>
+<li>Support for Win64 was added. This includes code generation itself, JIT
+    support and necessary changes to llvm-gcc.</li>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
+<li>The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
+    the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins.  Various
+    generic vector operations (insert/extract/shuffle) are much more efficient
+    when SSE 4.1 is enabled.  The JIT automatically takes advantage of these
+    instructions, but llvm-gcc must be explicitly told to use them, e.g. with
+    <tt>-march=penryn</tt>.</li>
 
-<div class="doc_text">
+<li>The X86 backend now does a number of optimizations that aim to avoid
+    converting numbers back and forth from SSE registers to the X87 floating
+    point stack.</li>
 
-<p>
-llvm-gcc3 has many significant problems that are fixed by llvm-gcc4.
-Two major ones include:</p>
+<li>The X86 backend supports stack realignment, which is particularly useful for
+    vector code on OS's without 16-byte aligned stacks.</li>
 
-<ul>
-<li>With llvm-gcc3, 
-    C99 variable sized arrays do not release stack memory when they go out of 
-    scope.  Thus, the following program may run out of stack space:
-<pre>
-    for (i = 0; i != 1000000; ++i) {
-      int X[n];
-      foo(X);
-    }
-</pre></li>
+<li>The X86 backend now supports the "sseregparm" options in GCC, which allow
+    functions to be tagged as passing floating point values in SSE
+    registers.</li>
 
-<li>With llvm-gcc3, Initialization of global union variables can only be done <a
-href="http://llvm.org/PR162">with the largest union member</a>.</li>
+<li>Trampolines (taking the address of a nested function) now work on
+    Linux/X86-64.</li>
 
-</ul>
+<li><tt>__builtin_prefetch</tt> is now compiled into the appropriate prefetch
+    instructions instead of being ignored.</li>
 
-<p>llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but
-does not currently support Link-Time-Optimization or C++ Exception Handling,
-which llvm-gcc3 does.</p>
+<li>128-bit integers are now supported on X86-64 targets.</li>
 
+<li>The register allocator can now rematerialize PIC-base computations.</li>
+
+<li>The "t" and "f" inline assembly constraints for the X87 floating point stack
+    now work.  However, the "u" constraint is still not fully supported.</li>
+
+</ul>
+  
 </div>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  Notes
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="targetspecific">Other Target Specific Improvements</a>
 </div>
 
 <div class="doc_text">
+<p>New target-specific features include:
+</p>
 
 <ul>
-
-<li>"long double" is transformed by the front-end into "double".  There is no
-support for floating point data types of any size other than 32 and 64
-bits.</li>
-    
-<li>The following Unix system functionality has not been tested and may not
-work:
-  <ol>
-  <li><tt>sigsetjmp</tt>, <tt>siglongjmp</tt> - These are not turned into the
-      appropriate <tt>invoke</tt>/<tt>unwind</tt> instructions.  Note that
-      <tt>setjmp</tt> and <tt>longjmp</tt> <em>are</em> compiled correctly.
-  <li><tt>getcontext</tt>, <tt>setcontext</tt>, <tt>makecontext</tt>
-      - These functions have not been tested.
-  </ol></li>
-
-<li>Although many GCC extensions are supported, some are not.  In particular,
-    the following extensions are known to <b>not be</b> supported:
-  <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>:   Built-in functions specific to particular targets.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html">Thread-Local</a>: Per-thread variables.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
-  </ol>
-
-  <p>The following GCC extensions are <b>partially</b> supported.  An ignored
-  attribute means that the LLVM compiler ignores the presence of the attribute,
-  but the code should still work.  An unsupported attribute is one which is
-  ignored by the LLVM compiler and will cause a different interpretation of
-  the program.</p>
-
-  <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable%20Length">Variable Length</a>:
-      Arrays whose length is computed at run time.<br>
-      Supported, but allocated stack space is not freed until the function returns (noted above).</li>
-
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
-
-      Declaring that functions have no side effects or that they can never
-      return.<br>
-
-      <b>Supported:</b> <tt>format</tt>, <tt>format_arg</tt>, <tt>non_null</tt>,
-      <tt>noreturn</tt>, <tt>constructor</tt>, <tt>destructor</tt>,
-      <tt>unused</tt>, <tt>used</tt>,
-      <tt>deprecated</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
-
-      <b>Ignored:</b> <tt>noinline</tt>,
-      <tt>always_inline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
-      <tt>malloc</tt>, <tt>no_instrument_function</tt>, <tt>cdecl</tt><br>
-
-      <b>Unsupported:</b> <tt>section</tt>, <tt>alias</tt>,
-      <tt>visibility</tt>, <tt>regparm</tt>, <tt>stdcall</tt>,
-      <tt>fastcall</tt>, all other target specific attributes</li>
-   
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
-      Specifying attributes of variables.<br>
-      <b>Supported:</b> <tt>cleanup</tt>, <tt>common</tt>, <tt>nocommon</tt>,
-                        <tt>deprecated</tt>, <tt>transparent_union</tt>,
-                        <tt>unused</tt>, <tt>used</tt>, <tt>weak</tt><br>
-
-      <b>Unsupported:</b> <tt>aligned</tt>, <tt>mode</tt>, <tt>packed</tt>,
-                        <tt>section</tt>, <tt>shared</tt>, <tt>tls_model</tt>,
-                        <tt>vector_size</tt>, <tt>dllimport</tt>, 
-                        <tt>dllexport</tt>, all target specific attributes.</li>
-
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>:  Specifying attributes of types.<br>
-      <b>Supported:</b> <tt>transparent_union</tt>, <tt>unused</tt>,
-                        <tt>deprecated</tt>, <tt>may_alias</tt><br>
-
-      <b>Unsupported:</b> <tt>aligned</tt>, <tt>packed</tt>, 
-                        all target specific attributes.</li>
-
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
-      Other built-in functions.<br>
-      We support all builtins which have a C language equivalent (e.g., 
-         <tt>__builtin_cos</tt>),  <tt>__builtin_alloca</tt>, 
-         <tt>__builtin_types_compatible_p</tt>, <tt>__builtin_choose_expr</tt>,
-         <tt>__builtin_constant_p</tt>, and <tt>__builtin_expect</tt>
-         (currently ignored).  We also support builtins for ISO C99 floating
-         point comparison macros (e.g., <tt>__builtin_islessequal</tt>), 
-         <tt>__builtin_prefetch</tt>, <tt>__builtin_popcount[ll]</tt>,
-         <tt>__builtin_clz[ll]</tt>, and <tt>__builtin_ctz[ll]</tt>.</li>
-  </ol>
-
-  <p>The following extensions <b>are</b> known to be supported:</p>
-
-  <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>:   Putting statements and declarations inside expressions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>:   Data types for complex numbers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Hex-Floats.html#Hex%20Floats">Hex Floats</a>:Hexadecimal floating-point constants.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero%20Length">Zero Length</a>: Zero-length arrays.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html#Empty%20Structures">Empty Structures</a>: Structures with no members.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic%20Macros">Variadic Macros</a>: Macros with a variable number of arguments.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Escaped-Newlines.html#Escaped%20Newlines">Escaped Newlines</a>:  Slightly looser rules for escaped newlines.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Subscripting.html#Subscripting">Subscripting</a>: Any array can be subscripted, even if not an lvalue.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer%20Arith">Pointer Arith</a>: Arithmetic on <code>void</code>-pointers and function pointers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Initializers.html#Initializers">Initializers</a>: Non-constant initializers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html#Compound%20Literals">Compound Literals</a>: Compound literals give structures, unions,
-or arrays as values.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html#Designated%20Inits">Designated Inits</a>: Labeling elements of initializers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html#Cast%20to%20Union">Cast to Union</a>: Casting to union type from any member of the union.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html#Case%20Ranges">Case Ranges</a>: `case 1 ... 9' and such.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html#Mixed%20Declarations">Mixed Declarations</a>: Mixing declarations and code.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Prototypes.html#Function%20Prototypes">Function Prototypes</a>: Prototype declarations and old-style definitions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Comments.html#C_002b_002b-Comments">C++ Comments</a>: C++ comments are recognized.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html#Dollar%20Signs">Dollar Signs</a>: Dollar sign is allowed in identifiers.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Character-Escapes.html#Character%20Escapes">Character Escapes</a>: <code>\e</code> stands for the character &lt;ESC&gt;.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alignment.html#Alignment">Alignment</a>: Inquiring about the alignment of a type or variable.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline">Inline</a>: Defining inline functions (as fast as macros).</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>:  <code>enum foo;</code>, with details to follow.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.</li>
-  </ol></li>
-
+<li>The LLVM C backend now supports vector code.</li>
 </ul>
+  
+</div>
 
-<p>If you run into GCC extensions which have not been included in any of these
-lists, please let us know (also including whether or not they work).</p>
 
-</div>
 
-<!-- ======================================================================= -->
+<!--=========================================================================-->
 <div class="doc_subsection">
-  <a name="c++-fe">Known problems with the C++ front-end</a>
+<a name="otherimprovements">Other Improvements</a>
 </div>
 
 <div class="doc_text">
+<p>New features include:
+</p>
 
-<p>For this release, the C++ front-end is considered to be fully
-tested and works for a number of non-trivial programs, including LLVM
-itself.</p>
-
+<ul>
+<li>LLVM now builds with GCC 4.3.</li>
+<li>Bugpoint now supports running custom scripts (with the <tt>-run-custom</tt>
+    option) to determine how to execute the command and whether it is making
+    forward process.</li>
+</ul>
+  
 </div>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="portability">Portability and Supported Platforms</a>
+</div>
+<!-- *********************************************************************** -->
 
 <div class="doc_text">
 
-<ul>
-<li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
-    front-end</a>.</li>
+<p>LLVM is known to work on the following platforms:</p>
 
+<ul>
+<li>Intel and AMD machines (IA32) running Red Hat Linux, Fedora Core and FreeBSD 
+      (and probably other unix-like systems).</li>
+<li>PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and
+    64-bit modes.</li>
+<li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
+<li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
+    support is available for native builds with Visual C++).</li>
+<li>Sun UltraSPARC workstations running Solaris 10.</li>
+<li>Alpha-based machines running Debian GNU/Linux.</li>
+<li>Itanium-based (IA64) machines running Linux and HP-UX.</li>
 </ul>
 
+<p>The core LLVM infrastructure uses GNU autoconf to adapt itself
+to the machine and operating system on which it is built.  However, minor
+porting may be required to get LLVM to work on new platforms.  We welcome your
+portability patches and reports of successful builds or error messages.</p>
+
 </div>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  Notes
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="knownproblems">Known Problems</a>
 </div>
+<!-- *********************************************************************** -->
 
 <div class="doc_text">
 
-<ul>
+<p>This section contains all known problems with the LLVM system, listed by
+component.  As new problems are discovered, they will be added to these
+sections.  If you run into a problem, please check the <a
+href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
+there isn't already one.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="experimental">Experimental features included with this release</a>
+</div>
 
-<li>Destructors for local objects are not always run when a <tt>longjmp</tt> is
-    performed. In particular, destructors for objects in the <tt>longjmp</tt>ing
-    function and in the <tt>setjmp</tt> receiver function may not be run.
-    Objects in intervening stack frames will be destroyed, however (which is
-    better than most compilers).</li>
-
-<li>The LLVM C++ front-end follows the <a
-    href="http://www.codesourcery.com/cxx-abi">Itanium C++ ABI</a>.
-    This document, which is not Itanium specific, specifies a standard for name
-    mangling, class layout, v-table layout, RTTI formats, and other C++
-    representation issues.  Because we use this API, code generated by the LLVM
-    compilers should be binary compatible with machine code generated by other
-    Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
-    <i>However</i>, the exception handling mechanism used by LLVM is very
-    different from the model used in the Itanium ABI, so <b>exceptions will not
-    interact correctly</b>. </li>
+<div class="doc_text">
+
+<p>The following components of this LLVM release are either untested, known to
+be broken or unreliable, or are in early development.  These components should
+not be relied on, and bugs should not be filed against them, but they may be
+useful to some people.  In particular, if you would like to work on one of these
+components, please contact us on the <a
+href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 
+<ul>
+<li>The MSIL, IA64, Alpha, SPU, and MIPS backends are experimental.</li>
+<li>The llc "<tt>-filetype=asm</tt>" (the default) is the only supported
+    value for this option.</li>
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="c-be">Known problems with the C back-end</a>
+  <a name="x86-be">Known problems with the X86 back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
+  <li>The X86 backend does not yet support
+    all <a href="http://llvm.org/PR879">inline assembly that uses the X86
+    floating point stack</a>.  It supports the 'f' and 't' constraints, but not
+    'u'.</li>
+  <li>The X86 backend generates inefficient floating point code when configured
+    to generate code for systems that don't have SSE2.</li>
+  <li>Win64 code generation wasn't widely tested. Everything should work, but we
+    expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
+    currently due
+    to <a href="http://llvm.org/PR2255">several</a>
+    <a href="http://llvm.org/PR2257">bugs</a> in FP stackifier
+</ul>
 
-<li>The C back-end produces code that violates the ANSI C Type-Based Alias
-Analysis rules.  As such, special options may be necessary to compile the code
-(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
-problem probably cannot be fixed.</li>
+</div>
 
-<li><a href="http://llvm.org/PR56">Zero arg vararg functions are not 
-supported</a>.  This should not affect LLVM produced by the C or C++ 
-frontends.</li>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ppc-be">Known problems with the PowerPC back-end</a>
+</div>
 
-<li>The C backend does not correctly implement the <a 
-href="LangRef.html#i_stacksave"><tt>llvm.stacksave</tt></a> or
-<a href="LangRef.html#i_stackrestore"><tt>llvm.stackrestore</tt></a> 
-intrinsics.  This means that some code compiled by it can run out of stack
-space if they depend on these (e.g. C99 varargs).</li>
+<div class="doc_text">
 
+<ul>
+<li>The Linux PPC32/ABI support needs testing for the interpreter and static
+compilation, and lacks support for debug information.</li>
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="x86-be">Known problems with the X86 back-end</a>
+  <a name="arm-be">Known problems with the ARM back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li>none yet.</li>
+<li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
+processors, thumb programs can crash or produce wrong
+results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
+<li>Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
+</li>
+<li>There is a bug in QEMU-ARM (&lt;= 0.9.0) which causes it to incorrectly
+ execute
+programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="ppc-be">Known problems with the PowerPC back-end</a>
+  <a name="sparc-be">Known problems with the SPARC back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li><a href="http://llvm.org/PR642">PowerPC backend does not correctly
-implement ordered FP comparisons</a>.</li>
+<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
+    support the 64-bit SPARC ABI (-m64).</li>
 </ul>
 
 </div>
@@ -589,7 +640,6 @@ implement ordered FP comparisons</a>.</li>
 appropriate nops inserted to ensure restartability.</li>
 
 </ul>
-
 </div>
 
 <!-- ======================================================================= -->
@@ -616,40 +666,113 @@ compilers.</li>
 output with code built with other compilers, particularly for floating-point
 programs.</li>
 
-<li>Defining vararg functions is not supported (but calling them is ok).</li>
+<li>Defining vararg functions is not supported (but calling them is OK).</li>
 
+<li>The Itanium backend has bitrotted somewhat.</li>
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="sparc-be">Known problems with the SPARC back-end</a>
+  <a name="c-be">Known problems with the C back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
-    support the 64-bit SPARC ABI (-m64).</li>
+<li><a href="http://llvm.org/PR802">The C backend has only basic support for
+    inline assembly code</a>.</li>
+<li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
+    C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
+    C++ code compiled with llc or native compilers.</li>
+<li>The C backend does not support all exception handling constructs.</li>
 </ul>
 
 </div>
 
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="arm-be">Known problems with the ARM back-end</a>
+  <a name="c-fe">Known problems with the llvm-gcc C front-end</a>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Bugs</div>
+
+<div class="doc_text">
+
+<p>llvm-gcc does not currently support <a href="http://llvm.org/PR869">Link-Time
+Optimization</a> on most platforms "out-of-the-box".  Please inquire on the
+llvmdev mailing list if you are interested.</p>
+
+<p>The only major language feature of GCC not supported by llvm-gcc is
+    the <tt>__builtin_apply</tt> family of builtins.   However, some extensions
+    are only supported on some targets.  For example, trampolines are only
+    supported on some targets (these are used when you take the address of a
+    nested function).</p>
+
+<p>If you run into GCC extensions which are not supported, please let us know.
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="c++-fe">Known problems with the llvm-gcc C++ front-end</a>
 </div>
 
 <div class="doc_text">
 
+<p>The C++ front-end is considered to be fully
+tested and works for a number of non-trivial programs, including LLVM
+itself, Qt, Mozilla, etc.</p>
+
 <ul>
-<li>The ARM backend is currently in early development stages, it is not 
-ready for production use.</li>
+<li>Exception handling works well on the X86 and PowerPC targets, including
+X86-64 darwin.  This works when linking to a libstdc++ compiled by GCC.  It is
+supported on X86-64 linux, but that is disabled by default in this release.</li>
 </ul>
 
 </div>
 
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
+</div>
+
+<div class="doc_text">
+The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
+technology and problems should be expected.
+<ul>
+<li>The Ada front-end currently only builds on X86-32.  This is mainly due
+to lack of trampoline support (pointers to nested functions) on other platforms,
+however it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
+which does support trampolines.</li>
+<li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
+Workaround: configure with --disable-bootstrap.</li>
+<li>The c380004 and <a href="http://llvm.org/PR2010">c393010</a> ACATS tests
+fail (c380004 also fails with gcc-4.2 mainline).  When built at -O3, the
+<a href="http://llvm.org/PR2421">cxg2021</a> ACATS test also fails.</li>
+<li>Some gcc specific Ada tests continue to crash the compiler.  The testsuite
+reports most tests as having failed even though they pass.</li>
+<li>The -E binder option (exception backtraces)
+<a href="http://llvm.org/PR1982">does not work</a> and will result in programs
+crashing if an exception is raised.  Workaround: do not use -E.</li>
+<li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
+or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
+or use representation clauses that result in a field of a non-discrete type
+starting or finishing in the middle of a byte.</li>
+<li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
+'main' as generated by the Ada binder to be invalid</a>.
+Workaround: hand edit the file to use pointers for <tt>argv</tt> and
+<tt>envp</tt> rather than integers.</li>
+<li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
+ignored</a>.</li>
+</ul>
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="additionalinfo">Additional Information</a>
@@ -659,11 +782,10 @@ ready for production use.</li>
 <div class="doc_text">
 
 <p>A wide variety of additional information is available on the <a
-href="http://llvm.org">LLVM web page</a>, including <a
-href="http://llvm.org/docs/">documentation</a> and <a
-href="http://llvm.org/pubs/">publications describing algorithms and
-components implemented in LLVM</a>.  The web page also contains versions of the
-API documentation which is up-to-date with the CVS version of the source code.
+href="http://llvm.org">LLVM web page</a>, in particular in the <a
+href="http://llvm.org/docs/">documentation</a> section.  The web page also
+contains versions of the API documentation which is up-to-date with the
+Subversion version of the source code.
 You can access versions of these documents specific to this release by going
 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
 
@@ -680,9 +802,9 @@ lists</a>.</p>
   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
   <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
-  <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
+  <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$
 </address>