X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FReleaseNotes.html;h=bdaba71b7430d341e663a0b1df71528fd743ff45;hb=256be96457faf173de2ac3f8145077b7e6fb41ba;hp=035dace224d2b47e80bac383de6ed5810d13dbf5;hpb=f795ef0cd4b19aeb9b527c94c99763ae717035ba;p=oota-llvm.git

diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index 035dace224d..bdaba71b743 100644
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -14,7 +14,7 @@
   <li><a href="#intro">Introduction</a></li>
   <li><a href="#subproj">Sub-project Status Update</a></li>
   <li><a href="#externalproj">External Projects Using LLVM 2.5</a></li>
-  <li><a href="#whatsnew">What's New in LLVM?</a></li>
+  <li><a href="#whatsnew">What's New in LLVM 2.5?</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>
@@ -58,12 +58,15 @@ current one.  To see the release notes for a specific release, please see the
   target-specific intrinsics
   gold lto plugin
   pre-alloc splitter, strong phi elim
-  llc -enable-value-prop, propagation of value info (sign/zero ext info) from
-       one MBB to another
+  <tt>llc -enable-value-prop</tt>, propagation of value info
+       (sign/zero ext info) from one MBB to another
   debug info for optimized code
   interpreter + libffi
   postalloc scheduler: anti dependence breaking, hazard recognizer?
 
+initial support for debug line numbers when optimization enabled, not useful in
+  2.5 but will be for 2.6.
+
  -->
 
  <!-- for announcement email:
@@ -78,11 +81,11 @@ current one.  To see the release notes for a specific release, please see the
 <div class="doc_text">
 <p>
 The LLVM 2.5 distribution currently consists of code from the core LLVM
