Fix bug: test/Regression/Analysis/DSGraph/2003-11-02-NodeCollapsing.ll
[oota-llvm.git] / docs / ReleaseNotes.html
index 48f0d6d2b62dc388736b0535f8726e52ff4841ee..4a760f3d3938810d8daa31cddec2aa38f1a533c7 100644 (file)
@@ -1,18 +1,19 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>LLVM 1.0 Release Notes</title></head>
+<html><head><title>LLVM 1.1 Release Notes</title></head>
 <body bgcolor=white>
 
 <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
-<tr><td>&nbsp; <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>LLVM 1.0 Release Notes</b></font></td>
+<tr><td>&nbsp; <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>LLVM 1.1 Release Notes</b></font></td>
 </tr></table>
  
 <ol>
-  <li><a href="#intro">Instroduction</a>
+  <li><a href="#intro">Introduction</a>
   <li><a href="#whatsnew">What's New?</a>
+  <li><a href="#portability">Portability and Supported Platforms</a>
   <li><a href="#install-instructions">Installation Instructions</a>
   <li><a href="#knownproblems">Known Problems</a>
   <ul>
-    <li><a href="#portability">Portability Problems</a>
+<!--    <li><a href="#portabilityprobs">Portability Problems</a> -->
     <li><a href="#core">Known problems with the LLVM Core</a>
     <li><a href="#c-fe">Known problems with the C Front-end</a>
     <li><a href="#c++-fe">Known problems with the C++ Front-end</a>
 <!-- *********************************************************************** -->
 
 This document contains the release notes for the LLVM compiler infrastructure,
-release 1.0.  The most up-to-date version of this document can be found on the
-<a href="http://llvm.cs.uiuc.edu/releases/1.0/ReleaseNotes.html">LLVM web
-site</a>.  Since this document may be updated after the release, it is best to
-read the copy hosted there.
-
+release 1.1.  Here we describe the status of LLVM, including any known problems,
+and bug fixes from the previous release.  The most up-to-date version of this
+document can be found on the <a
+href="http://llvm.cs.uiuc.edu/releases/1.1/">LLVM 1.1 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>
+
+For more information about LLVM, including information about potentially more
+current releases, please check out the <a href="http://llvm.cs.uiuc.edu">main
+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>
+
+Note that if you are reading this file from CVS, that this document applies to
+the <i>next</i> release, not the previous one.  To see the release notes for the
+previous release, see the <a href="http://llvm.cs.uiuc.edu/releases/">releases
+page</a>.<p>
 
 <!-- *********************************************************************** -->
 </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
@@ -48,23 +61,63 @@ read the copy hosted there.
 </b></font></td></tr></table><ul>
 <!-- *********************************************************************** -->
 
-This is the first public release of the LLVM compiler infrastructure.  As such,
-it is all new!  In particular, we are providing a stable C compiler, beta C++
-compiler, a C back-end, stable X86 and Sparc V9 static and JIT code generators,
-as well as a large suite of scalar and interprocedural optimizations.<p>
+This is the second public release of the LLVM compiler infrastructure.  This
+release implements the following new features:<p>
 
-TODO: Works on: SPEC CPU 2000<p>
-TODO: Works on: Olden/Ptrdist benchmarks
+<ol>
+<li>temp</li>
+<li>temp</li>
+<li>temp</li>
+</ol><p>
+
+In this release, the following Quality of Implementation issues were fixed:<p>
+
+<ol>
+<li><a href="http://llvm.cs.uiuc.edu/PR29">C++ front-end is not generating linkonce linkage type when it can</a></li>
+</ol><p>
+
+In this release, the following bugs in the previous release were fixed:<p>
+
+<ol>
+<li><a href="http://llvm.cs.uiuc.edu/PR57">[inliner] Inlining invoke with PHI in unwind target is broken</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR58">[linker] linkonce globals should link successfully to external globals</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR59">C++ frontend can crash when compiling virtual base classes</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR62">C backend fails on constant cast expr to ptr-to-anonymous struct</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR63">#ident is not recognized by C frontend</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR64">[constmerge] Constant merging pass merges constants with external linkage</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR65">C front-end miscompiles the builtin_expect intrinsic!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR66">[scalarrepl] Scalar Replacement of aggregates is decimating structures it shouldn't be</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR67">1.0 precompiled libstdc++ does not include wchar_t support</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR68">llvmgcc asserts when compiling functions renamed with asm's</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR69">C frontend crashes on some programs with lots of types.</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR70">[instcombine] Resolving invoke inserts cast after terminator</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR71">llvm-as crashes when labels are used in phi nodes</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR72">[build problem] Callgraph.cpp not pulled in from libipa.a</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR79">llvm-gcc crashes compiling global union initializer</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR80">C front-end crash on empty structure</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR81">CFrontend crashes when compiling C99 compound expressions</a></li>
+
+</ol><p>
+
+At this time, LLVM is known to work properly with SPEC CPU 2000, the Olden
+benchmarks, and the Ptrdist benchmarks among many other programs.  Note however
+that the Sparc and X86 backends do not currently support exception throwing or
+long jumping (including 253.perlbmk in SPEC).  For these programs you must use
+the C backend.<p>
 
 
 <!-- *********************************************************************** -->
 </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
 <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
