LLVM 1.0 Release Notes

From: Chris Lattner Date: Thu, 2 Oct 2003 04:57:28 +0000 (+0000) Subject: Initial checkin of the LLVM 1.0 release notes X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=79c3fe10080cdc0822fd2e7c77ee1cce8f273ab7;p=oota-llvm.git Initial checkin of the LLVM 1.0 release notes git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@8812 91177308-0d34-0410-b5e6-96231b3b80d8 --- 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
+

+ + + + +

+Introduction +

LLVM web +site

+What's New? +

+ +TODO: Works on: SPEC CPU 2000

+TODO: Works on: Olden/Ptrdist benchmarks + + + +

+Installation Instructions +

+ + +FIXME + + + + +

+Known Problems +

web version

Portability Problems

+ +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.

+ + + +

Known problems with the LLVM Core

+ +

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.

+ + +

Known problems with the C front-end

+ +

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). + + + +

Known problems with the C++ front-end

+ +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. + + +