Written by the LLVM Team
+ +
This document contains the release notes for the LLVM compiler -infrastructure, release 1.8. 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.3. Here we describe the status of LLVM, including +major improvements from the previous release and any known problems. 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 @@ -46,532 +47,582 @@ web site. If you have questions or comments, the LLVM developer's mailing list is a good place to send them.
-Note that if you are reading this file from CVS or the main LLVM web page, -this document applies to the next release, not the current one. To see -the release notes for the current or previous releases, see the releases page.
+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 +releases page.
This is the nineth public release of the LLVM Compiler Infrastructure. This -release incorporates a large number of enhancements and new features, -including DWARF debugging support (C and C++ on Darwin/PPC), improved inline -assembly support, a new nightly -tester, llvm-config enhancements, many bugs -fixed, and performance and compile time improvements. -
+This is the fourteenth public release of the LLVM Compiler Infrastructure. +It includes a large number of features and refinements from LLVM 2.2.
The llvm-gcc4 C front-end now generates debugging info for C and C++. This -information is propagated through the compiler and the code generator can -currently produce DWARF debugging information from it. DWARF is a standard -debugging format used on many platforms, but currently LLVM only includes -target support for Mac OS X targets for the 1.8 release. -
+LLVM 2.3 no longer supports llvm-gcc 4.0, it has been replaced with + llvm-gcc 4.2.
-LLVM 2.3 no longer includes the llvm-upgrade tool. It was useful + for upgrading LLVM 1.9 files to LLVM 2.x syntax, but you can always use a + previous LLVM release to do this. One nice impact of this is that the LLVM + regression test suite no longer depends on llvm-upgrade, which makes it run + faster.
- - +The llvm2cpp tool has been folded into llc, use + llc -march=cpp instead of llvm2cpp.
-LLVM API Changes:
-Inline assembly support is substantially improved in LLVM 1.8 over LLVM 1.7. -Many unsupported features are now supported, and inline asm support in the X86 -backend is far better. llvm-gcc4 now supports global register variables as -well.
+-
+
- Several core LLVM IR classes have migrated to use the + 'FOOCLASS::Create(...)' pattern instead of 'new + FOOCLASS(...)' (e.g. where FOOCLASS=BasicBlock). We hope to + standardize on FOOCLASS::Create for all IR classes in the future, + but not all of them have been moved over yet. +
- LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to + IRBuilder. +
- MRegisterInfo was renamed to TargetRegisterInfo. +
- The MappedFile class is gone, please use MemoryBuffer instead. +
- The '-enable-eh' flag to llc has been removed. Now code should + encode whether it is safe to omit unwind information for a function by + tagging the Function object with the 'nounwind' attribute. +
The loop optimizer passes now uses "Loop-Closed SSA Form", which makes it -easier to update SSA form as loop transformations change the code. An -immediate benefit of this is that the loop unswitching pass can now unswitch -loops in more cases. +
+The core LLVM 2.3 distribution currently consists of code from the core LLVM +repository (which roughly contains the LLVM optimizer, 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 new vmkit Project +and the Clang Project.
-The code generator now lowers switch statements to jump tables, providing -significant performance boosts for applications (e.g. interpreters) whose -performance is highly correlated to switch statement performance.
- + + - - -+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: +
-The LLVM JIT now allows clients to deallocate machine code JIT'd to its code -buffer. This is important for long living applications that depend on the JIT. +
+svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit
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.
+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.
-More specific changes include:
+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.
--
-
- LLVM 1.8 includes an initial ARM backend. This backend is in early - development stages. -
- LLVM 1.8 now includes significantly better support for mingw and - cygwin. -
- The llvm-config tool is - now built by default and has several new features. -
- The X86 and PPC backends now use the correct platform ABI for passing - vectors as arguments to functions. -
- The X86 backend now includes support for the Microsoft ML assembler - ("MASM"). -
- The PowerPC backend now pattern matches the 'rlwimi' instruction more - aggressively. -
- Most of LLVM is now built with "-pedantic", ensuring better portability - to more C++ Compilers. -
- The PowerPC backend now includes initial 64-bit support. The JIT is not - complete, and the static compiler has a couple of known bugs, but support - is mostly in place. LLVM 1.9 will include completed PPC-64 support. +
LLVM 2.3 includes several major new capabilities:
+-
-
- The LLVM "SparcV9" backend (deprecated in LLVM 1.7) has been removed in -LLVM 1.8. The LLVM "Sparc" backend replaces it. -
- The --version option now prints more useful information, including the - build configuration for the tool. +
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 is known to work on the following platforms:
+LLVM 2.3 fully supports the llvm-gcc 4.2 front-end.
--
-
- Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD - (and probably other unix-like systems). -
- Sun UltraSPARC workstations running Solaris 8. -
- Intel and AMD machines running on Win32 with the Cygwin libraries (limited - support is available for native builds with Visual C++). -
- PowerPC and X86-based Mac OS X systems, running 10.2 and above. -
- Alpha-based machines running Debian GNU/Linux. -
- Itanium-based machines running Linux and HP-UX. -
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.
-The core LLVM infrastructure uses -GNU autoconf to adapt itself -to the machine and operating system on which it is built. However, minor -porting may be required to get LLVM to work on new platforms. We welcome your -portability patches and reports of successful builds or error messages.
+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.
New features include: +
-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 LLVM bug database and submit a bug if -there isn't already one.
+Common linkage? + +Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize", +"__sync_val_compare_and_swap", etc + +-
+
- The C and Ocaml bindings have received additional improvements. The +bindings now cover pass managers, several transformation passes, iteration +over the LLVM IR, target data, and parameter attribute lists. +
The following components of this LLVM release are either untested, known to -be broken or unreliable, or are in early development. These components should -not be relied on, and bugs should not be filed against them, but they may be -useful to some people. In particular, if you would like to work on one of these -components, please contact us on the LLVMdev list.
+In addition to a huge array of bug fixes and minor performance tweaks, the +LLVM 2.3 optimizers support a few major enhancements:
-
-
- The -cee pass is known to be buggy, and may be removed in in a - future release. -
- The IA64 code generator is experimental. -
- The Alpha JIT is experimental. -
- "-filetype=asm" (the default) is the only supported value for the - -filetype llc option. + +
- Loop index set splitting on by default.
+This transformation hoists conditions from loop bodies and reduces loop's +iteration space to improve performance. For example,
+
+for (i = LB; i < UB; ++i) + if (i <= NV) + LOOP_BODY +
+is transformed into ++NUB = min(NV+1, UB) +for (i = LB; i < NUB; ++i) + LOOP_BODY +
+
+
+ - LLVM 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. + +
- Several optimizations have been sped up, leading to faster code generation + with the same code quality. + +
- 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.
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:
+-
-
- none yet +
- MemOperand in the code generator: describe me!. + +
- 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, particular in the instruction selection phase, register allocation, + scheduling, and tail merging/jump threading. + +
- 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. + +
- 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).
New target-specific features include: +
-
-
- In the JIT, dlsym() on a symbol compiled by the JIT will not - work. -
-llvm-gcc3 has many significant problems that are fixed by llvm-gcc4. -Two major ones include:
+-
-
- With llvm-gcc3,
- C99 variable sized arrays do not release stack memory when they go out of
- scope. Thus, the following program may run out of stack space:
-
- for (i = 0; i != 1000000; ++i) { - int X[n]; - foo(X); - } -
+ - The X86 backend now supports the "sseregparm" options in GCC, which allow + functions to be tagged as passing floating point values in SSE + registers. -
- With llvm-gcc3, Initialization of global union variables can only be done with the largest union member. +
- Trampolines (taking the address of a nested function) now work on + Linux/X86-64. -
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.
+New target-specific features include: +
-
-
-
- "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. - -
- The following Unix system functionality has not been tested and may not
-work:
-
-
-
- sigsetjmp, siglongjmp - These are not turned into the - appropriate invoke/unwind instructions. Note that - setjmp and longjmp are compiled correctly. -
- getcontext, setcontext, makecontext - - These functions have not been tested. -
-
- - Although many GCC extensions are supported, some are not. In particular,
- the following extensions are known to not be supported:
-
-
-
- Local Labels: Labels local to a block. -
- Nested Functions: As in Algol and Pascal, lexical scoping of functions. -
- Constructing Calls: Dispatching a call to another function. -
- Extended Asm: Assembler instructions with C expressions as operands. -
- Constraints: Constraints for asm operands. -
- Asm Labels: Specifying the assembler name to use for a C symbol. -
- Explicit Reg Vars: Defining variables residing in specified registers. -
- Vector Extensions: Using vector instructions through built-in functions. -
- Target Builtins: Built-in functions specific to particular targets. -
- Thread-Local: Per-thread variables. -
- Pragmas: Pragmas accepted by GCC. -
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.
- --
-
- Variable Length:
- Arrays whose length is computed at run time.
- Supported, but allocated stack space is not freed until the function returns (noted above).
-
- - Function Attributes:
-
- Declaring that functions have no side effects or that they can never
- return.
- - Supported: format, format_arg, non_null, - noreturn, constructor, destructor, - unused, used, - deprecated, warn_unused_result, weak
- - Ignored: noinline, - always_inline, pure, const, nothrow, - malloc, no_instrument_function, cdecl
- - Unsupported: section, alias, - visibility, regparm, stdcall, - fastcall, all other target specific attributes
-
- - Variable Attributes:
- Specifying attributes of variables.
- Supported: cleanup, common, nocommon, - deprecated, transparent_union, - unused, used, weak
- - Unsupported: aligned, mode, packed, - section, shared, tls_model, - vector_size, dllimport, - dllexport, all target specific attributes.
-
- - Type Attributes: Specifying attributes of types.
- Supported: transparent_union, unused, - deprecated, may_alias
- - Unsupported: aligned, packed, - all target specific attributes.
-
- - 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].
-
The following extensions are known to be supported:
- --
-
- Labels as Values: Getting pointers to labels and computed gotos. -
- Statement Exprs: Putting statements and declarations inside expressions. -
- Typeof:
typeof: referring to the type of an expression.
- - Lvalues: Using
?:, "," and casts in lvalues.
- - Conditionals: Omitting the middle operand of a
?:expression.
- - Long Long: Double-word integers. -
- Complex: Data types for complex numbers. -
- Hex Floats:Hexadecimal floating-point constants. -
- Zero Length: Zero-length arrays. -
- Empty Structures: Structures with no members. -
- Variadic Macros: Macros with a variable number of arguments. -
- Escaped Newlines: Slightly looser rules for escaped newlines. -
- Subscripting: Any array can be subscripted, even if not an lvalue. -
- Pointer Arith: Arithmetic on
void-pointers and function pointers.
- - Initializers: Non-constant initializers. -
- Compound Literals: Compound literals give structures, unions, -or arrays as values. -
- Designated Inits: Labeling elements of initializers. -
- Cast to Union: Casting to union type from any member of the union. -
- Case Ranges: `case 1 ... 9' and such. -
- Mixed Declarations: Mixing declarations and code. -
- Function Prototypes: Prototype declarations and old-style definitions. -
- C++ Comments: C++ comments are recognized. -
- Dollar Signs: Dollar sign is allowed in identifiers. -
- Character Escapes:
\estands for the character <ESC>.
- - Alignment: Inquiring about the alignment of a type or variable. -
- Inline: Defining inline functions (as fast as macros). -
- Alternate Keywords:
__const__,__asm__, etc., for header files.
- - Incomplete Enums:
enum foo;, with details to follow.
- - Function Names: Printable strings which are the name of the current function. -
- Return Address: Getting the return or frame address of a function. -
- Unnamed Fields: Unnamed struct/union fields within structs/unions. -
- Attribute Syntax: Formal syntax for attributes. -
-
+ - The LLVM C backend now supports vector code.
If you run into GCC extensions which have not been included in any of these -lists, please let us know (also including whether or not they work).
-New features include: +
-For this release, the C++ front-end is considered to be fully -tested and works for a number of non-trivial programs, including LLVM -itself.
- +-
+
- 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. +
-
-
- The C++ front-end inherits all problems afflicting the C - front-end. +
- 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 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. +
- Alpha-based machines running Debian GNU/Linux. +
- Itanium-based (IA64) machines running Linux and HP-UX.
LLVM is known to work on the following platforms:
+-
+
The core LLVM infrastructure uses GNU autoconf to adapt itself +to the machine and operating system on which it is built. However, minor +porting may be required to get LLVM to work on new platforms. We welcome your +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 LLVM bug database and submit a bug if +there isn't already one.
+ +The following components of this LLVM release are either untested, known to +be broken or unreliable, or are in early development. These components should +not be relied on, and bugs should not be filed against them, but they may be +useful to some people. In particular, if you would like to work on one of these +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 X86 backend does not yet support + all inline assembly that uses the X86 + floating point stack. It supports the 'f' and 't' constraints, but not + 'u'. +
- 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 + to several + bugs in FP stackifier +
-
+
- The Linux PPC32/ABI support needs testing for the interpreter and static +compilation, and lacks support for debug information.
-
-
- none yet. +
- 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. + +
- 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.
-
-
- PowerPC backend does not correctly -implement ordered FP comparisons. +
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).
-
-
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not - support the 64-bit SPARC ABI (-m64). +
- The C backend has only basic support for + 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. +
- The C backend does not support all exception handling constructs.
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 + supported on some targets (these are used when you take the address of a + nested function).
+ +If you run into GCC extensions which are not supported, please let us know. +
+ +The C++ front-end is considered to be fully +tested and works for a number of non-trivial programs, including LLVM +itself, Qt, Mozilla, etc.
+-
-
- The ARM backend is currently in early development stages, it is not -ready for production use. +
- 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.
-
+
- 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 +which does support trampolines. +
- The Ada front-end fails to bootstrap. +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 -E binder option (exception backtraces) +does not work and will result in programs +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 +starting or finishing in the middle of a byte. +
- The lli interpreter considers +'main' as generated by the Ada binder to be invalid. +Workaround: hand edit the file to use pointers for argv and +envp rather than integers. +
- The -fstack-check option is +ignored. +
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 +Subversion 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.
@@ -680,9 +802,9 @@ lists.
+ LLVM Compiler Infrastructure
Last modified: $Date$