add some random nounwinds.
[oota-llvm.git] / docs / ReleaseNotes.html
index fdeb6ecde335cbe561ddcffc6a486f45bde13763..84200c3b7275218df378b56133ac4c1da643e945 100644 (file)
@@ -4,25 +4,33 @@
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 2.1 Release Notes</title>
+  <title>LLVM 2.7 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 2.1 Release Notes</div>
+<div class="doc_title">LLVM 2.7 Release Notes</div>
+
 <ol>
   <li><a href="#intro">Introduction</a></li>
-  <li><a href="#whatsnew">What's New?</a></li>
+  <li><a href="#subproj">Sub-project Status Update</a></li>
+  <li><a href="#externalproj">External Projects Using LLVM 2.7</a></li>
+  <li><a href="#whatsnew">What's New in LLVM 2.7?</a></li>
   <li><a href="GettingStarted.html">Installation Instructions</a></li>
   <li><a href="#portability">Portability and Supported Platforms</a></li>
-  <li><a href="#knownproblems">Known Problems</a>
+  <li><a href="#knownproblems">Known Problems</a></li>
   <li><a href="#additionalinfo">Additional Information</a></li>
 </ol>
 
 <div class="doc_author">
-  <p>Written by the <a href="http://llvm.org">LLVM Team</a><p>
+  <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
 </div>
 
+<h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.7
+release.<br>
+You may prefer the
+<a href="http://llvm.org/releases/2.6/docs/ReleaseNotes.html">LLVM 2.6
+Release Notes</a>.</h1>
+
 <!-- *********************************************************************** -->
 <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 2.1.  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>This document contains the release notes for the LLVM Compiler
+Infrastructure, release 2.7.  Here we describe the status of LLVM, including
+major improvements from the previous release and significant 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
 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>
+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 a Subversion checkout or the 
+<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
+current one.  To see the release notes for a specific release, please see the
 <a href="http://llvm.org/releases/">releases page</a>.</p>
 
 </div>
+
+<!--
+Almost dead code.
+  include/llvm/Analysis/LiveValues.h => Dan
+  lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8.
+  llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8.
+  ABCD, SCCVN, GEPSplitterPass
+  MSIL backend?
+  AndersAA -> Unsupported, zap after branch.
+-->
+   
+<!-- Features that need text if they're finished for 2.7:
+  gcc plugin.
+  strong phi elim
+  variable debug info for optimized code
+  postalloc scheduler: anti dependence breaking, hazard recognizer?
+  metadata
+  loop dependence analysis
+  ELF Writer?  How stable?
+  <li>PostRA scheduler improvements, ARM adoption (David Goodwin).</li>
+  2.7 supports the GDB 7.0 jit interfaces for debug info.
+  2.7 eliminates ADT/iterator.h
+ -->
+
+ <!-- for announcement email:
+ Logo web page.
+ llvm devmtg
+ compiler_rt
+ KLEE web page at klee.llvm.org
+ Many new papers added to /pubs/
+   Mention gcc plugin.
+
+   -->
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
-  <a name="whatsnew">What's New?</a>
+  <a name="subproj">Sub-project Status Update</a>
 </div>
 <!-- *********************************************************************** -->
 
 <div class="doc_text">
+<p>
+The LLVM 2.7 distribution currently consists of code from the core LLVM
+repository (which roughly includes the LLVM optimizers, code generators
+and supporting tools), the Clang repository and the llvm-gcc repository.  In
+addition to this code, the LLVM Project includes other sub-projects that are in
+development.  Here we include updates on these subprojects.
+</p>
+
+</div>
 
-<p>This is the twelfth public release of the LLVM Compiler Infrastructure. 
-It includes many features and refinements from LLVM 2.0.</p>
 
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
+</div>
+
+<div class="doc_text">
+
+<p>The <a href="http://clang.llvm.org/">Clang project</a> is ...</p>
+
+<p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
+
+<ul>
+<li>...</li>
+</ul>
 </div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="frontends">New Frontends</a>
+<a name="clangsa">Clang Static Analyzer</a>
 </div>
 
 <div class="doc_text">
 