-<a name="install-instructions">Installation Instructions
+<a name="portability">Portability and Supported Platforms
 </b></font></td></tr></table><ul>
 <!-- *********************************************************************** -->
 
-FIXME
+LLVM has only been extensively tested on Intel and AMD machines running Red
+Hat Linux, and Sun UltraSPARC workstations running Solaris 8.
+The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
+work on more platforms than that.  However, it is extremely likely that we
+missed something.  We welcome portability patches and error messages.<p>
 
 
 <!-- *********************************************************************** -->
@@ -76,18 +129,13 @@ FIXME
 
 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, so it is important to check the <a
-href="http://llvm.cs.uiuc.edu/releases/1.0/ReleaseNotes.html">web version</a> of
-this document for up-to-date information.
+sections.
 
 
 <!-- _______________________________________________________________________ -->
+<!--
 </ul><h4><a name="portability"><hr size=0>Portability Problems</h4><ul>
-
-LLVM has only been extensively tested on ia32-linux and sparc-solaris machines.
-The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
-work on more platforms than that.  However, it is extremely likely that we
-missed something.  We welcome portability patches and error messages.<p>
+-->
 
 
 <!-- _______________________________________________________________________ -->
@@ -101,16 +149,16 @@ missed something.  We welcome portability patches and error messages.<p>
 
 <li>It is not possible to <tt>dlopen</tt> an LLVM bytecode file in the JIT.<p>
 
-<li>Linking in static archive files (.a files) is very slow.
+<li>Linking in static archive files (.a files) is very slow (there is no symbol
+table in the archive).
 
 <!-- _______________________________________________________________________ -->
 </ul><h4><a name="c-fe"><hr size=0>Known problems with the C front-end</h4><ul>
 
-<li>Inline assembly is not yet supported.<p>
+</ul><b>Bugs:</b><ul><p>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR6">Oversized integer bitfields cause crash</a>.<p>
 
-<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.
-     <p>
 <li>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>
@@ -120,10 +168,19 @@ missed something.  We welcome portability patches and error messages.<p>
     }
 </pre><p>
 
-<li>The following unix system functionality has not been tested and may not work:
+</ul><b>Notes:</b><ul><p>
+
+<li>Inline assembly is not yet supported.<p>
+
+<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.
+    <p>
+
+<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.
+       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><p>
@@ -194,7 +251,7 @@ missed something.  We welcome portability patches and error messages.<p>
   <ol>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>:   Putting statements and declarations inside expressions. 
   <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><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>:   Using <code>?:</code>, <code>,</code> and casts in lvalues. 
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>:   Using <code>?:</code>, "<code>,</code>" and casts in lvalues. 
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression. 
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>:   Data types for complex numbers. 
@@ -233,48 +290,59 @@ missed something.  We welcome portability patches and error messages.<p>
 <!-- _______________________________________________________________________ -->
 </ul><h4><a name="c++-fe"><hr size=0>Known problems with the C++ front-end</h4><ul>
 
-For this release, the C++ front-end is considered to be of <b>beta</b> quality.
-It works for a large number of simple programs, but has not been extensively
-tested.  We welcome bug reports though!<p>
+For this release, the C++ front-end is considered to be fully functional but
+of <b>beta</b> quality.  It has been tested and works for a number of simple programs that collectively exercise most of the language.  Nevertheless, it has not been in use as long as the C front-end.  Please report any bugs or problems.<p>
+
+</ul><b>Bugs</b>:<ul><p>
 
 <li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
     front-end</a><p>
 