-repository (which roughly includes the LLVM optimizers, 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 <a href="#clang">Clang Project</a> and
-the <a href="#vmkit">VMKit Project</a>.
+repository &mdash;which roughly includes the LLVM optimizers, code generators
+and supporting tools &mdash; 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 <a href="#clang">Clang
+Project</a> and the <a href="#vmkit">VMKit Project</a>.
 </p>
 
 </div>
@@ -96,18 +99,16 @@ the <a href="#vmkit">VMKit Project</a>.
 <div class="doc_text">
 
 <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.  While Clang is not included in the LLVM 2.5 release, it
-is continuing to make major strides forward in all areas.  Its C and Objective-C
+a set of new 'LLVM native' front-end technologies for the LLVM optimizer and
+code generator.  While Clang is not included in the LLVM 2.5 release, it is
+continuing to make major strides forward in all areas.  Its C and Objective-C
 parsing and code generation support is now very solid.  For example, it is
-capable of successfully building many real applications for X86-32 and X86-64,
-including <a href="http://wiki.freebsd.org/BuildingFreeBSDWithClang">the FreeBSD
-kernel</a>.  C++ is also making <a
-href="http://clang.llvm.org/cxx_status.html">incredible progress</a>, and work
-on templates has recently started.</p>
-
-<p>While Clang is not yet production quality, it is progressing very nicely and
-is quite usable for building many C and Objective-C applications.  If you are
+capable of successfully building many real-world applications for X86-32
+and X86-64,
+including the <a href="http://wiki.freebsd.org/BuildingFreeBSDWithClang">FreeBSD
+kernel</a> and <a href="http://gcc.gnu.org/gcc-4.2/">gcc 4.2</a>.  C++ is also
+making <a href="http://clang.llvm.org/cxx_status.html">incredible progress</a>,
+and work on templates has recently started.  If you are
 interested in fast compiles and good diagnostics, we encourage you to try it out
 by <a href="http://clang.llvm.org/get_started.html">building from mainline</a>
 and reporting any issues you hit to the <a
@@ -119,11 +120,17 @@ list</a>.</p>
 <ul>
 <li>Clang now has a new driver, which is focused on providing a GCC-compatible
     interface.</li>
-<li>The X86-64 ABI is now supported.</li>
+<li>The X86-64 ABI is now supported, including support for the Apple
+    64-bit Objective-C runtime and zero cost exception handling.</li>
 <li>Precompiled header support is now implemented.</li>
 <li>Objective-C support is significantly improved beyond LLVM 2.4, supporting
     many features, such as Objective-C Garbage Collection.</li>
-<li>Many many bugs are fixed.</li>
+<li>Variable length arrays are now fully supported.</li>
+<li>C99 designated initializers are now fully supported.</li>
+<li>Clang now includes all major compiler headers, including a
+    redesigned <i>tgmath.h</i> and several more intrinsic headers.</li>
+<li>Many many bugs are fixed and many features have been added.</li>
+</ul>
 </div>
 
 <!--=========================================================================-->
@@ -147,7 +154,7 @@ objects as well as an improved value-constraints subengine that does a much
 better job of reasoning about inequality relationships (e.g., <tt>x &gt; 2</tt>)
 between variables and constants.
 
-<p>The set of checks performed by the static analyzer continue to expand, and
+<p>The set of checks performed by the static analyzer continues to expand, and
 future plans for the tool include full source-level inter-procedural analysis
 and deeper checks such as buffer overrun detection. There are many opportunities
 to extend and enhance the static analyzer, and anyone interested in working on
@@ -166,15 +173,15 @@ The <a href="http://vmkit.llvm.org/">VMKit project</a> 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>Following LLVM 2.5, VMKit has its first release ? that you can find on its
+<p>Following LLVM 2.5, VMKit has its second release that you can find on its
 <a href="http://vmkit.llvm.org/releases/">webpage</a>. The release includes
 bug fixes, cleanup and new features. The major changes are:</p>
 
 <ul>
 
 <li>Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this
-functionality to native compile the standard classes (eg java.lang.String).
-Users can compile AOT .class files into dynamic libraries and run them with the
+functionality to native compile the standard classes (e.g. java.lang.String).
+Users can compile AoT .class files into dynamic libraries and run them with the
 help of VMKit.</li>
 
 <li>New exception model: the dwarf exception model is very slow for
@@ -184,7 +191,13 @@ a low performance penalty on applications without exceptions, but it is a big
 gain for exception-intensive applications. For example the jack benchmark in
 Spec JVM98 is 6x faster (performance gain of 83%).</li>
 
-<li>New support for OSX/X64, Linux/X64 (with the Boehm GC), Linux/ppc32.</li>
+<li>User-level management of thread stacks, so that thread local data access
+at runtime is fast and portable. </li>
+
+<li>Implementation of biased locking for faster object synchronizations at
+runtime.</li>
+
+<li>New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.</li>
 
 </ul>
 </div>
@@ -202,11 +215,8 @@ Spec JVM98 is 6x faster (performance gain of 83%).</li>
 
 <div class="doc_text">
 <p>
-http://pure-lang.googlecode.com/
-</p>
-
-<p>
-Pure is an algebraic/functional programming language based on term rewriting.
+<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),
@@ -231,16 +241,12 @@ it as a kind of functional scripting language for many application areas.
 
 <div class="doc_text">
 <p>
-http://www.dsource.org/projects/ldc
-</p>
-
-<p>
-I'd like to inform that the LDC project (LLVM D
-Compiler) is working with release 2.5 of LLVM. In fact we've required
-2.5 in our trunk since the release was branched.
-The improvements in 2.5 have fixed a lot of problems with LDC, more
-specifically the new inline asm constraints, better debug info
-support, general bugfixes :) and better x86-64 support have allowed
+<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.5 release.  General improvements in
+this
+cycle have included new inline asm constraint handling, better debug info
+support, general bugfixes, and better x86-64 support.  This has allowed
 some major improvements in LDC, getting us much closer to being as
 fully featured as the original DMD compiler from DigitalMars.
 </p>
@@ -252,17 +258,16 @@ fully featured as the original DMD compiler from DigitalMars.
 </div>
 
 <div class="doc_text">
-<p>http://code.roadsend.com/rphp</p>
-
-<p>Roadsend PHP is using LLVM for code generation. This is an open source
-project.
-</p>
+<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_section">
-  <a name="whatsnew">What's New in LLVM?</a>
+  <a name="whatsnew">What's New in LLVM 2.5?</a>
 </div>
 <!-- *********************************************************************** -->
 
@@ -284,73 +289,25 @@ in this section.
 <p>LLVM 2.5 includes several major new capabilities:</p>
 
 <ul>