-<p>LLVM 2.1 brings two new beta C front-ends.  First, Duncan, Anton and Devang
-has started syncing up llvm-gcc with GCC 4.2, yielding "llvm-gcc 4.2" (creative,
-huh?).  llvm-gcc 4.2 has the promise to bring much better FORTRAN and Ada
-support to LLVM as well as features like atomic builtins, OpenMP, and many other
-things.  Check it out!</p>
+<p>Previously announced in the 2.4, 2.5, and 2.6 LLVM releases, the Clang project also
+includes an early stage static source code analysis tool for <a
+href="http://clang.llvm.org/StaticAnalysis.html">automatically finding bugs</a>
+in C and Objective-C programs. The tool performs checks to find
+bugs that occur on a specific path within a program.</p>
 
-<p>Second, LLVM now includes its own native C and Objective-C front-end (C++ is
-in progress, but is not very far along) code named "<a
-href="http://clang.llvm.org/">clang</a>".  This front-end has a number of great
-features, primarily aimed at source-level analysis and speeding up compile-time.
-At this point though, the LLVM Code Generator component is still very early in
-development, so it's mostly useful for people looking to build source-level
-analysis tools or source-to-source translators.</p>
+<p>In the LLVM 2.7 time-frame, the analyzer core has ...</p>
 
 </div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="optimizer">Optimizer Improvements</a>
+<a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
 </div>
 
 <div class="doc_text">
+<p>
+The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
+a JVM and a CLI Virtual Machine (Microsoft .NET is an
+implementation of the CLI) using LLVM for static and just-in-time
+compilation.</p>
 
-<p>Some of the most noticable feature improvements this release have been in the
-optimizer, speeding it up and making it more aggressive.  For example:</p>
+<p>
+VMKit version ?? builds with LLVM 2.7 and you can find it on its
+<a href="http://vmkit.llvm.org/releases/">web page</a>. The release includes
+bug fixes, cleanup and new features. The major changes are:</p>
 
 <ul>
 
-<li>Owen Anderson wrote the new MemoryDependenceAnalysis pass, which provides 
-    a lazy, caching layer on top of <a href="AliasAnalysis.html">
-    AliasAnalysis</a>.  He then used it to rewrite
-    DeadStoreElimination which resulted in significantly better compile time in 
-    common cases, </li>
-<li>Owen implemented the new GVN pass, which is also based on 
-    MemoryDependenceAnalysis.  This pass replaces GCSE/LoadVN in the standard
-    set of passes, providing more aggressive optimization at a some-what 
-    improved compile-time cost.</li>
-<li>Owen implemented GVN-PRE, a partial redundancy elimination algorithm that
-    shares some details with the new GVN pass.  It is still in need of compile
-    time tuning, and is not turned on by default.</li>
-<li>Devang merged ETForest and DomTree into a single easier to use data
-    structure.  This makes it more obvious which datastructure to choose
-    (because there is only one) and makes the compiler more memory and time
-    efficient (less stuff to keep up-to-date).</li>
-<li>Nick Lewycky improved loop trip count analysis to handle many more common
-    cases.</li>
+<li>...</li>
 
 </ul>
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
+</div>
+
+<div class="doc_text">
+<p>
+The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
+is a simple library that provides an implementation of the low-level
+target-specific hooks required by code generation and other runtime components.
+For example, when compiling for a 32-bit target, converting a double to a 64-bit
+unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
+function. The compiler-rt library provides highly optimized implementations of
+this and other low-level routines (some are 3x faster than the equivalent
+libgcc routines).</p>
+
+<p>
+All of the code in the compiler-rt project is available under the standard LLVM
+License, a "BSD-style" license.</p>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="klee">KLEE: Symbolic Execution and Automatic Test Case Generator</a>
+</div>
+
+<div class="doc_text">
+<p>
+The new LLVM <a href="http://klee.llvm.org/">KLEE project</a> is a symbolic
+execution framework for programs in LLVM bitcode form.  KLEE tries to
+symbolically evaluate "all" paths through the application and records state
+transitions that lead to fault states.  This allows it to construct testcases
+that lead to faults and can even be used to verify algorithms.  For more
+details, please see the <a
+href="http://llvm.org/pubs/2008-12-OSDI-KLEE.html">OSDI 2008 paper</a> about
+KLEE.</p>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="dragonegg">DragonEgg: GCC-4.5 as an LLVM frontend</a>
+</div>
+
+<div class="doc_text">
+<p>
+The goal of <a href="http://dragonegg.llvm.org/">DragonEgg</a> is to make
+gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
+<a href="http://dragonegg.llvm.org/">DragonEgg</a> is a shared library (dragonegg.so)
+that is loaded by gcc at runtime.  It ...
+</p>
+
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="mc">llvm-mc: Machine Code Toolkit</a>
+</div>
+
+<div class="doc_text">
+<p>
+The LLVM Machine Code (MC) Toolkit project is ...
+</p>
+
+</div> 
+
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="externalproj">External Open Source Projects Using LLVM 2.7</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>An exciting aspect of LLVM is that it is used as an enabling technology for
+   a lot of other language and tools projects.  This section lists some of the
+   projects that have already been updated to work with LLVM 2.7.</p>
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="Rubinius">Rubinius</a>
+</div>
+
+<div class="doc_text">
+<p><a href="http://github.com/evanphx/rubinius">Rubinius</a> is an environment
+for running Ruby code which strives to write as much of the core class
+implementation in Ruby as possible. Combined with a bytecode interpreting VM, it
+uses LLVM to optimize and compile ruby code down to machine code. Techniques
+such as type feedback, method inlining, and uncommon traps are all used to
+remove dynamism from ruby execution and increase performance.</p>
+
+<p>Since LLVM 2.5, Rubinius has made several major leaps forward, implementing
+a counter based JIT, type feedback and speculative method inlining.
+</p>
 
 </div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="codegen">Code Generator Improvements</a>
