-The "vmkit" project is a new addition to the LLVM family. It 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.
-
-
The JVM, called JnJVM, executes real-world applications such as Apache
-projects (e.g. Felix and Tomcat) and the SpecJVM98 benchmark. It uses the GNU
-Classpath project for the base classes. The CLI implementation, called N3, is
-its in early stages but can execute simple applications and the "pnetmark"
-benchmark. It uses the pnetlib project as its core library.
-
-
The 'vmkit' VMs compare in performance with industrial and top open-source
-VMs on scientific applications. Besides the JIT, the VMs use many features of
-the LLVM framework, including the standard set of optimizations, atomic
-operations, custom function provider and memory manager for JITed methods, and
-specific virtual machine optimizations. vmkit is not an official part of LLVM
-2.3 release. It is publicly available under the LLVM license and can be
-downloaded from:
-
-
-
-svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit
+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.5 release. General improvements in
+this
+cycle have included new inline asm constraint handling, better debug info
+support, general bugfixes, and better x86-64 support. This has allowed
+some major improvements in LDC, getting us much closer to being as
+fully featured as the original DMD compiler from DigitalMars.
-
-
Clang
+
-
-
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.
-
-
At this point, Clang is most useful if you are interested in source-to-source
-transformations (such as refactoring) and other source-level tools for C and
-Objective-C. Clang now also includes tools for turning C code into pretty HTML,
-and includes a new static
-analysis tool in development. This tool is automatically focused on finding
-bugs in C and Objective-C code.
-
+
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.
-
LLVM 2.3 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.
+
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.
@@ -210,53 +286,28 @@ this section.
-
LLVM 2.3 includes several major new capabilities:
+
LLVM 2.5 includes several major new capabilities:
-The biggest change in LLVM 2.3 is Multiple Return Value (MRV) support.
- MRVs allow LLVM IR to directly represent functions that return multiple
- values without having to pass them "by reference" in the LLVM IR. This
- allows a front-end to generate more efficient code, as MRVs are generally
- returned in registers if a target supports them. See the LLVM IR Reference for more details.
-
- MRVs are fully supported in the LLVM IR, but are not yet fully supported in
- on all targets. However, it is generally safe to return up to 2 values from
- a function: most targets should be able to handle at least that. MRV
- support is a critical requirement for X86-64 ABI support, as X86-64 requires
- the ability to return multiple registers from functions, and we use MRVs to
- accomplish this in a direct way.
-
-LLVM 2.3 includes a complete reimplementation of the "llvmc"
- tool. It is designed to overcome several problems with the original
- llvmc and to provide a superset of the features of the
- 'gcc' driver.
-
-The main features of llvmc2 are:
-
- - Extended handling of command line options and smart rules for
- dispatching them to different tools.
- - Flexible (and extensible) rules for defining different tools.
- - The different intermediate steps performed by tools are represented
- as edges in the abstract graph.
- - The 'language' for driver behavior definition is tablegen and thus
- it's relatively easy to add new features.
- - The definition of driver is transformed into set of C++ classes, thus
- no runtime interpretation is needed.
-
-
-
-LLVM 2.3 includes a completely rewritten interface for Link Time Optimization. This interface
- is written in C, which allows for easier integration with C code bases, and
- incorporates improvements we learned about from the first incarnation of the
- interface.
-
-The Kaleidoscope tutorial now
- includes a "port" of the tutorial that uses the Ocaml bindings to implement
- the Kaleidoscope language.
+- LLVM 2.5 includes a brand new XCore backend.
+
+- llvm-gcc now generally supports the GFortran front-end, and the precompiled
+release binaries now support Fortran, even on Mac OS/X.
+
+- CMake is now used by the LLVM build process
+on Windows. It automatically generates Visual Studio project files (and
+more) from a set of simple text files. This makes it much easier to
+maintain. In time, we'd like to standardize on CMake for everything.
+- LLVM 2.5 now uses (and includes) Google Test for unit testing.
+
+- The LLVM native code generator now supports arbitrary precision integers.
+Types like i33 have long been valid in the LLVM IR, but were previously
+only supported by the interpreter. Note that the C backend still does not
+support these.
+
+- LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
@@ -269,47 +320,82 @@ this section.
-
LLVM 2.3 fully supports the llvm-gcc 4.2 front-end, and includes support
-for the C, C++, Objective-C, Ada, and Fortran front-ends.
+
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-gcc 4.2 includes numerous fixes to better support the Objective-C
-front-end. Objective-C now works very well on Mac OS/X.
-
-- Fortran EQUIVALENCEs are now supported by the gfortran front-end.
-
-- llvm-gcc 4.2 includes many other fixes which improve conformance with the
-relevant parts of the GCC testsuite.
-
-
+
In this release, the GCC inliner is completely disabled. Previously the GCC
+inliner was used to handle always-inline functions and other cases. This caused
+problems with code size growth, and it is completely disabled in this
+release.
+
+
llvm-gcc (and LLVM in general) now support code generation for stack
+canaries, which is an effective form of buffer overflow
+protection. llvm-gcc supports this with the -fstack-protector
+command line option (just like GCC). In LLVM IR, you can request code
+generation for stack canaries with function attributes.
+
+
-
New features include:
-
+
LLVM IR has several new features that are used by our existing front-ends and
+can be useful if you are writing a front-end for LLVM:
-- LLVM IR now directly represents "common" linkage, instead of representing it
-as a form of weak linkage.
+- The shufflevector instruction
+has been generalized to allow different shuffle mask width than its input
+vectors. This allows you to use shufflevector to combine two
+"<4 x float>" vectors into a "<8 x float>" for example.
+
+- LLVM IR now supports new intrinsics for computing and acting on overflow of integer operations. This allows
+efficient code generation for languages that must trap or throw an exception on
+overflow. While these intrinsics work on all targets, they only generate
+efficient code on X86 so far.
+
+- LLVM IR now supports a new private
+linkage type to produce labels that are stripped by the assembler before it
+produces a .o file (thus they are invisible to the linker).
+
+- LLVM IR supports two new attributes for better alias analysis. The noalias attribute can now be used on the
+return value of a function to indicate that it returns new memory (e.g.
+'malloc', 'calloc', etc).
+The new nocapture attribute can be used
+on pointer arguments to indicate that the function does not return the pointer,
+store it in an object that outlives the call, or let the value of the pointer
+escape from the function in any other way.
+Note that it is the pointer itself that must not escape, not the value it
+points to: loading a value out of the pointer is perfectly fine.
+Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
+
+
+
+- The parser for ".ll" files in lib/AsmParser is now completely rewritten as a
+recursive descent parser. This parser produces better error messages (including
+caret diagnostics), is less fragile (less likely to crash on strange things),
+does not leak memory, is more efficient, and eliminates LLVM's last use of the
+'bison' tool.
-- LLVM IR now has support for atomic operations, and this functionality can
-be accessed through the llvm-gcc "__sync_synchronize",
-"__sync_val_compare_and_swap", and related builtins. Support for atomics are
-available in the Alpha, X86, X86-64, and PowerPC backends.
+- Debug information representation and manipulation internals have been
+ consolidated to use a new set of classes in
+ llvm/Analysis/DebugInfo.h. These routines are more
+ efficient, robust, and extensible and replace the older mechanisms.
+ llvm-gcc, clang, and the code generator now use them to create and process
+ debug information.
-- The C and Ocaml bindings have extended to cover pass managers, several
-transformation passes, iteration over the LLVM IR, target data, and parameter
-attribute lists.
-
+
@@ -319,206 +405,228 @@ attribute lists.
-
In addition to a huge array of bug fixes and minor performance tweaks, the
-LLVM 2.3 optimizers support a few major enhancements:
+
In addition to a large array of bug fixes and minor performance tweaks, this
+release includes a few major enhancements and additions to the optimizers:
-for (i = LB; i < UB; ++i)
- if (i <= NV)
- LOOP_BODY
-
+
The "-mem2reg" pass is now much faster on code with large basic blocks.
-
is transformed into:
+
The "-jump-threading" pass is more powerful: it is iterative
+ and handles threading based on values with fully and partially redundant
+ loads.
-
-NUB = min(NV+1, UB)
-for (i = LB; i < NUB; ++i)
- LOOP_BODY
-
-
+
The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is
+ both faster and more aggressive.
-
LLVM now includes a new memcpy optimization pass which removes
-dead memcpy calls, unneeded copies of aggregates, and performs
-return slot optimization. The LLVM optimizer now notices long sequences of
-consecutive stores and merges them into memcpy's where profitable.
-
-
Alignment detection for vector memory references and for memcpy and
-memset is now more aggressive.
-
-
The Aggressive Dead Code Elimination (ADCE) optimization has been rewritten
-to make it both faster and safer in the presence of code containing infinite
-loops. Some of its prior functionality has been factored out into the loop
-deletion pass, which is safe for infinite loops. The new ADCE pass is
-no longer based on control dependence, making it run faster.
-
-
The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
- functions for C-based languages, has been rewritten to be a FunctionPass
- instead a ModulePass. This allows it to be run more often and to be
- included at -O1 in llvm-gcc. It was also extended to include more
- optimizations and several corner case bugs were fixed.
-
-
LLVM now includes a simple 'Jump Threading' pass, which attempts to simplify
- conditional branches using information about predecessor blocks, simplifying
- the control flow graph. This pass is pretty basic at this point, but
- catches some important cases and provides a foundation to build on.
-
-
Several corner case bugs which could lead to deleting volatile memory
- accesses have been fixed.
+
The "-scalarrepl" scalar replacement of aggregates pass is more aggressive
+ about promoting unions to registers.
-
Several optimizations have been sped up, leading to faster code generation
- with the same code quality.
-
-
We 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 code generator now has support for carrying information about memory
- references throughout the entire code generation process, via the
-
- MachineMemOperand class. In the future this will be used to improve
- both pre-pass and post-pass scheduling, and to improve compiler-debugging
- output.
-
-- The target-independent code generator infrastructure now uses LLVM's
- APInt
- class to handle integer values, which allows it to support integer types
- larger than 64 bits. Note that support for such types is also dependent on
- target-specific support. Use of APInt is also a step toward support for
- non-power-of-2 integer sizes.
-
-- LLVM 2.3 includes several compile time speedups for code with large basic
- blocks, particularly in the instruction selection phase, register
- allocation, scheduling, and tail merging/jump threading.
+- The Writing an LLVM Compiler
+Backend document has been greatly expanded and is substantially more
+complete.
+
+- The SelectionDAG type legalization logic has been completely rewritten, is
+now more powerful (it supports arbitrary precision integer types for example),
+and is more correct in several corner cases. The type legalizer converts
+operations on types that are not natively supported by the target machine into
+equivalent code sequences that only use natively supported types. The old type
+legalizer is still available (for now) and will be used if
+-disable-legalize-types is passed to the code generator.
+
-- Several improvements which make llc's --view-sunit-dags
- visualization of scheduling dependency graphs easier to understand.
-
-- The code generator allows targets to write patterns that generate subreg
- references directly in .td files now.
-
-- memcpy lowering in the backend is more aggressive, particularly for
- memcpy calls introduced by the code generator when handling
- pass-by-value structure argument copies.
+- The code generator now supports widening illegal vectors to larger legal
+ones (for example, converting operations on <3 x float> to work on
+<4 x float>) which is very important for common graphics
+applications.
+
+- The assembly printers for each target are now split out into their own
+libraries that are separate from the main code generation logic. This reduces
+the code size of JIT compilers by not requiring them to be linked in.
+
+- The 'fast' instruction selection path (used at -O0 and for fast JIT
+ compilers) now supports accelerating codegen for code that uses exception
+ handling constructs.
-- Inline assembly with multiple register results now returns those results
- directly in the appropriate registers, rather than going through memory.
- Inline assembly that uses constraints like "ir" with immediates now use the
- 'i' form when possible instead of always loading the value in a register.
- This saves an instruction and reduces register use.
-
-- Added support for PIC/GOT style tail calls on x86/32 and initial support
- for tail calls on PowerPC 32 (it may also work on ppc64 but not
- thoroughly tested).
+- The optional PBQP register allocator now supports register coalescing.
+
+
+
+
+
New features of the X86 target include:
+
+
+
+- The llvm.returnaddress
+intrinsic (which is used to implement __builtin_return_address) now
+supports non-zero stack depths on X86.
+
+- The X86 backend now supports code generation of vector shift operations
+using SSE instructions.
+
+- X86-64 code generation now takes advantage of red zone, unless the
+-mno-red-zone option is specified.
+
+- The X86 backend now supports using address space #256 in LLVM IR as a way of
+performing memory references off the GS segment register. This allows a
+front-end to take advantage of very low-level programming techniques when
+targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple
+example.
+
+- The X86 backend now supports a -disable-mmx command line option to
+ prevent use of MMX even on chips that support it. This is important for cases
+ where code does not contain the proper llvm.x86.mmx.emms
+ intrinsics.
+
+- The X86 JIT now detects the new Intel Core i7 and Atom chips and
+ auto-configures itself appropriately for the features of these chips.
+
+- The JIT now supports exception handling constructs on Linux/X86-64 and
+ Darwin/x86-64.
+
+- The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on
+ X86-64.
+
+
+
-
New target-specific features include:
+
New features of the PIC16 target include:
-- llvm-gcc's X86-64 ABI conformance is far improved, particularly in the
- area of passing and returning structures by value. llvm-gcc compiled code
- now interoperates very well on X86-64 systems with other compilers.
+- Both direct and indirect load/stores work now.
+- Logical, bitwise and conditional operations now work for integer data
+types.
+- Function calls involving basic types work now.
+- Support for integer arrays.
+- The compiler can now emit libcalls for operations not supported by m/c
+instructions.
+- Support for both data and ROM address spaces.
+
+
+
Things not yet supported:
+
+
+- Floating point.
+- Passing/returning aggregate types to and from functions.
+- Variable arguments.
+- Indirect function calls.
+- Interrupts/programs.
+- Debug info.
+
+
+
+
+
+
+
-
Support for Win64 was added. This includes code generation itself, JIT
- support and necessary changes to llvm-gcc.
+
+
New features include:
-
The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
- the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins. Various
- generic vector operations (insert/extract/shuffle) are much more efficient
- when SSE 4.1 is enabled. The JIT automatically takes advantage of these
- instructions, but llvm-gcc must be explicitly told to use them, e.g. with
- -march=penryn.
+
+- Beginning with LLVM 2.5, llvmc2 is known as
+ just llvmc. The old llvmc driver was removed.
-- The X86 backend now does a number of optimizations that aim to avoid
- converting numbers back and forth from SSE registers to the X87 floating
- point stack.
+- The Clang plugin was substantially improved and is now enabled
+ by default. The command llvmc --clang can be now used as a
+ synonym to ccc.
-- The X86 backend supports stack realignment, which is particularly useful for
- vector code on OS's without 16-byte aligned stacks.
+- There is now a --check-graph option, which is supposed to catch
+ common errors like multiple default edges, mismatched output/input language
+ names and cycles. In general, these checks can't be done at compile-time
+ because of the need to support plugins.
-- The X86 backend now supports the "sseregparm" options in GCC, which allow
- functions to be tagged as passing floating point values in SSE
- registers.
+- Plugins are now more flexible and can refer to compilation graph nodes and
+ options defined in other plugins. To manage dependencies, a priority-sorting
+ mechanism was introduced. This change affects the TableGen file syntax. See the
+ documentation for details.
-- Trampolines (taking the address of a nested function) now work on
- Linux/X86-64.
+- Hooks can now be provided with arguments. The syntax is "$CALL(MyHook,
+ 'Arg1', 'Arg2', 'Arg3')".
-- __builtin_prefetch is now compiled into the appropriate prefetch
- instructions instead of being ignored.
+- A new option type: multi-valued option, for options that take more than one
+ argument (for example, "-foo a b c").
-- 128-bit integers are now supported on X86-64 targets.
+- New option properties: 'one_or_more', 'zero_or_more',
+'hidden' and 'really_hidden'.
-- The register allocator can now rematerialize PIC-base computations.
+- The 'case' expression gained an 'error' action and
+ an 'empty' test (equivalent to "(not (not_empty ...))").
-- The "t" and "f" inline assembly constraints for the X87 floating point stack
- now work. However, the "u" constraint is still not fully supported.
+- Documentation now looks more consistent to the rest of the LLVM
+ docs. There is also a man page now.
-
+
+
-
New target-specific features include:
-
+
+
If you're already an LLVM user or developer with out-of-tree changes based
+on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading
+from the previous release.
-- The LLVM C backend now supports vector code.
-
-
-
+
llvm-gcc defaults to -fno-math-errno on all X86 targets.
+
-
-
-
-
New features include:
-
+
In addition, many APIs have changed in this release. Some of the major LLVM
+API changes are:
-- LLVM now builds with GCC 4.3.
-- Bugpoint now supports running custom scripts (with the -run-custom
- option) to determine how to execute the command and whether it is making
- forward process.
+- Some deprecated interfaces to create Instruction subclasses, that
+ were spelled with lower case "create," have been removed.
-
+
+
+
Portability and Supported Platforms
@@ -530,10 +638,10 @@ faster:
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 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 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++).
@@ -557,9 +665,8 @@ 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.
@@ -580,9 +687,9 @@ components, please contact us on the
LLVMdev list.
-- The MSIL, IA64, Alpha, SPU, and MIPS backends are experimental.
-- The llc "-filetype=asm" (the default) is the only supported
- value for this option.
+- 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.
@@ -602,14 +709,14 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.
- The X86 backend generates inefficient floating point code when configured
to generate code for systems that don't have SSE2.
- Win64 code generation wasn't widely tested. Everything should work, but we
- expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
- currently due
+ expect small issues to happen. Also, llvm-gcc cannot build the mingw64
+ runtime currently due
to several
- bugs in FP stackifier
-
- The X86-64 backend does not yet support position-independent code (PIC)
- generation on Linux targets.
+ bugs and due to lack of support for
+ the
+ 'u' inline assembly constraint and for X87 floating point inline assembly.
- The X86-64 backend does not yet support the LLVM IR instruction
- va_arg. Currently, the llvm-gcc front-end supports variadic
+ va_arg. Currently, the llvm-gcc and front-ends support variadic
argument constructs on X86-64 by lowering them manually.
@@ -640,7 +747,7 @@ compilation, and lacks support for debug information.
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
@@ -657,12 +764,26 @@ 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.
+
+
+
+
Known problems with the Alpha back-end
@@ -686,25 +807,9 @@ appropriate nops inserted to ensure restartability.
-
-- C++ programs are likely to fail on IA64, as calls to setjmp are
-made where the argument is not 16-byte aligned, as required on IA64. (Strictly
-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.)
-
-- The C++ front-end does not use IA64
-ABI compliant layout of v-tables. 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.
-
-- 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.
-
-- Defining vararg functions is not supported (but calling them is OK).
-
-- The Itanium backend has bitrotted somewhat.
+- 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.
@@ -721,8 +826,9 @@ programs.
inline assembly code.
The C backend violates the ABI of common
C++ programs, preventing intermixing between C++ compiled by the CBE and
- C++ code compiled with llc or native compilers.
+ C++ code compiled with
llc or native compilers.
The C backend does not support all exception handling constructs.
+
The C backend does not support arbitrary precision integers.
@@ -733,14 +839,11 @@ programs.
Known problems with the llvm-gcc C front-end
-
-
Bugs
-
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.
+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
@@ -765,13 +868,23 @@ tested and works for a number of non-trivial programs, including LLVM
itself, Qt, Mozilla, etc.
-- Exception handling works well on the X86 and PowerPC targets, including
-X86-64 darwin. This works when linking to a libstdc++ compiled by GCC. It is
-supported on X86-64 linux, but that is disabled by default in this release.
+- Exception handling works well on the X86 and PowerPC targets. Currently
+ 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.
+
+
@@ -779,20 +892,23 @@ supported on X86-64 linux, but that is disabled by default in this release.
-The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
-technology and problems should be expected.
+The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
+technology, and problems should be expected.
- 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.
+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 and c393010 ACATS tests
-fail (c380004 also fails with gcc-4.2 mainline). When built at -O3, the
-cxg2021 ACATS test also fails.
-- Some gcc specific Ada tests continue to crash the compiler. The testsuite
-reports most tests as having failed even though they pass.
+- The c380004, c393010
+and cxg2021 ACATS tests fail
+(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.
@@ -836,9 +952,9 @@ lists.
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
LLVM Compiler Infrastructure
Last modified: $Date$