-<li><p>The code generator now supports arbitrary precision integers.
-Types like <tt>i33</tt> have long been valid in the LLVM IR, but previously
-could only be used with the interpreter.
-Now IR using such types can be compiled to native code on all targets.
-All operations are supported if the integer is not bigger than twice the
-target machine word size.
-Simple operations like loads, stores and shifts by a constant amount are
-supported for integers of any size.
-</p></li>
-
-<!--
-Random stuff:
-
-Pure project: http://code.google.com/p/pure-lang/
-
-
-xcore backend!
-fortran on darwin!
-
-.ll parser rewrite, caret diags, better errors, less fragile (less likely to
-   crash on strange things).  No longer depends on flex/bison.
-GCC inliner off, llvm handles always-inline.
-cmake mature?
-x86 backend GS segment -> addr space 256 (r62980)
-nocapture
-addreadattrs pass renamed to functionattrs; now calculates nocapture
-memdep (used by GVN and memcpyopt) is faster / more aggressive.
-how to write a backend doc docs/WritingAnLLVMBackend.html
-fastisel + exception handling
-vector widening <3 x float> -> <4 x float>
-arm port improvements? arm jit encoding stuff, constant island support?
-JIT TLS support on x86-32 but not x86-64.
-mem2reg now faster on code with huge basic blocks
-stack protectors/stack canaries, -fstack-protector, controllable on a
-  per-function basis with attributes.
-shufflevector is generalized to allow different shuffle mask width than its
-  input vectors.
-loop optimizer improves floating point induction variables
-llvm/Analysis/DebugInfo.h classes, llvm-gcc and clang and codegen use them.
-    DebugInfoBuilder gone.
-asmprinters seperate from targets for jits
-PBQP register allocator now supports register coalescing.
-JIT supports exceptions on linux/x86-64 and linux/x86-64.
-integer overflow intrinsics for [us](add/sub/mul).  Supported on all targets,
-  but only generates efficient code on x86.
-X86 backend now supports -disable-mmx.
-noalias attribute on return value indicates that function returns new memory
-  (e.g. malloc).
-Jump threading more powerful: it is iterative, handles threading based on values
-  with fully redundant and partially redundant loads.
-LSR improvements?
-ARM debug info support?
-unit test framework based on Google Test.
-
-vector shift support + X86 backend.
-x86 JIT now detects core i7 and atom, autoconfiguring itself appropriately.
-SROA is more aggressive about promoting unions.
-non-zero __builtin_return_address values on X86.
-x86-64 now uses red zone (unless -mno-red-zone option is specified).
-private linkage.
-
-llvm-gcc defaults to -fno-math-errno on all x86 targets.
+<li>LLVM 2.5 includes a brand new <a
+href="http://en.wikipedia.org/wiki/XCore">XCore</a> backend.</li>
 
-initial support for debug line numbers when optimization enabled, not useful in
-  2.5 but will be for 2.6.
--->
+<li>llvm-gcc now generally supports the GFortran front-end, and the precompiled
+release binaries now support Fortran, even on Mac OS/X.</li>
+
+<li>CMake is now used by the <a href="GettingStartedVS.html">LLVM build process
+on Windows</a>.  It automatically generates Visual Studio project files (and
+more) from a set of simple text files.  This makes it much easier to
+maintain.  In time, we'd like to standardize on CMake for everything.</li>
+
+<li>LLVM 2.5 now uses (and includes) Google Test for unit testing.</li>
 
+<li>The LLVM native code generator now supports arbitrary precision integers.
+Types like <tt>i33</tt> have long been valid in the LLVM IR, but were previously
+only supported by the interpreter.  Note that the C backend still does not
+support these.</li>
+
+<li>LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.</li>
 </ul>
 
 </div>
@@ -368,7 +325,18 @@ front-ends and driver with the LLVM optimizer and code generator.  It currently
 includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
 
 <ul>
-<li>?</li>
+<li>In this release, the GCC inliner is completely disabled.  Previously the GCC
+inliner was used to handle always-inline functions and other cases.  This caused
+problems with code size growth, and it is completely disabled in this
+release.</li>
+
+<li>llvm-gcc (and LLVM in general) now support code generation for stack
+canaries, which is an effective form of <a
+href="http://en.wikipedia.org/wiki/Stack-smashing_protection">buffer overflow
+protection</a>.  llvm-gcc supports this with the <tt>-fstack-protector</tt>
+command line option (just like GCC).  In LLVM IR, you can request code
+generation for stack canaries with function attributes.
+</li>
 </ul>
 
 </div>