+<a name="macruby">MacRuby</a>
 </div>
 
 <div class="doc_text">
 
-<p>One of the main focuses of this release was performance tuning and bug
-   fixing.  In addition to these, several new major changes occurred:</p>
+<p>
+<a href="http://macruby.org">MacRuby</a> is an implementation of Ruby on top of
+core Mac OS X technologies, such as the Objective-C common runtime and garbage
+collector and the CoreFoundation framework. It is principally developed by
+Apple and aims at enabling the creation of full-fledged Mac OS X applications.
+</p>
+
+<p>
+MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby
+expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception
+handling.</p>
+
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="pure">Pure</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://pure-lang.googlecode.com/">Pure</a>
+is an algebraic/functional programming language based on term rewriting.
+Programs are collections of equations which are used to evaluate expressions in
+a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
+lexical closures, a hygienic macro system (also based on term rewriting),
+built-in list and matrix support (including list and matrix comprehensions) and
+an easy-to-use C interface. The interpreter uses LLVM as a backend to
+ JIT-compile Pure programs to fast native code.</p>
+
+<p>Pure versions ??? and later have been tested and are known to work with
+LLVM 2.7 (and continue to work with older LLVM releases >= 2.3 as well).
+</p>
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="ldc">LLVM D Compiler</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://www.dsource.org/projects/ldc">LDC</a> is an implementation of
+the D Programming Language using the LLVM optimizer and code generator.
+The LDC project works great with the LLVM 2.6 release.  General improvements in
+this
+cycle have included new inline asm constraint handling, better debug info
+support, general bug fixes and better x86-64 support.  This has allowed
+some major improvements in LDC, getting it much closer to being as
+fully featured as the original DMD compiler from DigitalMars.
+</p>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="RoadsendPHP">Roadsend PHP</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
+source implementation of the PHP programming 
+language that uses LLVM for its optimizer, JIT and static compiler. This is a 
+reimplementation of an earlier project that is now based on LLVM.</p>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="UnladenSwallow">Unladen Swallow</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://code.google.com/p/unladen-swallow/">Unladen Swallow</a> is a
+branch of <a href="http://python.org/">Python</a> intended to be fully
+compatible and significantly faster.  It uses LLVM's optimization passes and JIT
+compiler.</p>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="llvm-lua">llvm-lua</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://code.google.com/p/llvm-lua/">LLVM-Lua</a> uses LLVM to add JIT
+and static compiling support to the Lua VM.  Lua bytecode is analyzed to
+remove type checks, then LLVM is used to compile the bytecode down to machine
+code.</p>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="icedtea">IcedTea Java Virtual Machine Implementation</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
+harness to build OpenJDK using only free software build tools and to provide
+replacements for the not-yet free parts of OpenJDK.  One of the extensions that
+IcedTea provides is a new JIT compiler named <a
+href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
+to provide native code generation without introducing processor-dependent
+code.
+</p>
+</div>
+
+
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="whatsnew">What's New in LLVM 2.7?</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>This release includes a huge number of bug fixes, performance tweaks and
+minor improvements.  Some of the major improvements and new features are listed
+in this section.
+</p>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="majorfeatures">Major New Features</a>
+</div>
+
+<div class="doc_text">
+
+<p>LLVM 2.7 includes several major new capabilities:</p>
 
 <ul>
