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
@@ -46,23 +53,45 @@ List is a good place to send them.
Note that if you are reading this file from a Subversion checkout or the
main LLVM web page, this document applies to the next release, not the
-current one. To see the release notes for a specific releases, please see the
+current one. To see the release notes for a specific release, please see the
releases page.
-
-
+
+
+
+ Logo web page.
+ llvm devmtg
+ compiler_rt
+ KLEE web page at klee.llvm.org
+ Many new papers added to /pubs/
+ Mention gcc plugin.
+
+ -->
@@ -72,12 +101,11 @@ current one. To see the release notes for a specific releases, please see the
-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.
@@ -90,16 +118,13 @@ the
vmkit Project.
-
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.
+
The Clang project is ...
-
Codegen progress/state [DANIEL]
+
In the LLVM 2.7 time-frame, the Clang team has made many improvements:
+
@@ -109,161 +134,304 @@ front-end work has started to make significant progress.
-
The
-static analysis tool
+
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.
+
+
In the LLVM 2.7 time-frame, the analyzer core has ...
+
+
+
+
+
+
+
+
+The VMKit project is an implementation of
+a JVM and a CLI Virtual Machine (Microsoft .NET is an
+implementation of the CLI) using LLVM for static and just-in-time
+compilation.
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+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.
-[TED]
-.
+
+
+
+
+
+
+
+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 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.
+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 ...
+
+
+
-
[NICOLAS]
+
+
+
+
+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 on the order of 30% or more faster than 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 as
-well.
-
-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.
-
-LLVM 2.4 also includes an initial port for the PIC16 microprocessor. This
-is the LLVM targer that 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. While
-llvm-gcc supports all of these builtins, note that 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 ok to use low-precision approximations of certain libm
-functions (like tan, log, etc). This allows you to get high performance if you
-only need (say) 14-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.
+
+
+
+
+
+
+
-
New features include:
+
+
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.
+
+
+
+
+
+
+
+
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.
+- ...
+
-
Values with no names are now pretty printed by llvm-dis more
-nicely. They now print as "%3 = add i32 %A, 4" instead of
-"add i32 %A, 4 ; <i32>:3", which makes it much easier to read.
-
+
-
LLVM 2.4 includes some changes for better vector support. First, the shift
-operations (shl, ashr, lshr) now all support vectors
-and do an element-by-element shift (shifts of the whole vector can be
-accomplished by bitcasting the vector to <1 x i128> for example). Second,
-there is initial support in development for vector comparisons with the
-fcmp/icmp
-instructions. These instructions compare two vectors and return a vector of
-i1's for each result. Note that there is very little codegen support available
-for any of these IR features though.
-
-
A new DebugInfoBuilder class is available, which makes it much
-easier for front-ends to create debug info descriptors, similar to the way that
-IRBuilder makes it easier to create LLVM IR.
-
-
LLVM now supports "function attributes", which allows us to seperate return
-value attributes from function attributes. LLVM now supports attributes on a
-function itself, a return value, and its parameters. New supported function
-attributes include noinline/alwaysinline and the "opt-size" flag which says the
-function should be optimized for code size.
-
-
LLVM IR now directly represents "common" linkage, instead of
- representing it as a form of weak linkage.
-
+
+
+
+
+
LLVM IR has several new features for better support of new targets and that
+expose new optimization opportunities:
+
+
@@ -275,186 +443,212 @@ function should be optimized for code size.
-
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 prevents 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 C) and marks them
-with the appropriate attribute.
+
-
LLVM 2.4 now includes a new SparsePropagation framework, which makes it
-trivial to build lattice-based dataflow solvers that operate over LLVM IR. Using
-this interface means that you just define objects to represent your lattice
-values and the transfer functions that operate on them. It handles the
-mechanics of worklist processing, liveness tracking, handling PHI nodes,
-etc.
-
Various helper functions (ComputeMaskedBits, ComputeNumSignBits, etc) were
-pulled out of the Instruction Combining pass and put into a new
-ValueTracking.h header, where they can be reused by other passes.
+
+
-
The tail duplication pass has been removed from the standard optimizer
-sequence used by llvm-gcc. This pass still exists, but the benefits it once
-provided are now achieved by other passes.
+
-
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 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.
-- MIPS floating point support? [BRUNO]
-- The PowerPC backend now supports trampolines.
+- ...
+
Things not yet supported:
+
+
+- Variable arguments.
+- Interrupts/programs.
+
+
+
+
+
+
+
+
New features of the ARM target include:
+
+
+
+
+
+
-
New features include:
+
New features of other targets include:
-- 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, 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.
-
-- Recycler + pool allocation stuff? [DAN]
+- ...
-
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
-from the previous release.
+
This release includes a number of new APIs that are used internally, which
+ may also be useful for external clients.
+
-
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.
-
-
+
+
+
-
In addition, many APIs have changed in this release. Some of the major LLVM
-API changes are:
+
+
Other miscellaneous features include:
+
+
+
+
+
+
-
Attributes changes [DEVANG]
+
-
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".
+
If you're already an LLVM user or developer with out-of-tree changes based
+on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
+from the previous release.
-
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.
+
+- The LLVM interpreter now defaults to not using libffi even
+if you have it installed. This makes it more likely that an LLVM built on one
+system will work when copied to a similar system. To use libffi,
+configure with --enable-libffi.
+
+
-
Various header files like "llvm/ADT/iterator" were given a .h suffix.
- Change your code to #include "llvm/ADT/iterator.h" instead.
+
In addition, many APIs have changed in this release. Some of the major LLVM
+API changes are:
+
+
+- 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.
+
+- FIXME: Debug info has been totally redone. Add pointers to new APIs. Substantial caveats about compatibility of .ll and .bc files.
+
+- The llvm/Support/DataTypes.h header has moved
+to llvm/System/DataTypes.h.
+
+- The isInteger, isIntOrIntVector, isFloatingPoint,
+isFPOrFPVector and isFPOrFPVector methods have been renamed
+isIntegerTy, isIntOrIntVectorTy, isFloatingPointTy,
+isFPOrFPVectorTy and isFPOrFPVectorTy respectively.
@@ -472,16 +666,16 @@ converted to strings using
llvm::GetConstantStringInfo defined via
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
@@ -499,12 +693,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.
+
+
@@ -522,9 +730,11 @@ 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, 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.
@@ -544,13 +754,14 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.
and due to lack of support for
+ the
+ 'u' inline assembly constraint and for X87 floating point inline assembly.
@@ -578,14 +789,14 @@ compilation, and lacks support for debug information.
@@ -598,7 +809,7 @@ 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).
@@ -606,32 +817,30 @@ programs compiled with LLVM. Please use more recent versions of QEMU.
-
-- On 21164s, some rare FP arithmetic sequences which may trap do not have the
-appropriate nops inserted to ensure restartability.
-
+- 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.
-
+
On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.
+
+
@@ -646,8 +855,9 @@ appropriate nops inserted to ensure restartability.
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.
-
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
@@ -688,11 +894,23 @@ 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).
-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.
-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
@@ -729,6 +951,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.
+