more edits

<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>

<!-- ======================================================================= -->

<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>

<!-- ======================================================================= -->

<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>

<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>

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>