+<li>...</li>
+</ul>
 
-<li>Dale finished up the Tail Merging optimization in the code generator, and
-    enabled it by default.  This produces smaller code that is also faster in
-    some cases.</li>
+</div>
 
-<li>Christopher Lamb implemented support for virtual register sub-registers,
-    which can be used to better model many forms of subregisters.  As an example
-    use, he modified the X86 backend to use this to model truncates and
-    extends more accurately (leading to better code).</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="coreimprovements">LLVM IR and Core Improvements</a>
+</div>
 
-<li>Dan Gohman changed the way we represent vectors before legalization,
-    significantly simplifying the SelectionDAG representation for these and
-    making the code generator faster for vector code.</li>
+<div class="doc_text">
+<p>LLVM IR has several new features for better support of new targets and that
+expose new optimization opportunities:</p>
 
-<li>Evan contributed a new target independent if-converter.  While it is 
-    target independent, at this point only the ARM backend uses it so far.</li>
+<ul>
+<li>...</li>
+</ul>
 
-<li>Evan rewrite the way the register allocator handles rematerialization,
-    allowing it to be much more effective on two-address targets like X86,
-    and taught it to fold loads away when possible (also a big win on X86).</li>
+</div>
 
-<li>Dan Gohman contributed support for better alignment and volatility handling
-    in the code generator, and significantly enhanced alignment analysis for SSE
-    load/store instructions.  With his changes, an insufficiently-aligned SSE
-    load instruction turns into <tt>movups</tt>, for example.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="optimizer">Optimizer Improvements</a>
+</div>
 
-<li>Duraid Madina contributed a new "bigblock" register allocator, and Roman
-    Levenstein contributed several big improvements.  BigBlock is optimized for
-    code that uses very large basic blocks.  It is slightly slower than the
-    "local" allocator, but produces much better code.</li>
+<div class="doc_text">
 
-<li>David Greene refactored the register allocator to split coalescing out from
-    allocation, making coalescers pluggable.</li>
+<p>In addition to a large array of minor performance tweaks and bug fixes, this
+release includes a few major enhancements and additions to the optimizers:</p>
+
+<ul>
+
+<li>...</li>
 
 </ul>
 
@@ -173,120 +457,204 @@ optimizer, speeding it up and making it more aggressive.  For example:</p>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="targetspecific">Target Specific Improvements</a>
+<a name="executionengine">Interpreter and JIT Improvements</a>
 </div>
 
 <div class="doc_text">
-<p>New features include:
-</p>
 
 <ul>
-<li>Bruno Cardoso Lopes contributed initial MIPS support.  It is sufficient to
-    run many small programs, but is still incomplete and is not yet
-    fully performant.</li>
-    
-<li>Bill Wendling added SSSE3 support to the X86 backend.</li>
+<li>The JIT now <a
+href="http://llvm.org/viewvc/llvm-project?view=rev&revision=85295">defaults
+to compiling eagerly</a> to avoid a race condition in the lazy JIT.
+Clients that still want the lazy JIT can switch it on by calling
+<tt>ExecutionEngine::DisableLazyCompilation(false)</tt>.</li>
+<li>It is now possible to create more than one JIT instance in the same process.
+These JITs can generate machine code in parallel,
+although <a href="http://llvm.org/docs/ProgrammersManual.html#jitthreading">you
+still have to obey the other threading restrictions</a>.</li>
+</ul>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="codegen">Target Independent Code Generator Improvements</a>
+</div>
+
+<div class="doc_text">
 
