Written by the LLVM Team
+These are in-progress notes for the upcoming LLVM 2.7
+release.
+You may prefer the
+LLVM 2.6
+Release Notes.
+
This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.4. Here we describe the status of LLVM, including +Infrastructure, release 2.7. Here we describe the status of LLVM, including major improvements from the previous release and significant known problems. -All LLVM releases may be downloaded from the LLVM releases web site.
For more information about LLVM, including information about the latest @@ -50,19 +57,40 @@ current one. To see the release notes for a specific release, please see the releases page.
-The LLVM 2.4 distribution currently consists of code from the core LLVM -repository (which roughly includes the LLVM optimizers, code generators and -supporting tools) and the llvm-gcc repository. In addition to this code, the -LLVM Project includes other sub-projects that are in development. The two which -are the most actively developed are the Clang Project and -the VMKit Project. +The LLVM 2.7 distribution currently consists of code from the core LLVM +repository (which roughly includes the LLVM optimizers, code generators +and supporting tools), the Clang repository and the llvm-gcc repository. In +addition to this code, the LLVM Project includes other sub-projects that are in +development. Here we include updates on these subprojects.
The Clang project is an effort to build -a set of new 'LLVM native' front-end technologies for the LLVM optimizer -and code generator. Clang is continuing to make major strides forward in all -areas. Its C and Objective-C parsing support is very solid, and the code -generation support is far enough along to build many C applications. While not -yet production quality, it is progressing very nicely. In addition, C++ -front-end work has started to make significant progress.
- -Clang, in conjunction with the ccc driver, is now usable as a -replacement for gcc for building some small- to medium-sized C applications. -Additionally, Clang now has code generation support for Objective-C on Mac OS X -platform. Major highlights include:
+The Clang project is ...
--
-
- Clang/ccc pass almost all of the LLVM test suite on Mac OS X and Linux -on the 32-bit x86 architecture. This includes significant C -applications such as sqlite3, -lua, and -Clam AntiVirus. - -
- Clang can build the majority of Objective-C examples shipped with the -Mac OS X Developer Tools. -
Clang code generation still needs considerable testing and development, -however. Some areas under active development include:
+In the LLVM 2.7 time-frame, the Clang team has made many improvements:
-
-
- Improved support for C and Objective-C features, for example - variable-length arrays, va_arg, exception handling (Obj-C), and garbage - collection (Obj-C). -
- ABI compatibility, especially for platforms other than 32-bit - x86. +
- ...
The Clang project also includes an early stage static source code analysis -tool for automatically -finding bugs in C and Objective-C programs. The tool performs a growing set -of checks to find bugs that occur on a specific path within a program. Examples -of bugs the tool finds include logic errors such as null dereferences, -violations of various API rules, dead code, and potential memory leaks in -Objective-C programs. Since its inception, public feedback on the tool has been -extremely positive, and conservative estimates put the number of real bugs it -has found in industrial-quality software on the order of thousands.
+Previously announced in the 2.4, 2.5, and 2.6 LLVM releases, the Clang project also +includes an early stage static source code analysis tool for automatically finding bugs +in C and Objective-C programs. The tool performs checks to find +bugs that occur on a specific path within a program.
-The tool also provides a simple web GUI to inspect potential bugs found by -the tool. While still early in development, the GUI illustrates some of the key -features of Clang: accurate source location information, which is used by the -GUI to highlight specific code expressions that relate to a bug (including those -that span multiple lines); and built-in knowledge of macros, which is used to -perform inline expansion of macros within the GUI itself.
- -The set of checks performed by the static analyzer is gradually expanding, -and future plans for the tool include full source-level inter-procedural -analysis and deeper checks such as buffer overrun detection. There are many -opportunities to extend and enhance the static analyzer, and anyone interested -in working on this project is encouraged to get involved!
+In the LLVM 2.7 time-frame, the analyzer core has ...
The VMKit project is an implementation of -a JVM and a CLI Virtual Machines (Microsoft .NET is an -implementation of the CLI) using the Just-In-Time compiler of LLVM.
+a JVM and a CLI Virtual Machine (Microsoft .NET is an +implementation of the CLI) using LLVM for static and just-in-time +compilation. -Following LLVM 2.4, VMKit has its first release 0.24 that you can find on its -webpage. The release includes +
+VMKit version ?? builds with LLVM 2.7 and you can find it on its +web page. The release includes bug fixes, cleanup and new features. The major changes are:
-
-
- Support for generics in the .Net virtual machine. -
- Initial support for the Mono class libraries. -
- Support for MacOSX/x86, following LLVM's support for exceptions in -JIT on MacOSX/x86. -
- A new vmkit driver: a program to run java or .net applications. The driver -supports llvm command line arguments including the new "-fast" option. -
- A new memory allocation scheme in the JVM that makes unloading a -class loader very fast. -
- VMKit now follows the LLVM Makefile machinery. +
- ...
+The new LLVM compiler-rt project +is a simple library that provides an implementation of the low-level +target-specific hooks required by code generation and other runtime components. +For example, when compiling for a 32-bit target, converting a double to a 64-bit +unsigned integer is compiled into a runtime call to the "__fixunsdfdi" +function. The compiler-rt library provides highly optimized implementations of +this and other low-level routines (some are 3x faster than the equivalent +libgcc routines).
+ ++All of the code in the compiler-rt project is available under the standard LLVM +License, a "BSD-style" license.
+ ++The new LLVM KLEE project is a symbolic +execution framework for programs in LLVM bitcode form. KLEE tries to +symbolically evaluate "all" paths through the application and records state +transitions that lead to fault states. This allows it to construct testcases +that lead to faults and can even be used to verify algorithms. For more +details, please see the OSDI 2008 paper about +KLEE.
+ ++The goal of DragonEgg is to make +gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever. +DragonEgg is a shared library (dragonegg.so) +that is loaded by gcc at runtime. It ... +
+ ++The LLVM Machine Code (MC) Toolkit project is ... +
+ +This release includes a huge number of bug fixes, performance tweaks, and -minor improvements. Some of the major improvements and new features are listed -in this section. +
An exciting aspect of LLVM is that it is used as an enabling technology for + a lot of other language and tools projects. This section lists some of the + projects that have already been updated to work with LLVM 2.7.
+Rubinius is an environment +for running Ruby code which strives to write as much of the core class +implementation in Ruby as possible. Combined with a bytecode interpreting VM, it +uses LLVM to optimize and compile ruby code down to machine code. Techniques +such as type feedback, method inlining, and uncommon traps are all used to +remove dynamism from ruby execution and increase performance.
+ +Since LLVM 2.5, Rubinius has made several major leaps forward, implementing +a counter based JIT, type feedback and speculative method inlining.
+LLVM 2.4 includes several major new capabilities:
++MacRuby is an implementation of Ruby on top of +core Mac OS X technologies, such as the Objective-C common runtime and garbage +collector and the CoreFoundation framework. It is principally developed by +Apple and aims at enabling the creation of full-fledged Mac OS X applications. +
--
-
The most visible end-user change in LLVM 2.4 is that it includes many -optimizations and changes to make -O0 compile times much faster. You should see -improvements in speed on the order of 30% (or more) than in LLVM 2.3. There are -many pieces to this change described in more detail below. The speedups and new -components can also be used for JIT compilers that want fast -compilation.
-
-The biggest change to the LLVM IR is that Multiple Return Values (which -were introduced in LLVM 2.3) have been generalized to full support for "First -Class Aggregate" values in LLVM 2.4. This means that LLVM IR supports using -structs and arrays as values in a function. This capability is mostly useful -for front-end authors, who prefer to treat things like complex numbers, simple -tuples, dope vectors, etc., as Value*'s instead of as a tuple of Value*'s or as -memory values. Bitcode files from LLVM 2.3 will automatically migrate to the -general representation.
-
-LLVM 2.4 also includes an initial port for the PIC16 microprocessor. This -target only has support for 8 bit registers, and a number of other crazy -constraints. While the port is still in early development stages, it shows some -interesting things you can do with LLVM.
+
+MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby +expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception +handling.
-+Pure +is an algebraic/functional programming language based on term rewriting. +Programs are collections of equations which are used to evaluate expressions in +a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation, +lexical closures, a hygienic macro system (also based on term rewriting), +built-in list and matrix support (including list and matrix comprehensions) and +an easy-to-use C interface. The interpreter uses LLVM as a backend to + JIT-compile Pure programs to fast native code.
+ +Pure versions ??? and later have been tested and are known to work with +LLVM 2.7 (and continue to work with older LLVM releases >= 2.3 as well). +
+LDC is an implementation of +the D Programming Language using the LLVM optimizer and code generator. +The LDC project works great with the LLVM 2.6 release. General improvements in +this +cycle have included new inline asm constraint handling, better debug info +support, general bug fixes and better x86-64 support. This has allowed +some major improvements in LDC, getting it much closer to being as +fully featured as the original DMD compiler from DigitalMars. +
+LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC -front-ends and driver with the LLVM optimizer and code generator. It currently -includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.
+ +-
-
- LLVM 2.4 supports the full set of atomic __sync_* builtins. LLVM -2.3 only supported those used by OpenMP, but 2.4 supports them all. Note that -while llvm-gcc supports all of these builtins, not all targets do. X86 support -them all in both 32-bit and 64-bit mode and PowerPC supports them all except for -the 64-bit operations when in 32-bit mode. - -
- llvm-gcc now supports an -flimited-precision option, which tells -the compiler that it is okay to use low-precision approximations of certain libm -functions (like exp, log, etc). This allows you to get high -performance if you only need (say) 12-bits of precision. - -
- llvm-gcc now supports a C language extension known as "Blocks". -This feature is similar to nested functions and closures, but does not -require stack trampolines (with most ABIs), and supports returning closures -from functions that define them. Note that actually using Blocks -requires a small runtime that is not included with llvm-gcc. - -
- llvm-gcc now supports a new -flto option. On systems that support -transparent Link Time Optimization (currently Darwin systems with Xcode 3.1 and -later) this allows the use of LTO with other optimization levels like -Os. -Previously, LTO could only be used with -O4, which implied optimizations in --O3 that can increase code size. -
+Roadsend PHP (rphp) is an open +source implementation of the PHP programming +language that uses LLVM for its optimizer, JIT and static compiler. This is a +reimplementation of an earlier project that is now based on LLVM.
++Unladen Swallow is a +branch of Python intended to be fully +compatible and significantly faster. It uses LLVM's optimization passes and JIT +compiler.
+LLVM-Lua uses LLVM to add JIT +and static compiling support to the Lua VM. Lua bytecode is analyzed to +remove type checks, then LLVM is used to compile the bytecode down to machine +code.
++IcedTea provides a +harness to build OpenJDK using only free software build tools and to provide +replacements for the not-yet free parts of OpenJDK. One of the extensions that +IcedTea provides is a new JIT compiler named Shark which uses LLVM +to provide native code generation without introducing processor-dependent +code. +
+This release includes a huge number of bug fixes, performance tweaks and +minor improvements. Some of the major improvements and new features are listed +in this section. +
+ +New features include:
+ +LLVM 2.7 includes several major new capabilities:
-
-
- A major change to the Use class landed, which shrank it by 25%. Since -this is a pervasive part of the LLVM, it ended up reducing the memory use of -LLVM IR in general by 15% for most programs. +
- ... +
LLVM IR has several new features for better support of new targets and that +expose new optimization opportunities:
+ +-
+
- ...
In addition to a huge array of bug fixes and minor performance tweaks, this +
In addition to a large array of minor performance tweaks and bug fixes, this release includes a few major enhancements and additions to the optimizers:
-
-
- The Global Value Numbering (GVN) pass now does local Partial Redundancy -Elimination (PRE) to eliminate some partially redundant expressions in cases -where doing so won't grow code size. - -
- LLVM 2.4 includes a new loop deletion pass (which removes output-free -provably-finite loops) and a rewritten Aggressive Dead Code Elimination (ADCE) -pass that no longer uses control dependence information. These changes speed up -the optimizer and also prevent it from deleting output-free infinite -loops. +
- ... -
- The new AddReadAttrs pass works out which functions are read-only or -read-none (these correspond to 'pure' and 'const' in GCC) and marks them -with the appropriate attribute. +
-
+
- The JIT now defaults +to compiling eagerly to avoid a race condition in the lazy JIT. +Clients that still want the lazy JIT can switch it on by calling +ExecutionEngine::DisableLazyCompilation(false).
We have put a significant amount of work into the code generator infrastructure, -which allows us to implement more aggressive algorithms and make it run -faster:
+We have put a significant amount of work into the code generator +infrastructure, which allows us to implement more aggressive algorithms and make +it run faster:
-
-
- The target-independent code generator supports (and the X86 backend - currently implements) a new interface for "fast" instruction selection. This - interface is optimized to produce code as quickly as possible, sacrificing - code quality to do it. This is used by default at -O0 or when using - "llc -fast" on X86. It is straight-forward to add support for - other targets if faster -O0 compilation is desired. - -
- In addition to the new 'fast' instruction selection path, many existing - pieces of the code generator have been optimized in significant ways. - SelectionDAG's are now pool allocated and use better algorithms in many - places, the ".s" file printers now use raw_ostream to emit text much faster, - etc. The end result of these improvements is that the compiler also takes - substantially less time to generate code that is just as good (and often - better) than before. - -
- Each target has been split to separate the ".s" file printing logic from the - rest of the target. This enables JIT compilers that don't link in the - (somewhat large) code and data tables used for printing a ".s" file. - -
- The code generator now includes a "stack slot coloring" pass, which packs - together individual spilled values into common stack slots. This reduces - the size of stack frames with many spills, which tends to increase L1 cache - effectiveness. - -
- Various pieces of the register allocator (e.g. the coalescer and two-address - operation elimination pass) now know how to rematerialize trivial operations - to avoid copies and include several other optimizations. - -
- The graphs produced by - the llc -view-*-dags options are now significantly prettier and - easier to read. - -
- LLVM 2.4 includes a new register allocator based on Partitioned Boolean - Quadratic Programming (PBQP). This register allocator is still in - development, but is very simple and clean. +
- ...
New features of the X86 target include: +
+ +-
+
+
- ... + +
New target-specific features include: +
New features of the PIC16 target include:
-
-
- Exception handling is supported by default on Linux/x86-64. -
- Position Independent Code (PIC) is now supported on Linux/x86-64. -
- @llvm.frameaddress now supports getting the frame address of stack frames - > 0 on x86/x86-64. -
- MIPS has improved a lot since last release, the most important changes - are: Little endian support, floating point support, allegrex core and - intrinsics support. O32 ABI is improved but isn't complete. The EABI - was implemented and is fully supported. We also have support for small - sections and gp_rel relocation for its access, a threshold in bytes can be - specified through command line. -
- The PowerPC backend now supports trampolines. +
- ...
Things not yet supported:
+ +-
+
- Variable arguments. +
- Interrupts/programs. +
New features of the ARM target include: +
+ +-
+
+
- ... +
New features of other targets include: +
+ +-
+
- ... +
New features include: + +
This release includes a number of new APIs that are used internally, which + may also be useful for external clients.
-
-
- llvmc2 (the generic compiler driver) gained plugin - support. It is now easier to experiment with llvmc2 and - build your own tools based on it. - -
- LLVM 2.4 includes a number of new generic algorithms and data structures, - include a scoped hash table, 'immutable' data structures, a simple - free-list manager, and a raw_ostream class. - The raw_ostream class and - format allow for efficient file output, and various pieces of LLVM - have switched over to use it. The eventual goal is to eliminate - std::ostream in favor of it. - -
- LLVM 2.4 includes an optional build system based on CMake. It - still is in its early stages but can be useful for Visual C++ - users who can not use the Visual Studio IDE. +
- ... +
Other miscellaneous features include:
+ +-
+
- ...
If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.3, this section lists some "gotchas" that you may run into upgrading +on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading from the previous release.
-
-
-
- The LLVM IR generated by llvm-gcc no longer names all instructions. This - makes it run faster, but may be more confusing to some people. If you - prefer to have names, the 'opt -instnamer' pass will add names to - all instructions. - -
- The LoadVN and GCSE passes have been removed from the tree. They are - obsolete and have been replaced with the GVN and MemoryDependence passes. - +
- ...
-
-
-
- Now, function attributes and return value attributes are managed
-separately. Interface exported by ParameterAttributes.h header is now
-experted by Attributes.h header. The new attributes interface changes are:
-
-
-
- getParamAttrs method is now replaced by -getParamAttributes, getRetAttributes and -getFnAttributes methods. -
- Return value attributes are stored at index 0. Function attributes are -stored at index ~0U. Parameter attributes are stored at index that matches -parameter number. -
- ParamAttr namespace is now renamed as Attribute. -
- The name of the class that manages reference count of opaque -attributes is changed from PAListPtr to AttrListPtr. -
- ParamAttrsWithIndex is now renamed as AttributeWithIndex. - -
-
- - The DbgStopPointInst methods getDirectory and -getFileName now return Value* instead of strings. These can be -converted to strings using llvm::GetConstantStringInfo defined via -"llvm/Analysis/ValueTracking.h". - -
- The APIs to create various instructions have changed from lower case - "create" methods to upper case "Create" methods (e.g. - BinaryOperator::create). LLVM 2.4 includes both cases, but the - lower case ones are removed in mainline, please migrate. - -
- Various header files like "llvm/ADT/iterator" were given a ".h" suffix. - Change your code to #include "llvm/ADT/iterator.h" instead. - -
- The getresult instruction has been removed and replaced with the - extractvalue instruction. This is part of support for first class - aggregates. - -
- In the code generator, many MachineOperand predicates were renamed to be - shorter (e.g. isFrameIndex() -> isFI()), - SDOperand was renamed to SDValue (and the "Val" - member was changed to be the getNode() accessor), and the - MVT::ValueType enum has been replaced with an "MVT" - struct. The getSignExtended and getValue methods in the - ConstantSDNode class were renamed to getSExtValue and - getZExtValue respectively, to be more consistent with - the ConstantInt class. +
- ModuleProvider has been removed +and its methods moved to Module and GlobalValue. +Most clients can remove uses of ExistingModuleProvider, +replace getBitcodeModuleProvider with +getLazyBitcodeModule, and pass their Module to +functions that used to accept ModuleProvider. Clients who +wrote their own ModuleProviders will need to derive from +GVMaterializer instead and use +Module::setMaterializer to attach it to a +Module. + +
- GhostLinkage has given up the ghost. +GlobalValues that have not yet been read from their backing +storage have the same linkage they will have after being read in. +Clients must replace calls to +GlobalValue::hasNotBeenReadFromBitcode with +GlobalValue::isMaterializable.
LLVM is known to work on the following platforms:
-
-
- Intel and AMD machines (IA32) running Red Hat Linux, Fedora Core and FreeBSD - (and probably other unix-like systems). -
- PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and - 64-bit modes. +
- Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat + Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like + systems). +
- PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit + and 64-bit modes.
- Intel and AMD machines running on Win32 using MinGW libraries (native).
- Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++). -
- Sun UltraSPARC workstations running Solaris 10. +
- Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.
- Alpha-based machines running Debian GNU/Linux. -
- Itanium-based (IA64) machines running Linux and HP-UX.
The core LLVM infrastructure uses GNU autoconf to adapt itself @@ -607,12 +674,26 @@ portability patches and reports of successful builds or error messages.
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. If you run into a problem, please check the This section contains significant known problems with the LLVM system, +listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if there isn't already one.
+-
+
- The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15) + with a message of "Error: can not do 8 + byte pc-relative relocation" when building C++ code. We intend to + fix this on mainline, but a workaround is to upgrade to binutils 2.17 or + later. + +
- LLVM will not correctly compile on Solaris and/or OpenSolaris +using the stock GCC 3.x.x series 'out the box', +See: Broken versions of GCC and other tools. +However, A Modern GCC Build +for x86/x86-64 has been made available from the third party AuroraUX Project +that has been meticulously tested for bootstrapping LLVM & Clang. +
-
-
- The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental. -
- The llc "-filetype=asm" (the default) is the only supported - value for this option. +
- The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are + experimental. +
- The llc "-filetype=asm" (the default) is the only + supported value for this option. The ELF writer is experimental. +
- The implementation of Andersen's Alias Analysis has many known bugs.
-
+
- Support for the Advanced SIMD (Neon) instruction set is still incomplete +and not well tested. Some features may not work at all, and the code quality +may be poor in some cases.
- Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 processors, thumb programs can crash or produce wrong results (PR1388). -
- Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. +
- Compilation for ARM Linux OABI (old ABI) is supported but not fully tested. -
- There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly - execute -programs compiled with LLVM. Please use more recent versions of QEMU.
-
-
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not +
- The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not support the 64-bit SPARC ABI (-m64).
-
-
- The O32 ABI is not fully supported.
- 64-bit MIPS targets are not supported yet.
-
-
- The Itanium backend is highly experimental, and has a number of known - issues. We are looking for a maintainer for the Itanium backend. If you - are interested, please contact the LLVMdev mailing list. -
llvm-gcc 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.
-The only major language feature of GCC not supported by llvm-gcc is the __builtin_apply family of builtins. However, some extensions are only supported on some targets. For example, trampolines are only @@ -810,7 +875,7 @@ itself, Qt, Mozilla, etc.
- Exception handling works well on the X86 and PowerPC targets. Currently - only linux and darwin targets are supported (both 32 and 64 bit). + only Linux and Darwin targets are supported (both 32 and 64 bit).
- Fortran support generally works, but there are still several unresolved bugs - in Bugzilla. Please see the tools/gfortran component for details. - -
- The Fortran front-end currently does not build on Darwin (without tweaks) - due to unresolved dependencies on the C front-end. - + in Bugzilla. Please see the + tools/gfortran component for details. +
- The Ada front-end currently only builds on X86-32. This is mainly due -to lack of trampoline support (pointers to nested functions) on other platforms, -however it also fails to build on X86-64 +to lack of trampoline support (pointers to nested functions) on other platforms. +However, it also fails to build on X86-64 which does support trampolines.
- The Ada front-end fails to bootstrap. -Workaround: configure with --disable-bootstrap. +This is due to lack of LLVM support for setjmp/longjmp style +exception handling, which is used internally by the compiler. +Workaround: configure with --disable-bootstrap.
- The c380004, c393010 and cxg2021 ACATS tests fail -(c380004 also fails with gcc-4.2 mainline). -
- Some gcc specific Ada tests continue to crash the compiler. -
- The -E binder option (exception backtraces) +(c380004 also fails with gcc-4.2 mainline). +If the compiler is built with checks disabled then c393010 +causes the compiler to go into an infinite loop, using up all system memory. +
- Some GCC specific Ada tests continue to crash the compiler. +
- The -E binder option (exception backtraces) does not work and will result in programs -crashing if an exception is raised. Workaround: do not use -E. +crashing if an exception is raised. Workaround: do not use -E.
- Only discrete types are allowed to start or finish at a non-byte offset in a record. Workaround: do not pack records or use representation clauses that result in a field of a non-discrete type @@ -864,6 +932,20 @@ ignored.
The Llvm.Linkage module is broken, and has incorrect values. Only +Llvm.Linkage.External, Llvm.Linkage.Available_externally, and +Llvm.Linkage.Link_once will be correct. If you need any of the other linkage +modes, you'll have to write an external C library in order to expose the +functionality. This has been fixed in the trunk.
+
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
Last modified: $Date$