<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>LLVM 2.1 brings two new beta C front-ends. First, a new version of llvm-gcc
+based on GCC 4.2, innovatively called "llvm-gcc-4.2". This promises to bring
+FORTRAN and Ada support to LLVM as well as features like atomic builtins and
+OpenMP. None of these actually work yet, but don't let that stop you checking
+it out!</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
making the code generator faster for vector code.</li>
<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>
+ target independent, so far only the ARM backend uses it.</li>
-<li>Evan rewrite the way the register allocator handles rematerialization,
+<li>Evan rewrote 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>
<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
+ the point where it "just works" on linux/X86-32 and has partial support on
other targets.</li>
<li>Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma
"restrict" pointer arguments to functions.</li>
<li>Duncan contributed support for trampolines (taking the address of a nested
- functions), currently this is only supported in the x86 target.</li>
+ function). Currently this is only supported on the X86-32 target.</li>
<li>Lauro Ramos Venancio contributed support to encode alignment info in
load and store instructions, the foundation for other alignment-related
<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>
<ul>
<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>
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/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>
<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/Nested-Functions.html#Nested%20Functions">Nested Functions</a>:
+
+ As in Algol and Pascal, lexical scoping of functions.
+ Nested functions are supported, but llvm-gcc does not support
+ taking the address of a nested function (except on the X86-32 target)
+ or non-local gotos.</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>,
+ <b>Supported:</b> <tt>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>,
+ <tt>const</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>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>,
+ <tt>noreturn</tt>, <tt>pure</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>
+ <b>Ignored:</b> <tt>nothrow</tt>, <tt>malloc</tt>,
+ <tt>no_instrument_function</tt></li>
</ol>
</li>
itself, Qt, Mozilla, etc.</p>
<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>
+<li>Exception handling only works well on the linux/X86-32 target.
+In some cases, illegally throwing an exception does not result
+in a call to terminate.</li>
<!-- NO EH Support!
projects / oota-llvm.git / blobdiff