-<li>Nicholas Geoffray contributed improved linux/ppc ABI and JIT support.</li>
+<p>We have 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>
 
-<li>Dale Johannesen rewrote handling of 32-bit float values in the X86 backend
-    when using the floating point stack, fixing several nasty bugs.</li>
+<ul>
 
-<li>Dan contributed rematerialization support for the X86 backend, in addition
-    to several X86-specific micro optimizations.</li>
+<li>...</li>
 </ul>
-  
 </div>
 
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="x86">X86-32 and X86-64 Target Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New features of the X86 target include:
+</p>
+
+<ul>
+
+<li>...</li>
+
+</ul>
+
+</div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="llvmgccimprovements">llvm-gcc Improvements</a>
+<a name="pic16">PIC16 Target Improvements</a>
 </div>
 
 <div class="doc_text">
-<p>New features include:
+<p>New features of the PIC16 target include:
 </p>
 
 <ul>
-<li>Duncan and Anton made significant progress chasing down a number of problems
-    with C++ Zero-Cost exception handling in llvm-gcc 4.0 and 4.2.  It is now at
-    the point where it "just works" on linux/x86-32 and has partial support on
-    other targets.</li>
+<li>...</li>
+</ul>
+
+<p>Things not yet supported:</p>
+
+<ul>
+<li>Variable arguments.</li>
+<li>Interrupts/programs.</li>
+</ul>
 
-<li>Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma
-    pack, and variable sized fields in structures.</li>
+</div>
 
-<li>Tanya implemented support for <tt>__attribute__((noinline))</tt> in
-    llvm-gcc, and added support for generic variable annotations which are
-    propagated into the LLVM IR, e.g.
-    "<tt>int X __attribute__((annotate("myproperty")));</tt>".</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="ARM">ARM Target Improvements</a>
+</div>
 
-<li>Sheng Zhou and Christopher Lamb implemented alias analysis support for
-"restrict" pointer arguments to functions.</li>
+<div class="doc_text">
+<p>New features of the ARM target include:
+</p>
 
-<li>Duncan contributed support for trampolines (taking the address of a nested
-    functions), currently this is only supported in the x86 target.</li>
+<ul>
 
-<li>Lauro Ramos Venancio contributed support to encode alignment info in 
-    load and store instructions, the foundation for other alignment-related
-    work.</li>
+<li>...</li>
 </ul>
-  
+
+
 </div>
 
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="OtherTarget">Other Target Specific Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New features of other targets include:
+</p>
+
+<ul>
+<li>...</li>
+</ul>
+
+</div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="coreimprovements">LLVM Core Improvements</a>
+<a name="newapis">New Useful APIs</a>
 </div>
 
 <div class="doc_text">
-<p>New features include:
+
+<p>This release includes a number of new APIs that are used internally, which
+   may also be useful for external clients.
 </p>
 
 <ul>
-<li>Neil Booth contributed a new "APFloat" class, which ensures that floating
-    point representation and constant folding is not dependent on the host 
-    architecture that builds the application.  This support is the foundation
-    for "long double" support that will be wrapped up in LLVM 2.2.</li>
-    
-<li>Based on the APFloat class, Dale redesigned the internals of the ConstantFP
-    class and has been working on extending the core and optimizer components to
-    support various target-specific 'long double's.  We expect this work to be
-    completed in LLVM 2.2.</li>
+<li>...</li>
+</ul>
 
-<li>LLVM now provides an LLVMBuilder class, which makes it significantly easier
-    to create LLVM IR instructions.</li>
 
-<li>Reid contributed support for intrinsics that take arbitrary integer typed
-    arguments.  Dan Gohman and Chandler extended it to support arbitrary
-    floating point arguments and vectors.</li>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="otherimprovements">Other Improvements and New Features</a>
+</div>
+
+<div class="doc_text">
+<p>Other miscellaneous features include:</p>
+
+<ul>
+<li>...</li>
 </ul>
-  
+
 </div>
 
+
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="otherimprovements">Other Improvements</a>
+<a name="changes">Major Changes and Removed Features</a>
 </div>
 
 <div class="doc_text">
