From b46eff6362e3c9eeaac9860cfef08fbf77d2b598 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Fri, 18 May 2007 06:39:06 +0000 Subject: [PATCH] first cut of llvm 2.0 release notes git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_20@37220 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ReleaseNotes.html | 643 ++++++++++++++++++++++++++--------------- 1 file changed, 406 insertions(+), 237 deletions(-) diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 279a17906ce..abf2582c2f4 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -4,11 +4,11 @@ - LLVM 1.9 Release Notes + LLVM 2.0 Release Notes -
LLVM 1.9 Release Notes
+
LLVM 2.0 Release Notes
  1. Introduction
    2. @@ -32,13 +32,10 @@

    This document contains the release notes for the LLVM compiler -infrastructure, release 1.9. Here we describe the status of LLVM, including any -known problems and major improvements from the previous release. The most -up-to-date version of this document (corresponding to LLVM CVS) can be found -on the LLVM releases web site. 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.

    +infrastructure, release 2.0. Here we describe the status of LLVM, including any +known problems and major improvements from the previous release. All LLVM +releases may be downloaded from the LLVM +releases web site.

    For more information about LLVM, including information about the latest release, please check out the main LLVM @@ -61,67 +58,175 @@

    -

    This is the tenth public release of the LLVM Compiler Infrastructure. This -release incorporates a large number of enhancements, new features, and bug -fixes. We recommend that all users of previous LLVM versions upgrade. -

    +

    This is the eleventh public release of the LLVM Compiler Infrastructure. +Being the first major release since 1.0, this release is different in several +ways from our previous releases:

    + +
      +
    1. We took this as an opportunity to +break backwards compatibility with the LLVM 1.x bytecode and .ll file format. +If you have LLVM 1.9 .ll files that you would like to upgrade to LLVM 2.x, we +recommend the use of the stand alone llvm-upgrade +tool (which is included with 2.0). We intend to keep compatibility with .ll +and .bc formats within the 2.x release series, like we did within the 1.x +series.
      2. +
    2. There are several significant change to the LLVM IR and internal APIs, such + as a major overhaul of the type system, the completely new bitcode file + format, etc (described below).
      3. +
    3. We designed the release around a 6 month release cycle instead of the usual + 3-month cycle. This gave us extra time to develop and test some of the + more invasive features in this release.
      4. +
    4. LLVM 2.0 no longer supports the llvm-gcc3 front-end. Users are required to + upgrade to llvm-gcc4. llvm-gcc4 includes many features over + llvm-gcc3, is faster, and is much easier to + build from source.
      5. +
    + +

    Note that while this is a major version bump, this release has been + extensively tested on a wide range of software. It is easy to say that this + is our best release yet, in terms of both features and correctness. This is + the first LLVM release to correctly compile and optimize major software like + LLVM itself, Mozilla/Seamonkey, Qt 4.3rc1, kOffice, etc out of the box on + linux/x86. +

    -New Features in LLVM 1.9 +New Features in LLVM 2.0
    -
    New X86-64 Backend
    +
    Major Changes
    -

    LLVM 1.9 now fully supports the x86-64 instruction set on Mac OS/X, and -supports it on Linux (and other operating systems) when compiling in -static -mode. LLVM includes JIT support for X86-64, and supports both Intel EMT-64T -and AMD-64 architectures. The X86-64 instruction set permits addressing a -64-bit addressing space and provides the compiler with twice the -number of integer registers to use.

    -
    - -
    Link-Time Optimization integration -with native linkers
    -
    -

    LLVM now includes liblto which can -be used to integrate LLVM Link-Time Optimization support into a native linker. -This allows LLVM .bc to transparently participate with linking an application, -even when some .o files are in LLVM form and some are not.

    +

    Changes to the LLVM IR itself:

    + +
      + +
    • Integer types are now completely signless. This means that we + have types like i8/i16/i32 instead of ubyte/sbyte/short/ushort/int + etc. LLVM operations that depend on sign have been split up into + separate instructions (PR950). This + eliminates cast instructions that just change the sign of the operands (e.g. + int -> uint), which reduces the size of the IR and makes optimizers + simpler to write.
      • + +
    • Integer types with arbitrary bitwidths (e.g. i13, i36, i42, i1057, etc) are + now supported in the LLVM IR and optimizations (PR1043). However, neither llvm-gcc + (PR1284) nor the native code generators + (PR1270) support non-standard width + integers yet.
      • + +
    • 'Type planes' have been removed (PR411). + It is no longer possible to have two values with the same name in the + same symbol table. This simplifies LLVM internals, allowing significant + speedups.
      • + +
    • Global variables and functions in .ll files are now prefixed with + @ instead of % (PR645).
      • + +
    • The LLVM 1.x "bytecode" format has been replaced with a + completely new binary representation, named 'bitcode'. The Bitcode Format brings a + number of advantages to the LLVM over the old bytecode format: it is denser + (files are smaller), more extensible, requires less memory to read, + is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc + files), and has many other nice features.
      • + +
    • Load and store instructions now track the alignment of their pointer + (PR400). This allows the IR to + express loads that are not sufficiently aligned (e.g. due to '#pragma + packed') or to capture extra alignment information.
      • +
    + +

    Major new features:

    + +
      + +
    • A number of ELF features are now supported by LLVM, including 'visibility', + extern weak linkage, Thread Local Storage (TLS) with the __thread + keyword, and symbol aliases. + Among other things, this means that many of the special options needed to + configure llvm-gcc on linux are no longer needed, and special hacks to build + large C++ libraries like Qt are not needed.
      • + +
    • LLVM now has a new MSIL backend. llc -march=msil will now turn LLVM + into MSIL (".net") bytecode. This is still fairly early development + with a number of limitations.
      • + +
    • A new llvm-upgrade tool + exists to migrates LLVM 1.9 .ll files to LLVM 2.0 syntax.
      • +
    +
    + -
    DWARF debugging -support for Linux, Cygwin and MinGW on X86
    +
    llvm-gcc +Improvements
    -

    llvm-gcc4 now supports generating debugging info for Linux, Cygwin and MinGW. -This extends the PPC/Darwin and X86/Darwin debugging support available in the -1.8 release. DWARF is a standard debugging format used on many platforms.

    +

    New features include: +

    + +
      +
    • Precompiled Headers (PCH) are now supported.
      • + +
    • "#pragma packed" is now supported, as are the various features + described above (visibility, extern weak linkage, __thread, aliases, + etc).
      • + +
    • Tracking function parameter/result attributes is now possible.
      • + +
    • Many internal enhancements have been added, such as improvements to + NON_LVALUE_EXPR, arrays with non-zero base, structs with variable sized + fields, VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, nested functions, and many other + things. This is primarily to supports non-C GCC front-ends, like Ada.
      • + +
    • It is simpler to configure llvm-gcc for linux.
      • + +
    +
    Optimizer Improvements
    +
    -

    The mid-level optimizer is now faster and produces better code in many cases. - Significant changes include:

    +

    New features include: +

      -
    • LLVM includes a new 'predicate simplifier' pass, which - currently performs dominator tree-based optimizations.
      • -
    • The complete loop unroll pass now supports unrolling of - multiple basic block loops.
      • -
    • The 'globalopt' pass can now perform the scalar replacement of - aggregates transformation on some heap allocations.
      • -
    • The globalsmodref-aa alias analysis can now track 'indirect pointer - globals' more accurately.
      • -
    • The instruction combiner can now perform element propagation -analysis of vector expressions, eliminating computation of vector elements -that are not used.
      • +
    • The pass manager has been entirely + rewritten, making it significantly smaller, simpler, and more extensible. + Support has been added to run FunctionPasses interlaced with + CallGraphSCCPasses, and we now support loop transformations explicitly with + LoopPass.
      • + +
    • The -scalarrepl pass can now promote unions containing FP values + into a register, it can also handle unions of vectors of the same + size.
      • + +
    • LLVM 2.0 includes a new loop rotation pass, which converts "for loops" into + "do/while loops", where the condition is at the bottom of the loop.
      • + +
    • The Loop Strength Reduction pass has been improved, and support added + for sinking expressions across blocks to reduce register pressure.
      • + +
    • ModulePasses may now use the result of FunctionPasses.
      • + +
    • The [Post]DominatorSet classes have been removed from LLVM and clients + switched to use the far-more-efficient ETForest class instead.
      • + +
    • The ImmediateDominator class has also been removed, and clients have been + switched to use DominatorTree instead.
      • + +
    • The predicate simplifier pass has been improved, making it able to do + simple value range propagation and eliminate more conditionals.
      • +
    @@ -132,96 +237,229 @@

    -The LLVM Target-Independent code generator now supports more target features and -optimizes many cases more aggressively. New features include: +New features include:

      -
    • LLVM now includes a late branch folding pass which optimizes code - layout, performs several branch optzns, and deletes unreachable code.
      • -
    • The code generator now support targets that have pre/post-increment - addressing modes.
      • -
    • LLVM now supports dynamically-loadable register allocators and - schedulers.
      • -
    • LLVM 1.9 includes several improvements to inline asm support, - including support for new constraints and modifiers.
      • -
    • The register coalescer is now more aggressive than before, - allowing it to eliminate more copies.
      • + +
    • Support was added for software floating point, which allows LLVM to target + chips that don't have hardware FPUs (e.g. ARM thumb mode).
      • + +
    • A new register scavenger has been implemented, which is useful for + finding free registers after register allocation. This is useful when + rewriting frame references on RISC targets, for example.
      • + +
    • Heuristics have been added to avoid coalescing vregs with very large live + ranges to physregs. This was bad because it effectively pinned the physical + register for the entire lifetime of the virtual register (PR711).
      • + +
    • Support now exists for very simple (but still very useful) + rematerialization the register allocator, enough to move + instructions like "load immediate" and constant pool loads.
      • + +
    • Switch statement lowering is significantly better, improving codegen for + sparse switches that have dense subregions, and implemented support + for the shift/and trick.
      • + +
    • Added support for tracking physreg sub-registers and super-registers + in the code generator, as well as extensive register + allocator changes to track them.
      • + +
    • There is initial support for virtreg sub-registers + (PR1350).
      • + +
    + +

    +Other improvements include: +

    + +
      + +
    • Inline assembly support is much more solid that before. + The two primary features still missing are support for 80-bit floating point + stack registers on X86 (PR879), and + support for inline asm in the C backend (PR802).
      • + +
    • DWARF debug information generation has been improved. LLVM now passes + most of the GDB testsuite on MacOS and debug info is more dense.
      • + +
    • Codegen support for Zero-cost DWARF exception handling has been added (PR592). It is mostly + complete and just in need of continued bug fixes and optimizations at + this point. However, support in llvm-g++ is disabled with an + #ifdef for the 2.0 release (PR870).
      • + +
    • The code generator now has more accurate and general hooks for + describing addressing modes ("isLegalAddressingMode") to + optimizations like loop strength reduction and code sinking.
      • + +
    • Progress has been made on a direct Mach-o .o file writer. Many small + apps work, but it is still not quite complete.
      • +

    In addition, the LLVM target description format has itself been extended in several ways:

      -
    • tblgen now allows definition of 'multiclasses' which can be - used to factor instruction patterns more aggressively in .td files.
      • -
    • LLVM has a new TargetAsmInfo class which captures a variety of - information about the target assembly language format.
      • -
    • .td files now support "${:foo}" syntax for encoding - subtarget-specific assembler syntax into instruction descriptions.
      • +
    • Extended TargetData to support better target parameterization in + the .ll/.bc files, eliminating the 'pointersize/endianness' attributes + in the files (PR761).
      • + +
    • TargetData was generalized for finer grained alignment handling, + handling of vector alignment, and handling of preferred alignment
      • + +
    • LLVM now supports describing target calling conventions + explicitly in .td files, reducing the amount of C++ code that needs + to be written for a port.
      • + +
    + +
    + + +
    Target-Specific +Improvements
    + +
    + +

    X86-specific Code Generator Enhancements: +

    + +
      +
    • The MMX instruction set is now supported through intrinsics.
      • +
    • The scheduler was improved to better reduce register pressure on + X86 and other targets that are register pressure sensitive.
      • +
    • Linux/x86-64 support is much better.
      • +
    • PIC support for linux/x86 has been added.
      • +
    • The X86 backend now supports the GCC regparm attribute.
      • +
    • LLVM now supports inline asm with multiple constraint letters per operand + (like "ri") which is common in X86 inline asms.
    -

    Further, several significant target-specific enhancements are included in -LLVM 1.9:

    +

    ARM-specific Code Generator Enhancements:

      -
    • The LLVM ARM backend now supports more instructions - and the use of a frame pointer. It is now possible to build - libgcc and a simple cross compiler, but it is not considered "complete" yet. -
      • -
    • LLVM supports the Win32 dllimport/dllexport linkage and - stdcall/fastcall calling conventions.
      • +
    • The ARM code generator is now stable and fully supported.
      • + +
    • There are major new features, including support for ARM + v4-v6 chips, vfp support, soft float point support, pre/postinc support, + load/store multiple generation, constant pool entry motion (to support + large functions), and inline asm support, weak linkage support, static + ctor/dtor support and many bug fixes.
      • +
    • Added support for Thumb code generation (llc -march=thumb).
      • + +
    • The ARM backend now supports the ARM AAPCS/EABI ABI and PIC codegen on + arm/linux.
      • + +
    • Several bugs were fixed for DWARF debug info generation on arm/linux.
      • +
    + +

    PowerPC-specific Code Generator Enhancements:

    + +
      +
    • The PowerPC 64 JIT now supports addressing code loaded above the 2G + boundary.
      • + +
    • Improved support for the Linux/ppc ABI and the linux/ppc JIT is fully + functional now. llvm-gcc and static compilation are not fully supported + yet though.
      • + +
    • Many PowerPC 64 bug fixes.
      • +
    +
    Other Improvements
    -

    This release includes many other improvements, including improvements to - the optimizers and code generators (improving the generated code) changes to - speed up the compiler in many ways (improving algorithms and fine tuning - code), and changes to reduce the code size of the compiler itself.

    More specific changes include:

      -
    • The llvm-test framework now supports SPEC2006.
      • -
    • LLVM now includes a FAQ about the -getelementptr instruction.
      • -
    • Bugpoint now supports a new "-find-bugs" mode. This mode makes - bugpoint permute pass sequences to try to expose bugs due to pass - sequencing.
      • -
    • The JIT now supports lazily streaming code from multiple modules at a - time, implicitly linking the code as it goes.
      • -
    -
    +
  2. LLVM no longer relies on static destructors to shut itself down. Instead, + it lazily initializes itself and shuts down when llvm_shutdown() is + explicitly called.
    3. - -
    -Significant API Changes in LLVM 1.9 +
  3. LLVM now has significantly fewer static constructors, reducing startup time. +
    4. + +
  4. Several classes have been refactored to reduce the amount of code that + gets linked into apps that use the JIT.
    5. + +
  5. Construction of intrinsic function declarations has been simplified.
    6. + +
  6. The gccas/gccld tools have been replaced with small shell scripts.
    7. + +
  7. Support has been added to llvm-test for running on low-memory + or slow machines (make SMALL_PROBLEM_SIZE=1).
    8. + +
    + +
    API Changes
    -

    Several significant API changes have been made. If you are maintaining -out-of-tree code, please be aware that:

    +

    LLVM 2.0 contains a revamp of the type system and several other significant +internal changes. If you are programming to the C++ API, be aware of the +following major changes:

      -
    • The ConstantSInt and ConstantUInt classes have been merged into the - ConstantInt class.
      • -

    • As a step towards making LLVM's integer types signless, several new -instructions have been added to LLVM. The Div instruction is now -UDiv, SDiv, and FDiv. The Rem instruction -is now URem, SRem and FRem. See the -Language Reference for details on these new -instructions.

      -

    • ConstantBool::True and ConstantBool::False have been - renamed to ConstantBool::getTrue() and - ConstantBool::getFalse().

      • -
    • The 'analyze' tool has been merged into the 'opt' tool.
      • +
    • Pass registration is slightly different in LLVM 2.0 (you now need an + intptr_t in your constructor), as explained in the Writing an LLVM Pass + document.
      • + +
    • ConstantBool, ConstantIntegral and ConstantInt + classes have been merged together, we now just have + ConstantInt.
      • + +
    • Type::IntTy, Type::UIntTy, Type::SByteTy, ... are + replaced by Type::Int8Ty, Type::Int16Ty, etc. LLVM types + have always corresponded to fixed size types + (e.g. long was always 64-bits), but the type system no longer includes + information about the sign of the type.
      • + +
    • Several classes (CallInst, GetElementPtrInst, + ConstantArray, etc), that once took std::vector as + arguments now take ranges instead. For example, you can create a + GetElementPtrInst with code like: + + 
      +      Value *Ops[] = { Op1, Op2, Op3 };