@@ -376,14 +344,55 @@ includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="coreimprovements">LLVM Core Improvements</a>
+<a name="coreimprovements">LLVM IR and Core Improvements</a>
 </div>
 
 <div class="doc_text">
-<p>New features include:</p>
+<p>LLVM IR has several new features that are used by our existing front-ends and
+can be useful if you are writing a front-end for LLVM:</p>
 
 <ul>
-<li>?</li>
+<li>The <a href="LangRef.html#i_shufflevector">shufflevector</a> instruction 
+has been generalized to allow different shuffle mask width than its input
+vectors.  This allows you to use shufflevector to combine two
+"&lt;4 x float&gt;" vectors into a "&lt;8 x float&gt;" for example.</li>
+
+<li>LLVM IR now supports new intrinsics for computing and acting on <a 
+href="LangRef.html#int_overflow">overflow of integer operations</a>. This allows
+efficient code generation for languages that must trap or throw an exception on
+overflow.  While these intrinsics work on all targets, they only generate
+efficient code on X86 so far.</li>
+
+<li>LLVM IR now supports a new <a href="LangRef.html#linkage">private
+linkage</a> type to produce labels that are stripped by the assembler before it
+produces a .o file (thus they are invisible to the linker).</li>
+
+<li>LLVM IR supports two new attributes for better alias analysis.  The <a
+href="LangRef.html#paramattrs">noalias</a> attribute can now be used on the
+return value of a function to indicate that it returns new memory (e.g.
+'malloc', 'calloc', etc).
+The new <a href="LangRef.html#paramattrs">nocapture</a> attribute can be used
+on pointer arguments to indicate that the function does not return the pointer,
+store it in an object that outlives the call, or let the value of the pointer
+escape from the function in any other way.
+Note that it is the pointer itself that must not escape, not the value it
+points to: loading a value out of the pointer is perfectly fine.
+Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
+<!-- The simplifylibcalls pass applies these attributes to standard libc functions. -->
+</li>
+
+<li>The parser for ".ll" files in lib/AsmParser is now completely rewritten as a
+recursive descent parser.  This parser produces better error messages (including
+caret diagnostics), is less fragile (less likely to crash on strange things),
+does not leak memory, is more efficient, and eliminates LLVM's last use of the
+'bison' tool.</li>
+
+<li>Debug information representation and manipulation internals have been
+    consolidated to use a new set of classes in
+    <tt>llvm/Analysis/DebugInfo.h</tt>.  These routines are more
+    efficient, robust, and extensible and replace the older mechanisms.
+    llvm-gcc, clang, and the code generator now use them to create and process
+    debug information.</li>
 
 </ul>
 
@@ -396,12 +405,26 @@ includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
 
 <div class="doc_text">
 
-<p>In addition to a huge array of bug fixes and minor performance tweaks, this
+<p>In addition to a large array of bug fixes and minor performance tweaks, this
 release includes a few major enhancements and additions to the optimizers:</p>
 
 <ul>
 
-<li>?</li>
+<li>The loop optimizer now improves floating point induction variables in
+several ways, including adding shadow induction variables to avoid
+"integer &lt;-&gt; floating point" conversions in loops when safe.</li>
+
+<li>The "-mem2reg" pass is now much faster on code with large basic blocks.</li>
+
+<li>The "-jump-threading" pass is more powerful: it is iterative
+  and handles threading based on values with fully and partially redundant
+  loads.</li>
+
+<li>The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is
+    both faster and more aggressive.</li>
+
+<li>The "-scalarrepl" scalar replacement of aggregates pass is more aggressive
+    about promoting unions to registers.</li>
 
 </ul>
 
@@ -409,7 +432,7 @@ release includes a few major enhancements and additions to the optimizers:</p>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="codegen">Code Generator Improvements</a>
+<a name="codegen">Target Independent Code Generator Improvements</a>
 </div>
 
 <div class="doc_text">
@@ -419,21 +442,80 @@ infrastructure, which allows us to implement more aggressive algorithms and make
 it run faster:</p>
 
 <ul>