-<p>New features include:
-</p>
+
+<p>If you're already an LLVM user or developer with out-of-tree changes based
+on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
+from the previous release.</p>
 
 <ul>
-<li>Sterling Stein contributed a new BrainF frontend, located in llvm/examples.
-    This shows a some of the more modern APIs for building a front-end, and
-    demonstrates JIT compiler support.</li>
+<li>The LLVM interpreter now defaults to <em>not</em> using <tt>libffi</tt> even
+if you have it installed.  This makes it more likely that an LLVM built on one
+system will work when copied to a similar system.  To use <tt>libffi</tt>,
+configure with <tt>--enable-libffi</tt>.
+</li>
+</ul>
+
 
-<li>David Green contributed a new <tt>--enable-expensive-checks</tt> configure
-    option which enables STL checking, and fixed several bugs exposed by
-    it.</li>
+<p>In addition, many APIs have changed in this release.  Some of the major LLVM
+API changes are:</p>
+
+<ul>
+<li><tt>ModuleProvider</tt> has been <a
+href="http://llvm.org/viewvc/llvm-project?view=rev&revision=94686">removed</a>
+and its methods moved to <tt>Module</tt> and <tt>GlobalValue</tt>.
+Most clients can remove uses of <tt>ExistingModuleProvider</tt>,
+replace <tt>getBitcodeModuleProvider</tt> with
+<tt>getLazyBitcodeModule</tt>, and pass their <tt>Module</tt> to
+functions that used to accept <tt>ModuleProvider</tt>.  Clients who
+wrote their own <tt>ModuleProvider</tt>s will need to derive from
+<tt>GVMaterializer</tt> instead and use
+<tt>Module::setMaterializer</tt> to attach it to a
+<tt>Module</tt>.</li>
+
+<li><tt>GhostLinkage</tt> has given up the ghost.
+<tt>GlobalValue</tt>s that have not yet been read from their backing
+storage have the same linkage they will have after being read in.
+Clients must replace calls to
+<tt>GlobalValue::hasNotBeenReadFromBitcode</tt> with
+<tt>GlobalValue::isMaterializable</tt>.</li>
+
+<li>FIXME: Debug info has been totally redone. Add pointers to new APIs. Substantial caveats about compatibility of .ll and .bc files.</li>
+
+<li>The <tt>llvm/Support/DataTypes.h</tt> header has moved
+to <tt>llvm/System/DataTypes.h</tt>.</li>
+
+<li>The <tt>isInteger</tt>, <tt>isIntOrIntVector</tt>, <tt>isFloatingPoint</tt>,
+<tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed
+<tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>, 
+<tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.</li>
 </ul>
-  
+
 </div>
 
+
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="portability">Portability and Supported Platforms</a>
@@ -298,20 +666,19 @@ optimizer, speeding it up and making it more aggressive.  For example:</p>
 <p>LLVM is known to work on the following platforms:</p>
 
 <ul>
-<li>Intel and AMD machines 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.2 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 (IA32, X86-64, AMD64, EMT-64) running Red Hat
+    Linux, Fedora Core, FreeBSD and AuroraUX (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 8.</li>
+<li>Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.</li>
 <li>Alpha-based machines running Debian GNU/Linux.</li>
-<li>Itanium-based machines running Linux and HP-UX.</li>
 </ul>
 
-<p>The core LLVM infrastructure uses
-<a href="http://www.gnu.org/software/autoconf/">GNU autoconf</a> to adapt itself
+<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>
@@ -326,12 +693,26 @@ portability patches and reports of successful builds or error messages.</p>
 
 <div class="doc_text">
 
-<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
+<p>This section contains significant known problems with the LLVM system,
+listed by component.  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>
 
+<ul>
+<li>The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15)
+    with a message of "<tt><a href="http://llvm.org/PR5004">Error: can not do 8
+    byte pc-relative relocation</a></tt>" when building C++ code.  We intend to
+    fix this on mainline, but a workaround is to upgrade to binutils 2.17 or
+    later.</li>
+    
+<li>LLVM will not correctly compile on Solaris and/or OpenSolaris
+using the stock GCC 3.x.x series 'out the box',
+See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>.
+However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a>
+for x86/x86-64 has been made available from the third party AuroraUX Project
+that has been meticulously tested for bootstrapping LLVM &amp; Clang.</li>
+</ul>
+
 </div>
 
 <!-- ======================================================================= -->