+      GEP = new GetElementPtrInst(BasePtr, Ops, 3);
+
      + + This avoids creation of a temporary vector (and a call to malloc/free). If + you have an std::vector, use code like this: + 
      +      std::vector<Value*> Ops = ...;
+      GEP = new GetElementPtrInst(BasePtr, &Ops[0], Ops.size());
+
      + +
      • + +
    • CastInst is now abstract and its functionality is split into several parts, + one for each of the new cast + instructions.
      • + +
    • Instruction::getNext()/getPrev() are now private (along with + BasicBlock::getNext, etc), for efficiency reasons (they are now no + longer just simple pointers). Please use BasicBlock::iterator, etc instead. +
      • + +
    • Module::getNamedFunction() is now called + Module::getFunction().
      • +
    • SymbolTable.h has been split into ValueSymbolTable.h and +TypeSymbolTable.h.
    @@ -289,8 +527,8 @@
    • The -cee pass is known to be buggy, and may be removed in in a future release.
      • +
    • C++ EH support
    • The IA64 code generator is experimental.
      • -
    • The ARM code generator is experimental.
    • The Alpha JIT is experimental.
    • "-filetype=asm" (the default) is the only supported value for the -filetype llc option.
      • @@ -307,9 +545,7 @@
    @@ -324,52 +560,42 @@
    - Known problems with the SPARC back-end + Known problems with the ARM back-end
      -
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not - support the 64-bit SPARC ABI (-m64).
      • +
    • The Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 +processors, any thumb program compiled with LLVM crashes or produces wrong +results. (PR1388)
      • +
    • Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. +
      • +
    • QEMU-ARM (<= 0.9.0) wrongly executes programs compiled with LLVM. A non-affected QEMU version must be used or this + +patch must be applied on QEMU.
    - Known problems with the C back-end + Known problems with the SPARC back-end
      - -
    • 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 -fno-strict-aliasing option). This -problem probably cannot be fixed.
      • - -
    • Zero arg vararg functions are not -supported. This should not affect LLVM produced by the C or C++ -frontends.
      • - -
    • The C backend does not correctly implement the llvm.stacksave or -llvm.stackrestore -intrinsics. This means that some code compiled by it can run out of stack -space if they depend on these (e.g. C99 varargs).
      • - -
    • The C backend does not support inline - assembly code.
      • +
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).
    @@ -415,36 +641,25 @@
  8. Defining vararg functions is not supported (but calling them is ok).
    9. +
  9. The Itanium backend has bitrotted somewhat.
    10. - Known problems with the ARM back-end + Known problems with the C back-end
    - -
    - Known problems with the LLVM Core -
    - -
    - -
      -
    • In the JIT, dlsym() on a symbol compiled by the JIT will not - work.
      • -
    -
    @@ -456,15 +671,9 @@
    -

    - -

    llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but -does not currently support Link-Time -Optimization or C++ Exception Handling, -which llvm-gcc3 does.

    - -

    llvm-gcc4 does not support the GCC indirect -goto extension, but llvm-gcc3 does.

    +

    llvm-gcc4 does not currently support Link-Time +Optimization on most platforms "out-of-the-box". Please inquire on the +llvmdev mailing list if you are interested.

    @@ -474,86 +683,52 @@
    -
      -
    • "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.
      • +

    • "long double" is silently 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.

      • -
    • Although many GCC extensions are supported, some are not. In particular, - the following extensions are known to not be supported: -
        -
      1. Local Labels: Labels local to a block.
        2. -
      2. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
        3. -
      3. Constructing Calls: Dispatching a call to another function.
        4. -
      4. Thread-Local: Per-thread variables.
        5. -
      5. Pragmas: Pragmas accepted by GCC.
        6. -
      - -

      The following GCC extensions are partially supported. An ignored - attribute means that the LLVM compiler ignores the presence of the attribute, - but the code should still work. An unsupported attribute is one which is - ignored by the LLVM compiler and will cause a different interpretation of - the program.

      +

    • llvm-gcc does not support __builtin_apply yet. + See Constructing Calls: Dispatching a call to another function.

      +
      • +

    • llvm-gcc partially supports tthese GCC extensions:

        -
      1. Variable Length: - Arrays whose length is computed at run time.
        - Supported, but allocated stack space is not freed until the function returns (noted above).
        2. +
      2. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
        + Nested functions are supported, but llvm-gcc does not support non-local + gotos or taking the address of a nested function.
      3. Function Attributes: Declaring that functions have no side effects or that they can never return.
        - Supported: constructor, destructor, + Supported: alias, always_inline, cdecl, + constructor, destructor, deprecated, fastcall, format, - format_arg, non_null, noreturn, + format_arg, non_null, noreturn, regparm section, stdcall, unused, used, visibility, warn_unused_result, weak
        - Ignored: noinline, - always_inline, pure, const, nothrow, - malloc, no_instrument_function, cdecl
        - - Unsupported: alias, regparm, all other target specific - attributes
        4. - -
      4. Variable Attributes: - Specifying attributes of variables.
        - Supported: cleanup, common, nocommon, - deprecated, dllimport, dllexport, - section, transparent_union, unused, - used, weak
        - - Unsupported: aligned, mode, packed, - shared, tls_model, - vector_size, all target specific attributes. -
        5. - -
      5. Type Attributes: Specifying attributes of types.
        - Supported: transparent_union, unused, - deprecated, may_alias
        - - Unsupported: aligned, packed, - all target specific attributes.
        6. - -
      6. Other Builtins: - Other built-in functions.
        - We support all builtins which have a C language equivalent (e.g., - __builtin_cos), __builtin_alloca, - __builtin_types_compatible_p, __builtin_choose_expr, - __builtin_constant_p, and __builtin_expect - (currently ignored). We also support builtins for ISO C99 floating - point comparison macros (e.g., __builtin_islessequal), - __builtin_prefetch, __builtin_popcount[ll], - __builtin_clz[ll], and __builtin_ctz[ll].
        7. + Ignored: noinline, pure, const, nothrow, + malloc, no_instrument_function
      +
      • -

      The following extensions are known to be supported:

      +

    • llvm-gcc supports the vast majority of GCC extensions, including:

        +
      1. Pragmas: Pragmas accepted by GCC.
        2. +
      2. Local Labels: Labels local to a block.
        3. +
      3. Other Builtins: + Other built-in functions.
        4. +
      4. Variable Attributes: + Specifying attributes of variables.
        5. +
      5. Type Attributes: Specifying attributes of types.
        6. +
      6. Thread-Local: Per-thread variables.
        7. +
      7. Variable Length: + Arrays whose length is computed at run time.
      8. Labels as Values: Getting pointers to labels and computed gotos.
      9. Statement Exprs: Putting statements and declarations inside expressions.
      10. Typeof: typeof: referring to the type of an expression.
        11. @@ -609,20 +784,15 @@
        -

        For this release, the C++ front-end is considered to be fully +

        The C++ front-end is considered to be fully tested and works for a number of non-trivial programs, including LLVM -itself.

        +itself, Qt, Mozilla, etc.

        -
        - - -
        - Notes -
        - -
          -
        • llvm-gcc4 does not support C++ exception handling at all yet.
          • +
        • llvm-gcc4 only has partial support for C++ +Exception Handling, and it is not enabled by default.
          • + +
        @@ -656,11 +826,10 @@

        A wide variety of additional information is available on the LLVM web page, including documentation and 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. +href="http://llvm.org">LLVM web page, in particular in the documentation section. 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 "llvm/doc/" directory in the LLVM tree.

        @@ -679,7 +848,7 @@ Valid HTML 4.01! - The LLVM Compiler Infrastructure
        + LLVM Compiler Infrastructure
        Last modified: $Date$