+</ul><b>Notes</b>:<ul><p>
+
 <li>The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser.  This
 parser is significantly more standards compliant (and picky) than prior GCC
 versions.  For more information, see the C++ section of the <a
 href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.<p>
 
 <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
+    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).<p> 
 
-<li>The calling conventions and name mangling used by the LLVM C++ front-end do
-    follow the <a href="http://www.codesourcery.com/cxx-abi">Itanium C++
-    ABI</a>, and thus we should be binary compatible with native C++ code
-    compiled with a recent GCC compiler.  However, the exception handling
-    mechanisms are very different, so they will not interact correctly.
+<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><a href="http://llvm.cs.uiuc.edu/PR11">Code for executing destructors when
+    unwinding is not shared</a> (this is a quality of implementation problem,
+    which does not effect functionality).<p>
+
 
 <!-- _______________________________________________________________________ -->
 </ul><h4><a name="x86-be"><hr size=0>Known problems with the X86 back-end</h4><ul>
 
-<li>The X86 code generator does not currently support the <tt>unwind</tt>
-instruction, so code that throws a C++ exception or calls the C <tt>longjmp</tt>
-function will abort.<p>
-
-<li>Some executables produced by LLC seem to intermittently crash (extremely
-infrequently).  The cause of the problem has not been diagnosed, and does not
-affect the JIT.<p>
+<li>The X86 code generator <a
+href="http://llvm.cs.uiuc.edu/PR16">does not currently
+support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+or calls the C <tt>longjmp</tt> function will abort.<p>
 
 
 <!-- _______________________________________________________________________ -->
 </ul><h4><a name="sparc-be"><hr size=0>Known problems with the Sparc back-end</h4><ul>
 
-<li>The Sparc code generator does not currently support the <tt>invoke</tt> or
-<tt>unwind</tt> instructions, so code produced by the C++ front-end and C code
-that calls the <tt>setjmp</tt> or <tt>longjmp</tt> functions will not compile.
+<li>The Sparc code generator <a
+href="http://llvm.cs.uiuc.edu/PR15">does not currently
+support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+or calls the C <tt>longjmp</tt> function will abort.<p>
 
 
 <!-- _______________________________________________________________________ -->
@@ -285,10 +353,12 @@ 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.<p>
 
-<li>Initializers for global variables that include floating point numbers may
-not be initialized with exactly the right floating point number, if the number
-is not accurately representable in decimal.  This prevents the Olden "power"
-benchmark from producing exactly the right results with the C backend.<p>
+<li><a href="http://llvm.cs.uiuc.edu/PR33">Initializers for global variables</a>
+cannot include special floating point numbers like Not-A-Number or Infinity.<p>
+
+<li><a href="http://zion.cs.uiuc.edu/PR56">Zero arg vararg functions are not 
+supported</a>.  This should not affect LLVM produced by the C or C++ 
+frontends.<p>
 
 <li>The code produces by the C back-end has only been tested with the Sun CC and
 GCC compilers.  It is possible that it will have to be adjusted to support other
@@ -308,7 +378,7 @@ including mailing lists publications describing algorithms and components
 implemented in LLVM.  The web page also contains versions of the API
 documentation which is up-to-date with the CVS version of the source code.  You
 can access versions of these documents specific to this release by going into
-the "<tt>llvm/www/doc/</tt>" directory in the LLVM tree.<p>
+the "<tt>llvm/doc/</tt>" directory in the LLVM tree.<p>
 
 If you have any questions or comments about LLVM, please feel free to contact us
 via the mailing lists.<p>
@@ -320,9 +390,9 @@ via the mailing lists.<p>
 
 <hr><font size-1>
 
-<address>By: <a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+Maintained By: <a href="http://llvm.cs.uiuc.edu/">The LLVM Team</a><br>
 <!-- Created: Wed Oct  1 17:38:54 CDT 2003 -->
 <!-- hhmts start -->
-Last modified: Thu Oct  2 00:06:58 CDT 2003
+Last modified: Sat Nov  1 20:14:25 CST 2003
 <!-- hhmts end -->
 </body></html>