@@ -345,17 +726,15 @@ there isn't already one.</p>
 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>
+components, please contact us on the <a
+href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 
 <ul>
-<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in a 
-    future release.</li>
-<li>C++ EH support is disabled for this release.</li>
-<li>The MSIL backend is experimental.</li>
-<li>The IA64 code generator is experimental.</li>
-<li>The Alpha backend is experimental.</li>
-<li>"<tt>-filetype=asm</tt>" (the default) is the only supported value for the 
-    <tt>-filetype</tt> llc option.</li>
+<li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
+    experimental.</li>
+<li>The <tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
+    supported value for this option.  The ELF writer is experimental.</li>
+<li>The implementation of Andersen's Alias Analysis has many known bugs.</li>
 </ul>
 
 </div>
@@ -368,11 +747,22 @@ components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/l
 <div class="doc_text">
 
 <ul>
-<li>The X86 backend does not yet support <a href="http://llvm.org/PR879">inline
-    assembly that uses the X86 floating point stack</a>.</li>
-<li>The X86 backend occasionally has <a href="http://llvm.org/PR1649">alignment
-    problems</a> on operating systems that don't require 16-byte stack alignment
-    (including most non-darwin OS's like linux).</li>
+  <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 the mingw64
+    runtime currently due
+    to <a href="http://llvm.org/PR2255">several</a>
+    <a href="http://llvm.org/PR2257">bugs</a> and due to lack of support for
+    the
+    'u' inline assembly constraint and for X87 floating point inline assembly.</li>
+  <li>The X86-64 backend does not yet support the LLVM IR instruction
+      <tt>va_arg</tt>. Currently, the llvm-gcc and front-ends support variadic
+      argument constructs on X86-64 by lowering them manually.</li>
 </ul>
 
 </div>
@@ -385,8 +775,6 @@ components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/l
 <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 Linux PPC32/ABI support needs testing for the interpreter and static
 compilation, and lacks support for debug information.</li>
 </ul>
@@ -401,13 +789,14 @@ compilation, and lacks support for debug information.</li>
 <div class="doc_text">
 
 <ul>
+<li>Support for the Advanced SIMD (Neon) instruction set is still incomplete
+and not well tested.  Some features may not work at all, and the code quality
+may be poor in some cases.</li>
 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
-processors, thumb program can crash or produces wrong
+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>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
 </li>
-<li>There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute
-programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 </ul>
 
 </div>
@@ -420,7 +809,7 @@ programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 <div class="doc_text">
 
 <ul>
-<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
+<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
     support the 64-bit SPARC ABI (-m64).</li>
 </ul>
 
@@ -428,48 +817,30 @@ programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="alpha-be">Known problems with the Alpha back-end</a>
+  <a name="mips-be">Known problems with the MIPS back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-
-<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
-appropriate nops inserted to ensure restartability.</li>
-
+<li>64-bit MIPS targets are not supported yet.</li>
 </ul>
+
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="ia64-be">Known problems with the IA64 back-end</a>
+  <a name="alpha-be">Known problems with the Alpha back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
 
-<li>C++ programs are likely to fail on IA64, as calls to <tt>setjmp</tt> are
-made where the argument is not 16-byte aligned, as required on IA64. (Strictly
-speaking this is not a bug in the IA64 back-end; it will also be encountered
-when building C++ programs using the C back-end.)</li>
-
-<li>The C++ front-end does not use <a href="http://llvm.org/PR406">IA64
-ABI compliant layout of v-tables</a>.  In particular, it just stores function
-pointers instead of function descriptors in the vtable.  This bug prevents
-mixing C++ code compiled with LLVM with C++ objects compiled by other C++
-compilers.</li>
-
-<li>There are a few ABI violations which will lead to problems when mixing LLVM
-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>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.</li>
 
-<li>The Itanium backend has bitrotted somewhat.</li>
 </ul>
-
 </div>
 
 <!-- ======================================================================= -->
@@ -480,15 +851,13 @@ programs.</li>
 <div class="doc_text">
 
 <ul>
-<li><a href="http://llvm.org/PR802">The C backend does not support inline
-    assembly code</a>.</li>
-<li><a href="http://llvm.org/PR1126">The C backend does not support vectors
-    yet</a>.</li>
-<li><a href="http://llvm.org/PR1126">The C backend does not support vectors
-    yet</a>.</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>
+    C++ code compiled with <tt>llc</tt> or native compilers.</li>
+<li>The C backend does not support all exception handling constructs.</li>
+<li>The C backend does not support arbitrary precision integers.</li>
 </ul>
 
 </div>
@@ -496,159 +865,105 @@ programs.</li>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="c-fe">Known problems with the C front-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-gcc4 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_subsubsection">
-  Notes
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="c++-fe">Known problems with the llvm-gcc C++ front-end</a>
 </div>
 
 <div class="doc_text">
-<ul>
-
-<li><p>"long double" is silently 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.</p></li>
-    
-<li><p>llvm-gcc does <b>not</b> support <tt>__builtin_apply</tt> yet.
-  See <a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</p>
-</li>
 
-<li><p>llvm-gcc <b>partially</b> supports these GCC extensions:</p>
-  <ol>
-  <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.<br>
-      Nested functions are supported, but llvm-gcc does not support non-local
-      gotos or taking the address of a nested function.</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>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>,
-      <tt>constructor</tt>, <tt>destructor</tt>,
-      <tt>deprecated</tt>, <tt>fastcall</tt>, <tt>format</tt>, 
-      <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>, <tt>noreturn</tt>, <tt>regparm</tt>
-      <tt>section</tt>, <tt>stdcall</tt>, <tt>unused</tt>, <tt>used</tt>, 
-      <tt>visibility</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
-
-      <b>Ignored:</b> <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
-      <tt>malloc</tt>, <tt>no_instrument_function</tt></li>
-  </ol>
-</li>
-
-<li><p>llvm-gcc supports the vast majority of GCC extensions, including:</p>
-
-  <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
-  <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/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
-      Other built-in functions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
-      Specifying attributes of variables.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>:  Specifying attributes of types.</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/Variable-Length.html#Variable%20Length">Variable Length</a>:
-      Arrays whose length is computed at run time.</li>
-  <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/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/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>
+<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>Exception handling works well on the X86 and PowerPC targets. Currently
+  only Linux and Darwin targets are supported (both 32 and 64 bit).</li>
 </ul>
 
-<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="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
 </div>
 
 <div class="doc_text">
+<ul>
+<li>Fortran support generally works, but there are still several unresolved bugs
+    in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
+    tools/gfortran component for details.</li>
+</ul>
+</div>
 
-<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>
+<!-- ======================================================================= -->
+<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>llvm-gcc4 only has partial support for <a href="http://llvm.org/PR870">C++ 
-Exception Handling</a>, and it is not enabled by default.</li>
-
-<!-- NO EH Support!
-
-<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-gcc3 is very
-    different from the model used in the Itanium ABI, so <b>exceptions will not
-    interact correctly</b>. </li>
--->
+<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>.
+This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
+exception handling, which is used internally by the compiler.
+Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
+<li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
+and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
+(c380004 also fails with gcc-4.2 mainline).
+If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
+causes the compiler to go into an infinite loop, using up all system memory.</li>
+<li>Some GCC specific Ada tests continue to crash the compiler.</li>
+<li>The <tt>-E</tt> 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 <tt>-E</tt>.</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_subsection">
+       <a name="ocaml-bindings">Known problems with the O'Caml bindings</a>
 </div>
 
+<div class="doc_text">
 
+<p>The <tt>Llvm.Linkage</tt> module is broken, and has incorrect values. Only
+<tt>Llvm.Linkage.External</tt>, <tt>Llvm.Linkage.Available_externally</tt>, and
+<tt>Llvm.Linkage.Link_once</tt> will be correct. If you need any of the other linkage
+modes, you'll have to write an external C library in order to expose the
+functionality. This has been fixed in the trunk.</p>
+</div>
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
@@ -677,9 +992,9 @@ lists</a>.</p>
 <hr>
 <address>
   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+  src="http://jigsaw.w3.org/css-validator/images/vcss-blue" 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-blue" alt="Valid HTML 4.01"></a>
 
   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$