diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
new file mode 100644
index 00000000000..975c3a5f995
--- /dev/null
+++ b/docs/ReleaseNotes.html
@@ -0,0 +1,326 @@
+
+
LLVM 1.0 Release Notes
+
+
+
+ LLVM 1.0 Release Notes |
+
+
+
+ - Instroduction
+
- What's New?
+
- Installation Instructions
+
- Known Problems
+
+
- Additional Information
+
+
+
Written by Chris Lattner
+
+
+
+
+
+
+
+This document contains the release notes for the LLVM compiler infrastructure,
+release 1.0. The most up-to-date version of this document can be found on the
+LLVM web
+site. Since this document may be updated after the release, it is best to
+read the copy hosted there.
+
+
+
+
+
+
+This is the first public release of the LLVM compiler infrastructure. As such,
+it is all new! In particular, we are providing a stable C compiler, beta C++
+compiler, a C back-end, stable X86 and Sparc V9 static and JIT code generators,
+as well as a large suite of scalar and interprocedural optimizations.
+
+TODO: Works on: SPEC CPU 2000
+TODO: Works on: Olden/Ptrdist benchmarks
+
+
+
+
+
+
+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, so it is important to check the web version of
+this document for up-to-date information.
+
+
+
+
+
+LLVM has only been extensively tested on ia32-linux and sparc-solaris machines.
+The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
+work on more platforms than that. However, it is extremely likely that we
+missed something. We welcome portability patches and error messages.
+
+
+
+
+
+- In the JIT, dlsym on a symbol compiled by the JIT will not work.
+
+
- The JIT does not use mutexes to protect its internal data structures. As
+ such, execution of a threaded program could cause these data structures to
+ be corrupted.
+
+
- It is not possible to dlopen an LLVM bytecode file in the JIT.
+
+
+
+
+- Inline assembly is not yet supported.
+
+
- "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.
+
+
- 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 following unix system functionality has not been tested and may not work:
+
+ - sigsetjmp, siglongjmp - These are not turned into the
+ appropriate invoke/unwind instructions.
+
- 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.
+
- Labels as Values: Getting pointers to labels, and computed gotos.
+
- 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.
+
- Return Address: Getting the return or frame address of a function.
+
- 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, which 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, constructor, destructor, unused, deprecated,
+ warn_unused_result, weak
+ Ignored: noreturn, noinline, always_inline, pure, const, nothrow, malloc
+ no_instrument_function, cdecl
+ Unsupported: used, 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, 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 (ignored).
+
+
+
+ The following extensions are known to be supported:
+
+ - 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:
\e
stands 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.
+
- Unnamed Fields: Unnamed struct/union fields within structs/unions.
+
- Attribute Syntax: Formal syntax for attributes.
+
+
+ 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).
+
+
+
+
+
+For this release, the C++ front-end is considered to be of beta quality.
+It works for a large number of simple programs, but has not been extensively
+tested. We welcome bug reports though!
+
+
- The C++ front-end inherits all problems afflicting the C
+ front-end
+
+
- The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser. This
+parser is significantly more standards compliant (and picky) than prior GCC
+versions. For more information, see the C++ section of the GCC 3.4 release notes.
+
+
- Destructors for local objects are not always run when a longjmp is
+ performed. In particular, destructors for objects in the longjmping
+ function and in the setjmp receiver function may not be run.
+ Objects in intervening stack frames will be destroyed however (which is
+ better than most compilers).
+
+
- The calling conventions and name mangling used by the LLVM C++ front-end do
+ follow the Itanium C++
+ ABI, and thus we should be binary compatible with native C++ code
+ compiled with a recent GCC compiler. However, the exception handling
+ mechanisms are very different, so they will not interact correctly.
+
+
+
+
+- The X86 code generator does not currently support the unwind
+instruction, so code that throws a C++ exception or calls the C longjmp
+function will abort.
+
+
- Some executables produced by LLC seem to intermittently crash (extremely
+infrequently). The cause of the problem has not been diagnosed, and does not
+affect the JIT.
+
+
+
+
+
+- The Sparc code generator does not currently support the invoke or
+unwind instructions, so code produced by the C++ front-end and C code
+that calls the setjmp or longjmp functions will not compile.
+
+
+
+
+
+- The C back-end produces code that violates the ANSI C Type-Based Alias
+Analysis rules. As such, special options may be necessary to compile the code
+(for example, GCC requires the -fno-strict-aliasing option). This
+problem probably cannot be fixed.
+
+
- Initializers for global variables that include floating point numbers may
+not be initialized with exactly the right floating point number, if the number
+is not accurately representable in decimal. This prevents the Olden "power"
+benchmark from producing exactly the right results with the C backend.
+
+
- The code produces by the C back-end has only been tested with the Sun CC and
+GCC compilers. It is possible that it will have to be adjusted to support other
+C compilers.
+
+
+
+
+
+
+
+A wide variety of additional information is available on the LLVM web page,
+including mailing lists 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. You
+can access versions of these documents specific to this release by going into
+the "llvm/www/doc/" directory in the LLVM tree.
+
+If you have any questions or comments about LLVM, please feel free to contact us
+via the mailing lists.
+
+
+
+
+
+
+
+
+By: Chris Lattner
+
+
+Last modified: Wed Oct 1 23:56:16 CDT 2003
+
+