-<li>The type legalization logic has been completely rewritten, and is now
-more powerful (it supports arbitrary precision integer types for example)
-and hopefully more correct.
-The type legalizer converts operations on types that are not natively
-supported by the target machine into equivalent code sequences that only use
-natively supported types.
-The old type legalizer is still available and will be used if
-<tt>-disable-legalize-types</tt> is passed to <tt>llc</tt>.
+<li>The <a href="WritingAnLLVMBackend.html">Writing an LLVM Compiler
+Backend</a> document has been greatly expanded and is substantially more
+complete.</li>
+
+<li>The SelectionDAG type legalization logic has been completely rewritten, is
+now more powerful (it supports arbitrary precision integer types for example),
+and is more correct in several corner cases.  The type legalizer converts
+operations on types that are not natively supported by the target machine into
+equivalent code sequences that only use natively supported types.  The old type
+legalizer is still available (for now) and will be used if
+<tt>-disable-legalize-types</tt> is passed to the code generator.
 </li>
-<li>?</li>
 
+<li>The code generator now supports widening illegal vectors to larger legal
+ones (for example, converting operations on &lt;3 x float&gt; to work on
+&lt;4 x float&gt;) which is very important for common graphics
+applications.</li>
+
+<li>The assembly printers for each target are now split out into their own
+libraries that are separate from the main code generation logic.  This reduces
+the code size of JIT compilers by not requiring them to be linked in.</li>
+
+<li>The 'fast' instruction selection path (used at -O0 and for fast JIT
+    compilers) now supports accelerating codegen for code that uses exception
+    handling constructs.</li>
+    
+<li>The optional PBQP register allocator now supports register coalescing.</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>The <tt><a href="LangRef.html#int_returnaddress">llvm.returnaddress</a></tt>
+intrinsic (which is used to implement <tt>__builtin_return_address</tt>) now
+supports non-zero stack depths on X86.</li>
+
+<li>The X86 backend now supports code generation of vector shift operations
+using SSE instructions.</li>
+
+<li>X86-64 code generation now takes advantage of red zone, unless the
+<tt>-mno-red-zone</tt> option is specified.</li>
+
+<li>The X86 backend now supports using address space #256 in LLVM IR as a way of
+performing memory references off the GS segment register.  This allows a
+front-end to take advantage of very low-level programming techniques when
+targeting X86 CPUs. See <tt>test/CodeGen/X86/movgs.ll</tt> for a simple
+example.</li>
+
+<li>The X86 backend now supports a <tt>-disable-mmx</tt> command line option to
+  prevent use of MMX even on chips that support it.  This is important for cases
+  where code does not contain the proper <tt>llvm.x86.mmx.emms</tt>
+  intrinsics.</li>
+
+<li>The X86 JIT now detects the new Intel <a 
+   href="http://en.wikipedia.org/wiki/Intel_Core_i7">Core i7</a> and <a
+   href="http://en.wikipedia.org/wiki/Intel_Atom">Atom</a> chips and
+    auto-configures itself appropriately for the features of these chips.</li>
+    
+<li>The JIT now supports exception handling constructs on Linux/X86-64 and
+    Darwin/x86-64.</li>
+
+<li>The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on
+    X86-64.</li>
+</ul>
+
+</div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
@@ -450,41 +532,25 @@ The old type legalizer is still available and will be used if
 types.</li>
 <li>Function calls involving basic types work now.</li>
 <li>Support for integer arrays.</li>
-<li>Compiler can now emit libcalls for operations not support by m/c insns.</li>
-<li>Support for both data and rom address spaces.</li>
-</li>
+<li>The compiler can now emit libcalls for operations not supported by m/c
+instructions.</li>
+<li>Support for both data and ROM address spaces.</li>
 </ul>
 
 <p>Things not yet supported:</p>
 
 <ul>
 <li>Floating point.</li>
-<li>Passing/returning aggregate types to/from functions.</li>
+<li>Passing/returning aggregate types to and from functions.</li>
 <li>Variable arguments.</li>
 <li>Indirect function calls.</li>
-<li>Interrupts/prgrams.</li>
+<li>Interrupts/programs.</li>
 <li>Debug info.</li>
-</li>
 </ul>
 
 </div>
 
 
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="othertargetspecific">Other Target Specific Improvements</a>
-</div>
-
-<div class="doc_text">
-<p>New target-specific features include:
-</p>
-
-<ul>
-<li>?</li>
-</ul>
-
-</div>
-
 <!--=========================================================================-->
 <div class="doc_subsection">
 <a name="llvmc">Improvements in LLVMC</a>
