[llvm-commits] CVS: llvm/docs/ReleaseNotes.html

Chris Lattner lattner at cs.uiuc.edu
Mon May 16 10:06:46 PDT 2005



Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.325 -> 1.326
---
Log message:

more edits


---
Diffs of the changes:  (+30 -29)

 ReleaseNotes.html |   59 +++++++++++++++++++++++++++---------------------------
 1 files changed, 30 insertions(+), 29 deletions(-)


Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.325 llvm/docs/ReleaseNotes.html:1.326
--- llvm/docs/ReleaseNotes.html:1.325	Mon May 16 11:56:09 2005
+++ llvm/docs/ReleaseNotes.html	Mon May 16 12:06:29 2005
@@ -625,12 +625,6 @@
 <li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
     front-end</a>.</li>
 
-<li><b>IA-64 specific</b>: The C++ front-end does not use <a 
-href="http://llvm.cs.uiuc.edu/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>
-
 </ul>
 
 </div>
@@ -672,27 +666,35 @@
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="x86-be">Known problems with the X86 back-end</a>
+  <a name="c-be">Known problems with the C back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-  <li>None yet</li>
+
+<li>The C back-end produces code that violates the ANSI C Type-Based Alias
+Analysis rules.  As such, special options may be necessary to compile the code
+(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
+problem probably cannot be fixed.</li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR56">Zero arg vararg functions are not 
+supported</a>.  This should not affect LLVM produced by the C or C++ 
+frontends.</li>
+
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="sparcv9-be">Known problems with the SparcV9 back-end</a>
+  <a name="x86-be">Known problems with the X86 back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li><a href="http://llvm.cs.uiuc.edu/PR60">[sparcv9] SparcV9 backend miscompiles
-several programs in the LLVM test suite</a></li>
+  <li>None yet</li>
 </ul>
 
 </div>
@@ -712,22 +714,14 @@
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="c-be">Known problems with the C back-end</a>
+  <a name="sparcv9-be">Known problems with the SparcV9 back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-
-<li>The C back-end produces code that violates the ANSI C Type-Based Alias
-Analysis rules.  As such, special options may be necessary to compile the code
-(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
-problem probably cannot be fixed.</li>
-
-<li><a href="http://llvm.cs.uiuc.edu/PR56">Zero arg vararg functions are not 
-supported</a>.  This should not affect LLVM produced by the C or C++ 
-frontends.</li>
-
+<li><a href="http://llvm.cs.uiuc.edu/PR60">[sparcv9] SparcV9 backend miscompiles
+several programs in the LLVM test suite</a></li>
 </ul>
 
 </div>
@@ -741,9 +735,10 @@
 
 <ul>
 
-<li>On 21164s, some rare FP arithmatic sequences which may trap do not have the appropriate nops inserted to ensure restartability.</li>
+<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.</li>
 
-<li>Vararg functions are not supported.</li>
+<li>Defining vararg functions is not supported (but calling them is ok).</li>
 
 <li>Due to the vararg problems, C++ exceptions do not work.  Small changes are required to the CFE (which break correctness in the exception handler) to compile the exception handling library (and thus the C++ standard library).</li>
 
@@ -765,11 +760,17 @@
 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>There are a few ABI violations which will lead to problems
-when mixing LLVM output with code built with other compilers,
-particularly for C++ and floating-point programs.</li>
+<li>The C++ front-end does not use <a href="http://llvm.cs.uiuc.edu/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>Vararg functions are not supported.</li>
+<li>Defining vararg functions is not supported (but calling them is ok).</li>
 
 </ul>
 
@@ -824,7 +825,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
 
   <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2005/05/16 16:56:09 $
+  Last modified: $Date: 2005/05/16 17:06:29 $
 </address>
 
 </body>






More information about the llvm-commits mailing list