@@ -501,18 +567,18 @@ types.</li>
  by default. The command <tt>llvmc --clang</tt> can be now used as a
  synonym to <tt>ccc</tt>.</li>
 
-<li>There is now a <tt>--check-graph</tt> option which is supposed to catch
+<li>There is now a <tt>--check-graph</tt> option, which is supposed to catch
  common errors like multiple default edges, mismatched output/input language
  names and cycles. In general, these checks can't be done at compile-time
  because of the need to support plugins.</li>
 
 <li>Plugins are now more flexible and can refer to compilation graph nodes and
  options defined in other plugins. To manage dependencies, a priority-sorting
- mechanism was introduced. This change affects the TableGen file syntax; see the
+ mechanism was introduced. This change affects the TableGen file syntax. See the
  documentation for details.</li>
 
 <li>Hooks can now be provided with arguments. The syntax is "<tt>$CALL(MyHook,
- 'Arg1', 'Arg2', 'Arg #3')</tt>".</li>
+ 'Arg1', 'Arg2', 'Arg3')</tt>".</li>
 
 <li>A new option type: multi-valued option, for options that take more than one
  argument (for example, "<tt>-foo a b c</tt>").</li>
@@ -531,22 +597,6 @@ types.</li>
 </div>
 
 
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="otherimprovements">Other Improvements</a>
-</div>
-
-<div class="doc_text">
-<p>New features include:
-</p>
-
-<ul>
-<li>?</li>
-
-</ul>
-
-</div>
-
 <!--=========================================================================-->
 <div class="doc_subsection">
 <a name="changes">Major Changes and Removed Features</a>
@@ -560,7 +610,8 @@ from the previous release.</p>
 
 <ul>
 
-<li>?</li>
+<li>llvm-gcc defaults to <tt>-fno-math-errno</tt> on all X86 targets.</li>
+
 </ul>
 
 
@@ -568,10 +619,8 @@ from the previous release.</p>
 API changes are:</p>
 
 <ul>
-<li>?</li>
-</ul>
-
-<li>?</li>
+<li>Some deprecated interfaces to create <tt>Instruction</tt> subclasses, that
+    were spelled with lower case "create," have been removed.</li>
 </ul>
 
 </div>
@@ -639,8 +688,8 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 
 <ul>
 <li>The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.</li>
-<li>The llc "<tt>-filetype=asm</tt>" (the default) is the only supported
-    value for this option.</li>
+<li>The <tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
+    supported value for this option.</li>
 </ul>
 
 </div>
@@ -660,13 +709,14 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
   <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
+    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> due to lack of support for the
-    'u' inline assembly constraint and X87 floating point inline assembly.</li>
+    <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 front-end supports variadic
+      <tt>va_arg</tt>. Currently, the llvm-gcc and front-ends support variadic
       argument constructs on X86-64 by lowering them manually.</li>
 </ul>
 
@@ -697,7 +747,7 @@ compilation, and lacks support for debug information.</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>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
@@ -714,7 +764,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>
 
@@ -757,7 +807,7 @@ appropriate nops inserted to ensure restartability.</li>
 <div class="doc_text">
 
 <ul>
-<li>The Itanium backend is highly experimental, and has a number of known
+<li>The Itanium backend is highly experimental and has a number of known
     issues.  We are looking for a maintainer for the Itanium backend.  If you
     are interested, please contact the LLVMdev mailing list.</li>
 </ul>
@@ -776,7 +826,7 @@ appropriate nops inserted to ensure restartability.</li>
     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>
@@ -833,9 +883,6 @@ itself, Qt, Mozilla, etc.</p>
 <ul>
 <li>Fortran support generally works, but there are still several unresolved bugs
     in Bugzilla.  Please see the tools/gfortran component for details.</li>
-
-<li>The Fortran front-end currently does not build on Darwin (without tweaks)
-    due to unresolved dependencies on the C front-end.</li>
 </ul>
 </div>
 
@@ -845,12 +892,12 @@ itself, Qt, Mozilla, etc.</p>
 </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.
+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>
+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
@@ -861,7 +908,7 @@ 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>Some GCC specific Ada tests continue to crash the compiler.</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>