docs/ReleaseNotes.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   2                       "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4 <head>
   5   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   6   <link rel="stylesheet" href="llvm.css" type="text/css">
   7   <title>LLVM 3.0 Release Notes</title>
   8 </head>
   9 <body>
  10
  11 <h1>LLVM 3.0 Release Notes</h1>
  12
  13 <img align=right src="http://llvm.org/img/DragonSmall.png"
  14     width="136" height="136" alt="LLVM Dragon Logo">
  15
  16 <ol>
  17   <li><a href="#intro">Introduction</a></li>
  18   <li><a href="#subproj">Sub-project Status Update</a></li>
  19   <li><a href="#externalproj">External Projects Using LLVM 3.0</a></li>
  20   <li><a href="#whatsnew">What's New in LLVM 3.0?</a></li>
  21   <li><a href="GettingStarted.html">Installation Instructions</a></li>
  22   <li><a href="#knownproblems">Known Problems</a></li>
  23   <li><a href="#additionalinfo">Additional Information</a></li>
  24 </ol>
  25
  26 <div class="doc_author">
  27   <p>Written by the <a href="http://llvm.org/">LLVM Team</a></p>
  28 </div>
  29
  30 <!--
  31 <h1 style="color:red">These are in-progress notes for the upcoming LLVM 3.0
  32 release.<br>
  33 You may prefer the
  34 <a href="http://llvm.org/releases/2.9/docs/ReleaseNotes.html">LLVM 2.9
  35 Release Notes</a>.</h1>
  36  -->
  37
  38 <!-- *********************************************************************** -->
  39 <h2>
  40   <a name="intro">Introduction</a>
  41 </h2>
  42 <!-- *********************************************************************** -->
  43
  44 <div>
  45
  46 <p>This document contains the release notes for the LLVM Compiler
  47    Infrastructure, release 3.0.  Here we describe the status of LLVM, including
  48    major improvements from the previous release and significant known problems.
  49    All LLVM releases may be downloaded from
  50    the <a href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
  51
  52 <p>For more information about LLVM, including information about the latest
  53    release, please check out the <a href="http://llvm.org/">main LLVM web
  54    site</a>.  If you have questions or comments,
  55    the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
  56    Developer's Mailing List</a> is a good place to send them.</p>
  57
  58 <p>Note that if you are reading this file from a Subversion checkout or the main
  59    LLVM web page, this document applies to the <i>next</i> release, not the
  60    current one.  To see the release notes for a specific release, please see the
  61    <a href="http://llvm.org/releases/">releases page</a>.</p>
  62
  63 </div>
  64
  65 <!-- Features that need text if they're finished for 3.1:
  66   ARM EHABI
  67   combiner-aa?
  68   strong phi elim
  69   loop dependence analysis
  70   CorrelatedValuePropagation
  71   lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.1.
  72  -->
  73
  74 <!-- *********************************************************************** -->
  75 <h2>
  76   <a name="subproj">Sub-project Status Update</a>
  77 </h2>
  78 <!-- *********************************************************************** -->
  79
  80 <div>
  81
  82 <p>The LLVM 3.0 distribution currently consists of code from the core LLVM
  83    repository (which roughly includes the LLVM optimizers, code generators and
  84    supporting tools), the Clang repository and the llvm-gcc repository.  In
  85    addition to this code, the LLVM Project includes other sub-projects that are
  86    in development.  Here we include updates on these subprojects.</p>
  87
  88 <!--=========================================================================-->
  89 <h3>
  90 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
  91 </h3>
  92
  93 <div>
  94
  95 <p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
  96    C++, and Objective-C languages. Clang aims to provide a better user
  97    experience through expressive diagnostics, a high level of conformance to
  98    language standards, fast compilation, and low memory use. Like LLVM, Clang
  99    provides a modular, library-based architecture that makes it suitable for
 100    creating or integrating with other development tools. Clang is considered a
 101    production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
 102    (32- and 64-bit), and for darwin/arm targets.</p>
 103
 104 <p>In the LLVM 3.0 time-frame, the Clang team has made many improvements:</p>
 105
 106 <ul>
 107   <li>Greatly improved support for building C++ applications, with greater
 108       stability and better diagnostics.</li>
 109
 110   <li><a href="http://clang.llvm.org/cxx_status.html">Improved support</a> for
 111       the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372">C++
 112       2011</a> standard, including implementations of non-static data member
 113       initializers, alias templates, delegating constructors, the range-based
 114       for loop, and implicitly-generated move constructors and move assignment
 115       operators, among others.</li>
 116
 117   <li>Implemented support for some features of the upcoming C1x standard,
 118       including static assertions and generic selections.</li>
 119
 120   <li>Better detection of include and linking paths for system headers and
 121       libraries, especially for Linux distributions.</li>
 122
 123   <li>Implemented support
 124       for <a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html">Automatic
 125       Reference Counting</a> for Objective-C.</li>
 126
 127   <li>Implemented a number of optimizations in <tt>libclang</tt>, the Clang C
 128       interface, to improve the performance of code completion and the mapping
 129       from source locations to abstract syntax tree nodes.</li>
 130 </ul>
 131
 132
 133 <p>If Clang rejects your code but another compiler accepts it, please take a
 134    look at the <a href="http://clang.llvm.org/compatibility.html">language
 135    compatibility</a> guide to make sure this is not intentional or a known
 136    issue.</p>
 137
 138 </div>
 139
 140 <!--=========================================================================-->
 141 <h3>
 142 <a name="dragonegg">DragonEgg: GCC front-ends, LLVM back-end</a>
 143 </h3>
 144
 145 <div>
 146 <p><a href="http://dragonegg.llvm.org/">DragonEgg</a> is a
 147    <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin</a> that replaces GCC's
 148    optimizers and code generators with LLVM's. Currently it requires a patched
 149    version of gcc-4.5.  The plugin can target the x86-32 and x86-64 processor
 150    families and has been used successfully on the Darwin, FreeBSD and Linux
 151    platforms.  The Ada, C, C++ and Fortran languages work well.  The plugin is
 152    capable of compiling plenty of Obj-C, Obj-C++ and Java but it is not known
 153    whether the compiled code actually works or not!</p>
 154
 155 <p>The 3.0 release has the following notable changes:</p>
 156
 157 <ul>
 158 <!--
 159 <li></li>
 160 -->
 161 </ul>
 162
 163 </div>
 164
 165 <!--=========================================================================-->
 166 <h3>
 167 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
 168 </h3>
 169
 170 <div>
 171
 172 <p>The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
 173    is a simple library that provides an implementation of the low-level
 174    target-specific hooks required by code generation and other runtime
 175    components.  For example, when compiling for a 32-bit target, converting a
 176    double to a 64-bit unsigned integer is compiled into a runtime call to the
 177    "__fixunsdfdi" function. The compiler-rt library provides highly optimized
 178    implementations of this and other low-level routines (some are 3x faster than
 179    the equivalent libgcc routines).</p>
 180
 181 <p>In the LLVM 3.0 timeframe,</p>
 182
 183 </div>
 184
 185 <!--=========================================================================-->
 186 <h3>
 187 <a name="lldb">LLDB: Low Level Debugger</a>
 188 </h3>
 189
 190 <div>
 191
 192 <p>LLDB has advanced by leaps and bounds in the 3.0 timeframe.  It is
 193    dramatically more stable and useful, and includes both a
 194    new <a href="http://lldb.llvm.org/tutorial.html">tutorial</a> and
 195    a <a href="http://lldb.llvm.org/lldb-gdb.html">side-by-side comparison with
 196    GDB</a>.</p>
 197
 198 </div>
 199
 200 <!--=========================================================================-->
 201 <h3>
 202 <a name="libc++">libc++: C++ Standard Library</a>
 203 </h3>
 204
 205 <div>
 206
 207 <p>Like compiler_rt, libc++ is now <a href="DeveloperPolicy.html#license">dual
 208    licensed</a> under the MIT and UIUC license, allowing it to be used more
 209    permissively.</p>
 210
 211 </div>
 212
 213
 214 <!--=========================================================================-->
 215 <h3>
 216 <a name="LLBrowse">LLBrowse: IR Browser</a>
 217 </h3>
 218
 219 <div>
 220
 221 <p><a href="http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html">
 222    LLBrowse</a> is an interactive viewer for LLVM modules. It can load any LLVM
 223    module and displays its contents as an expandable tree view, facilitating an
 224    easy way to inspect types, functions, global variables, or metadata nodes. It
 225    is fully cross-platform, being based on the popular wxWidgets GUI
 226    toolkit.</p>
 227
 228 </div>
 229
 230 <!--=========================================================================-->
 231 <h3>
 232 <a name="vmkit">VMKit</a>
 233 </h3>
 234
 235 <div>
 236
 237 <p>The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation
 238    of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and
 239    just-in-time compilation. As of LLVM 3.0, VMKit now supports generational
 240    garbage collectors. The garbage collectors are provided by the MMTk
 241    framework, and VMKit can be configured to use one of the numerous implemented
 242    collectors of MMTk.</p>
 243
 244 </div>
 245
 246
 247 <!--=========================================================================-->
 248 <!--
 249 <h3>
 250 <a name="klee">KLEE: A Symbolic Execution Virtual Machine</a>
 251 </h3>
 252
 253 <div>
 254 <p>
 255 <a href="http://klee.llvm.org/">KLEE</a> is a symbolic execution framework for
 256 programs in LLVM bitcode form. KLEE tries to symbolically evaluate "all" paths
 257 through the application and records state transitions that lead to fault
 258 states. This allows it to construct testcases that lead to faults and can even
 259 be used to verify some algorithms.
 260 </p>
 261
 262 <p>UPDATE!</p>
 263 </div>-->
 264
 265 </div>
 266
 267 <!-- *********************************************************************** -->
 268 <h2>
 269   <a name="externalproj">External Open Source Projects Using LLVM 3.0</a>
 270 </h2>
 271 <!-- *********************************************************************** -->
 272
 273 <div>
 274
 275 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
 276    a lot of other language and tools projects.  This section lists some of the
 277    projects that have already been updated to work with LLVM 3.0.</p>
 278
 279 <!--=========================================================================-->
 280 <h3>AddressSanitizer</h3>
 281
 282 <div>
 283
 284 <p><a href="http://code.google.com/p/address-sanitizer/">AddressSanitizer</a>
 285    uses compiler instrumentation and a specialized malloc library to find C/C++
 286    bugs such as use-after-free and out-of-bound accesses to heap, stack, and
 287    globals. The key feature of the tool is speed: the average slowdown
 288    introduced by AddressSanitizer is less than 2x.</p>
 289
 290 </div>
 291
 292 <!--=========================================================================-->
 293 <h3>ClamAV</h3>
 294
 295 <div>
 296
 297 <p><a href="http://www.clamav.net">Clam AntiVirus</a> is an open source (GPL)
 298    anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail
 299    gateways.</p>
 300
 301 <p>Since version 0.96 it
 302    has <a href="http://vrt-sourcefire.blogspot.com/2010/09/introduction-to-clamavs-low-level.html">bytecode
 303    signatures</a> that allow writing detections for complex malware.</p>
 304
 305 <p>It uses LLVM's JIT to speed up the execution of bytecode on X86, X86-64,
 306    PPC32/64, falling back to its own interpreter otherwise.  The git version was
 307    updated to work with LLVM 3.0.</p>
 308
 309 </div>
 310
 311 <!--=========================================================================-->
 312 <h3>clReflect</h3>
 313
 314 <div>
 315
 316 <p><a href="https://bitbucket.org/dwilliamson/clreflect">clReflect</a> is a C++
 317    parser that uses clang/LLVM to derive a light-weight reflection database
 318    suitable for use in game development. It comes with a very simple runtime
 319    library for loading and querying the database, requiring no external
 320    dependencies (including CRT), and an additional utility library for object
 321    management and serialisation.</p>
 322
 323 </div>
 324
 325 <!--=========================================================================-->
 326 <h3>Cling C++ Interpreter</h3>
 327
 328 <div>
 329
 330 <p><a href="http://cern.ch/cling">Cling</a> is an interactive compiler interface
 331    (aka C++ interpreter). It uses LLVM's JIT and clang; it currently supports
 332    C++ and C. It has a prompt interface, runs source files, calls into shared
 333    libraries, prints the value of expressions, even does runtime lookup of
 334    identifiers (dynamic scopes). And it just behaves like one would expect from
 335    an interpreter.</p>
 336
 337 </div>
 338
 339 <!--=========================================================================-->
 340 <!-- FIXME: Comment out
 341 <h3>Crack Programming Language</h3>
 342
 343 <div>
 344 <p>
 345 <a href="http://code.google.com/p/crack-language/">Crack</a> aims to provide the
 346 ease of development of a scripting language with the performance of a compiled
 347 language. The language derives concepts from C++, Java and Python, incorporating
 348 object-oriented programming, operator overloading and strong typing.</p>
 349 </div>
 350 -->
 351
 352 <!--=========================================================================-->
 353 <h3>Glasgow Haskell Compiler (GHC)</h3>
 354
 355 <div>
 356
 357 <p>GHC is an open source, state-of-the-art programming suite for Haskell, a
 358    standard lazy functional programming language. It includes an optimizing
 359    static compiler generating good code for a variety of platforms, together
 360    with an interactive system for convenient, quick development.</p>
 361
 362 <p>GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and
 363    later. Since LLVM 2.9, GHC now includes experimental support for the ARM
 364    platform with LLVM 3.0.</p>
 365
 366 </div>
 367
 368 <!--=========================================================================-->
 369 <h3>gwXscript</h3>
 370
 371 <div>
 372
 373 <p><a href="http://botwars.tk/gwscript/">gwXscript</a> is an object oriented,
 374    aspect oriented programming language which can create both executables (ELF,
 375    EXE) and shared libraries (DLL, SO, DYNLIB). The compiler is implemented in
 376    its own language and translates scripts into LLVM-IR which can be optimized
 377    and translated into native code by the LLVM framework. Source code in
 378    gwScript contains definitions that expand the namespaces. So you can build
 379    your project and simply 'plug out' features by removing a file. The remaining
 380    project does not leave scars since you directly separate concerns by the
 381    'template' feature of gwX. It is also possible to add new features to a
 382    project by just adding files and without editing the original project. This
 383    language is used for example to create games or content management systems
 384    that should be extendable.</p>
 385
 386 <p>gwXscript is strongly typed and offers comfort with its native types string,
 387    hash and array. You can easily write new libraries in gwXscript or native
 388    code. gwXscript is type safe and users should not be able to crash your
 389    program or execute malicious code except code that is eating CPU time.</p>
 390
 391 </div>
 392
 393 <!--=========================================================================-->
 394 <h3>include-what-you-use</h3>
 395
 396 <div>
 397
 398 <p><a href="http://code.google.com/p/include-what-you-use">include-what-you-use</a>
 399    is a tool to ensure that a file directly <code>#include</code>s
 400    all <code>.h</code> files that provide a symbol that the file uses. It also
 401    removes superfluous <code>#include</code>s from source files.</p>
 402
 403 </div>
 404
 405 <!--=========================================================================-->
 406 <h3>LanguageKit and Pragmatic Smalltalk</h3>
 407
 408 <div>
 409
 410 <p><a href="http://etoileos.com/etoile/features/languagekit/">LanguageKit</a> is
 411    a framework for implementing dynamic languages sharing an object model with
 412    Objective-C. It provides static and JIT compilation using LLVM along with
 413    its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on
 414    top of LanguageKit, that interfaces directly with Objective-C, sharing the
 415    same object representation and message sending behaviour. These projects are
 416    developed as part of the &Eacute;toi&eacute; desktop environment.</p>
 417
 418 </div>
 419
 420 <!--=========================================================================-->
 421 <h3>Mono</h3>
 422
 423 <div>
 424
 425 <p>An open source, cross-platform implementation of C# and the CLR that is
 426    binary compatible with Microsoft.NET. Has an optional, dynamically-loaded
 427    LLVM code generation backend in Mini, the JIT compiler.</p>
 428
 429 <p>Note that we use a Git mirror of LLVM with some patches. See:
 430    https://github.com/mono/llvm</p>
 431
 432 </div>
 433
 434 <!--=========================================================================-->
 435 <h3>Portable OpenCL (pocl)</h3>
 436
 437 <div>
 438
 439 <p>Portable OpenCL is an open source implementation of the OpenCL standard which
 440    can be easily adapted for new targets. One of the goals of the project is
 441    improving performance portability of OpenCL programs, avoiding the need for
 442    target-dependent manual optimizations. A "native" target is included, which
 443    allows running OpenCL kernels on the host (CPU).</p>
 444
 445 </div>
 446
 447 <!--=========================================================================-->
 448 <h3>Pure</h3>
 449
 450 <div>
 451 <p><a href="http://pure-lang.googlecode.com/">Pure</a> is an
 452   algebraic/functional programming language based on term rewriting. Programs
 453   are collections of equations which are used to evaluate expressions in a
 454   symbolic fashion. The interpreter uses LLVM as a backend to JIT-compile Pure
 455   programs to fast native code. Pure offers dynamic typing, eager and lazy
 456   evaluation, lexical closures, a hygienic macro system (also based on term
 457   rewriting), built-in list and matrix support (including list and matrix
 458   comprehensions) and an easy-to-use interface to C and other programming
 459   languages (including the ability to load LLVM bitcode modules, and inline C,
 460   C++, Fortran and Faust code in Pure programs if the corresponding LLVM-enabled
 461   compilers are installed).</p>
 462
 463 <p>Pure version 0.48 has been tested and is known to work with LLVM 3.0
 464   (and continues to work with older LLVM releases &gt;= 2.5).</p>
 465
 466 </div>
 467
 468 <!--=========================================================================-->
 469 <h3>Renderscript</h3>
 470
 471 <div>
 472
 473 <p><a href="http://developer.android.com/guide/topics/renderscript/index.html">Renderscript</a>
 474    is Android's advanced 3D graphics rendering and compute API. It provides a
 475    portable C99-based language with extensions to facilitate common use cases
 476    for enhancing graphics and thread level parallelism. The Renderscript
 477    compiler frontend is based on Clang/LLVM. It emits a portable bitcode format
 478    for the actual compiled script code, as well as reflects a Java interface for
 479    developers to control the execution of the compiled bitcode. Executable
 480    machine code is then generated from this bitcode by an LLVM backend on the
 481    device. Renderscript is thus able to provide a mechanism by which Android
 482    developers can improve performance of their applications while retaining
 483    portability.</p>
 484
 485 </div>
 486
 487 <!--=========================================================================-->
 488 <h3>SAFECode</h3>
 489
 490 <div>
 491
 492 <p><a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C/C++
 493    compiler built using LLVM.  It takes standard, unannotated C/C++ code,
 494    analyzes the code to ensure that memory accesses and array indexing
 495    operations are safe, and instruments the code with run-time checks when
 496    safety cannot be proven statically.  SAFECode can be used as a debugging aid
 497    (like Valgrind) to find and repair memory safety bugs.  It can also be used
 498    to protect code from security attacks at run-time.</p>
 499
 500 </div>
 501
 502 <!--=========================================================================-->
 503 <h3>The Stupid D Compiler (SDC)</h3>
 504
 505 <div>
 506
 507 <p><a href="https://github.com/bhelyer/SDC">The Stupid D Compiler</a> is a
 508    project seeking to write a self-hosting compiler for the D programming
 509    language without using the frontend of the reference compiler (DMD).</p>
 510
 511 </div>
 512
 513 <!--=========================================================================-->
 514 <h3>TTA-based Co-design Environment (TCE)</h3>
 515
 516 <div>
 517
 518 <p>TCE is a toolset for designing application-specific processors (ASP) based on
 519    the Transport triggered architecture (TTA). The toolset provides a complete
 520    co-design flow from C/C++ programs down to synthesizable VHDL and parallel
 521    program binaries. Processor customization points include the register files,
 522    function units, supported operations, and the interconnection network.</p>
 523
 524 <p>TCE uses Clang and LLVM for C/C++ language support, target independent
 525    optimizations and also for parts of code generation. It generates new
 526    LLVM-based code generators "on the fly" for the designed TTA processors and
 527    loads them in to the compiler backend as runtime libraries to avoid
 528    per-target recompilation of larger parts of the compiler chain.</p>
 529
 530 </div>
 531
 532 <!--=========================================================================-->
 533 <h3>Tart Programming Language</h3>
 534
 535 <div>
 536
 537 <p><a href="http://code.google.com/p/tart/">Tart</a> is a general-purpose,
 538    strongly typed programming language designed for application
 539    developers. Strongly inspired by Python and C#, Tart focuses on practical
 540    solutions for the professional software developer, while avoiding the clutter
 541    and boilerplate of legacy languages like Java and C++. Although Tart is still
 542    in development, the current implementation supports many features expected of
 543    a modern programming language, such as garbage collection, powerful
 544    bidirectional type inference, a greatly simplified syntax for template
 545    metaprogramming, closures and function literals, reflection, operator
 546    overloading, explicit mutability and immutability, and much more. Tart is
 547    flexible enough to accommodate a broad range of programming styles and
 548    philosophies, while maintaining a strong commitment to simplicity, minimalism
 549    and elegance in design.</p>
 550
 551 </div>
 552
 553 <!--=========================================================================-->
 554 <h3>ThreadSanitizer</h3>
 555
 556 <div>
 557
 558 <p><a href="http://code.google.com/p/data-race-test/">ThreadSanitizer</a> is a
 559    data race detector for (mostly) C and C++ code, available for Linux, Mac OS
 560    and Windows. On different systems, we use binary instrumentation frameworks
 561    (Valgrind and Pin) as frontends that generate the program events for the race
 562    detection algorithm. On Linux, there's an option of using LLVM-based
 563    compile-time instrumentation.</p>
 564
 565 </div>
 566
 567 <!--=========================================================================-->
 568 <h3>The ZooLib C++ Cross-Platform Application Framework</h3>
 569
 570 <div>
 571
 572 <p><a href="http://www.zoolib.org/">ZooLib</a> is Open Source under the MIT
 573    License. It provides GUI, filesystem access, TCP networking, thread-safe
 574    memory management, threading and locking for Mac OS X, Classic Mac OS,
 575    Microsoft Windows, POSIX operating systems with X11, BeOS, Haiku, Apple's iOS
 576    and Research in Motion's BlackBerry.</p>
 577
 578 <p>My current work is to use CLang's static analyzer to improve ZooLib's code
 579    quality.  I also plan to set up LLVM compiles of the demo programs and test
 580    programs using CLang and LLVM on all the platforms that CLang, LLVM and
 581    ZooLib all support.</p>
 582
 583 </div>
 584
 585 <!--=========================================================================-->
 586 <!--
 587 <h3>PinaVM</h3>
 588
 589 <div>
 590 <p><a href="http://gitorious.org/pinavm/pages/Home">PinaVM</a> is an open
 591 source, <a href="http://www.systemc.org/">SystemC</a> front-end. Unlike many
 592 other front-ends, PinaVM actually executes the elaboration of the
 593 program analyzed using LLVM's JIT infrastructure. It later enriches the
 594 bitcode with SystemC-specific information.</p>
 595 </div>
 596 -->
 597
 598
 599 <!--=========================================================================-->
 600 <!--
 601 <h3 id="icedtea">IcedTea Java Virtual Machine Implementation</h3>
 602
 603 <div>
 604 <p>
 605 <a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
 606 harness to build OpenJDK using only free software build tools and to provide
 607 replacements for the not-yet free parts of OpenJDK.  One of the extensions that
 608 IcedTea provides is a new JIT compiler named <a
 609 href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
 610 to provide native code generation without introducing processor-dependent
 611 code.
 612 </p>
 613
 614 <p> OpenJDK 7 b112, IcedTea6 1.9 and IcedTea7 1.13 and later have been tested
 615 and are known to work with LLVM 3.0 (and continue to work with older LLVM
 616 releases &gt;= 2.6 as well).</p>
 617 </div>
 618 -->
 619
 620 <!--=========================================================================-->
 621 <!--
 622 <h3>Polly - Polyhedral optimizations for LLVM</h3>
 623
 624 <div>
 625 <p>Polly is a project that aims to provide advanced memory access optimizations
 626 to better take advantage of SIMD units, cache hierarchies, multiple cores or
 627 even vector accelerators for LLVM. Built around an abstract mathematical
 628 description based on Z-polyhedra, it provides the infrastructure to develop
 629 advanced optimizations in LLVM and to connect complex external optimizers. In
 630 its first year of existence Polly already provides an exact value-based
 631 dependency analysis as well as basic SIMD and OpenMP code generation support.
 632 Furthermore, Polly can use PoCC(Pluto) an advanced optimizer for data-locality
 633 and parallelism.</p>
 634 </div>
 635 -->
 636
 637 <!--=========================================================================-->
 638 <!--
 639 <h3>Rubinius</h3>
 640
 641 <div>
 642   <p><a href="http://github.com/evanphx/rubinius">Rubinius</a> is an environment
 643   for running Ruby code which strives to write as much of the implementation in
 644   Ruby as possible. Combined with a bytecode interpreting VM, it uses LLVM to
 645   optimize and compile ruby code down to machine code. Techniques such as type
 646   feedback, method inlining, and deoptimization are all used to remove dynamism
 647   from ruby execution and increase performance.</p>
 648 </div>
 649 -->
 650
 651 <!--=========================================================================-->
 652 <!--
 653 <h3>
 654 <a name="FAUST">FAUST Real-Time Audio Signal Processing Language</a>
 655 </h3>
 656
 657 <div>
 658 <p>
 659 <a href="http://faust.grame.fr">FAUST</a> is a compiled language for real-time
 660 audio signal processing. The name FAUST stands for Functional AUdio STream. Its
 661 programming model combines two approaches: functional programming and block
 662 diagram composition. In addition with the C, C++, JAVA output formats, the
 663 Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7-3.0.</p>
 664
 665 </div>
 666 -->
 667
 668 </div>
 669
 670 <!-- *********************************************************************** -->
 671 <h2>
 672   <a name="whatsnew">What's New in LLVM 3.0?</a>
 673 </h2>
 674 <!-- *********************************************************************** -->
 675
 676 <div>
 677
 678 <p>This release includes a huge number of bug fixes, performance tweaks and
 679    minor improvements.  Some of the major improvements and new features are
 680    listed in this section.</p>
 681
 682 <!--=========================================================================-->
 683 <h3>
 684 <a name="majorfeatures">Major New Features</a>
 685 </h3>
 686
 687 <div>
 688
 689 <p>LLVM 3.0 includes several major new capabilities:</p>
 690
 691 <ul>
 692
 693 <!--
 694 <li></li>
 695 -->
 696
 697 </ul>
 698
 699 </div>
 700
 701 <!--=========================================================================-->
 702 <h3>
 703 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 704 </h3>
 705
 706 <div>
 707
 708 <p>LLVM IR has several new features for better support of new targets and that
 709    expose new optimization opportunities:</p>
 710
 711 <p>One of the biggest changes is that 3.0 has a new exception handling
 712    system. The old system used LLVM intrinsics to convey the exception handling
 713    information to the code generator. It worked in most cases, but not
 714    all. Inlining was especially difficult to get right. Also, the intrinsics
 715    could be moved away from the <code>invoke</code> instruction, making it hard
 716    to recover that information.</p>
 717
 718 <p>The new EH system makes exception handling a first-class member of the IR. It
 719    adds two new instructions:</p>
 720
 721 <ul>
 722   <li><a href="LangRef.html#i_landingpad"><code>landingpad</code></a> &mdash;
 723       this instruction defines a landing pad basic block. It contains all of the
 724       information that's needed by the code generator. It's also required to be
 725       the first non-PHI instruction in the landing pad. In addition, a landing
 726       pad may be jumped to only by the unwind edge of an <code>invoke</code>
 727       instruction.</li>
 728
 729   <li><a href="LangRef.html#i_resume"><code>resume</code></a> &mdash; this
 730       instruction causes the current exception to resume traveling up the
 731       stack. It replaces the <code>@llvm.eh.resume</code> intrinsic.</li>
 732 </ul>
 733
 734 <p>Converting from the old EH API to the new EH API is rather simple, because a
 735    lot of complexity has been removed. The two intrinsics,
 736    <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code> have been
 737    superceded by the <code>landingpad</code> instruction. Instead of generating
 738    a call to <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code>:
 739
 740 <div class="doc_code">
 741 <pre>
 742 Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
 743                                               Intrinsic::eh_exception);
 744 Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
 745                                                 Intrinsic::eh_selector);
 746
 747 // The exception pointer.
 748 Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
 749
 750 std::vector&lt;Value*&gt; Args;
 751 Args.push_back(ExnPtr);
 752 Args.push_back(Builder.CreateBitCast(Personality,
 753                                      Type::getInt8PtrTy(Context)));
 754
 755 <i>// Add selector clauses to Args.</i>
 756
 757 // The selector call.
 758 Builder.CreateCall(SlctrIntr, Args, "exc_sel");
 759 </pre>
 760 </div>
 761
 762 <p>You should instead generate a <code>landingpad</code> instruction, that
 763    returns an exception object and selector value:</p>
 764
 765 <div class="doc_code">
 766 <pre>
 767 LandingPadInst *LPadInst =
 768   Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
 769                            Personality, 0);
 770
 771 Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
 772 Builder.CreateStore(LPadExn, getExceptionSlot());
 773
 774 Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
 775 Builder.CreateStore(LPadSel, getEHSelectorSlot());
 776 </pre>
 777 </div>
 778
 779 <p>It's now trivial to add the individual clauses to the <code>landingpad</code>
 780    instruction.</p>
 781
 782 <div class="doc_code">
 783 <pre>
 784 <i><b>// Adding a catch clause</b></i>
 785 Constant *TypeInfo = getTypeInfo();
 786 LPadInst-&gt;addClause(TypeInfo);
 787
 788 <i><b>// Adding a C++ catch-all</b></i>
 789 LPadInst-&gt;addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
 790
 791 <i><b>// Adding a cleanup</b></i>
 792 LPadInst-&gt;setCleanup(true);
 793
 794 <i><b>// Adding a filter clause</b></i>
 795 std::vector&lt;Constant*&gt; TypeInfos;
 796 Constant *TypeInfo = getFilterTypeInfo();
 797 TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
 798
 799 ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
 800 LPadInst-&gt;addClause(ConstantArray::get(FilterTy, TypeInfos));
 801 </pre>
 802 </div>
 803
 804 <p>Converting from using the <code>@llvm.eh.resume</code> intrinsic to
 805    the <code>resume</code> instruction is trivial. It takes the exception
 806    pointer and exception selector values returned by
 807    the <code>landingpad</code> instruction:</p>
 808
 809 <div class="doc_code">
 810 <pre>
 811 Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
 812                                      Builder.getInt32Ty(), NULL);
 813 Value *UnwindData = UndefValue::get(UnwindDataTy);
 814 Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
 815 Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
 816 UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
 817 UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
 818 Builder.CreateResume(UnwindData);
 819 </pre>
 820 </div>
 821
 822 </div>
 823
 824 <!--=========================================================================-->
 825 <h3>
 826 <a name="optimizer">Optimizer Improvements</a>
 827 </h3>
 828
 829 <div>
 830
 831 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 832    release includes a few major enhancements and additions to the
 833    optimizers:</p>
 834
 835 <ul>
 836 <!--
 837 <li></li>
 838 -->
 839 </li>
 840
 841 </ul>
 842
 843 </div>
 844
 845 <!--=========================================================================-->
 846 <h3>
 847 <a name="mc">MC Level Improvements</a>
 848 </h3>
 849
 850 <div>
 851
 852 <p>The LLVM Machine Code (aka MC) subsystem was created to solve a number of
 853    problems in the realm of assembly, disassembly, object file format handling,
 854    and a number of other related areas that CPU instruction-set level tools work
 855    in.</p>
 856
 857 <ul>
 858 <!--
 859 <li></li>
 860 -->
 861 </ul>
 862
 863 <p>For more information, please see
 864    the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro
 865    to the LLVM MC Project Blog Post</a>.</p>
 866
 867 </div>
 868
 869 <!--=========================================================================-->
 870 <h3>
 871 <a name="codegen">Target Independent Code Generator Improvements</a>
 872 </h3>
 873
 874 <div>
 875
 876 <p>We have put a significant amount of work into the code generator
 877    infrastructure, which allows us to implement more aggressive algorithms and
 878    make it run faster:</p>
 879
 880 <ul>
 881 <!--
 882 <li></li>
 883 -->
 884 </ul>
 885 </div>
 886
 887 <!--=========================================================================-->
 888 <h3>
 889 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 890 </h3>
 891
 892 <div>
 893
 894 <p>New features and major changes in the X86 target include:</p>
 895
 896 <ul>
 897
 898   <li>The CRC32 intrinsics have been renamed.  The intrinsics were previously
 899       <code>@llvm.x86.sse42.crc32.[8|16|32]</code>
 900       and <code>@llvm.x86.sse42.crc64.[8|64]</code>. They have been renamed to
 901       <code>@llvm.x86.sse42.crc32.32.[8|16|32]</code> and
 902       <code>@llvm.x86.sse42.crc32.64.[8|64]</code>.</li>
 903
 904 </ul>
 905
 906 </div>
 907
 908 <!--=========================================================================-->
 909 <h3>
 910 <a name="ARM">ARM Target Improvements</a>
 911 </h3>
 912
 913 <div>
 914
 915 <p>New features of the ARM target include:</p>
 916
 917 <ul>
 918 <!--
 919 <li></li>
 920 -->
 921 </ul>
 922 </div>
 923
 924 <!--=========================================================================-->
 925 <h3>
 926 <a name="OtherTS">Other Target Specific Improvements</a>
 927 </h3>
 928
 929 <p>PPC32/ELF va_arg was implemented.</p>
 930 <p>PPC32 initial support for .o file writing was implemented.</p>
 931
 932 <div>
 933
 934 <ul>
 935 <!--
 936 <li></li>
 937 -->
 938 </ul>
 939
 940 </div>
 941
 942 <!--=========================================================================-->
 943 <h3>
 944 <a name="changes">Major Changes and Removed Features</a>
 945 </h3>
 946
 947 <div>
 948
 949 <p>If you're already an LLVM user or developer with out-of-tree changes based on
 950    LLVM 2.9, this section lists some "gotchas" that you may run into upgrading
 951    from the previous release.</p>
 952
 953 <ul>
 954   <li>The <code>LLVMC</code> front end code was removed while separating
 955       out language independence.</li>
 956   <li>The <code>LowerSetJmp</code> pass wasn't used effectively by any
 957       target and has been removed.</li>
 958   <li>The old <code>TailDup</code> pass was not used in the standard pipeline
 959       and was unable to update ssa form, so it has been removed.
 960   <li>The syntax of volatile loads and stores in IR has been changed to
 961       "<code>load volatile</code>"/"<code>store volatile</code>".  The old
 962       syntax ("<code>volatile load</code>"/"<code>volatile store</code>")
 963       is still accepted, but is now considered deprecated.</li>
 964   <li>The old atomic intrinscs (<code>llvm.memory.barrier</code> and
 965       <code>llvm.atomic.*</code>) are now gone.  Please use the new atomic
 966       instructions, described in the <a href="Atomics.html">atomics guide</a>.
 967 </ul>
 968
 969 <h4>Windows (32-bit)</h4>
 970 <div>
 971
 972 <ul>
 973   <li>On Win32(MinGW32 and MSVC), Windows 2000 will not be supported.
 974       Windows XP or higher is required.</li>
 975 </ul>
 976
 977 </div>
 978
 979 </div>
 980
 981 <!--=========================================================================-->
 982 <h3>
 983 <a name="api_changes">Internal API Changes</a>
 984 </h3>
 985
 986 <div>
 987
 988 <p>In addition, many APIs have changed in this release.  Some of the major
 989    LLVM API changes are:</p>
 990
 991 <ul>
 992   <li>The biggest and most pervasive change is that llvm::Type's are no longer
 993       returned or accepted as 'const' values.  Instead, just pass around
 994       non-const Type's.</li>
 995
 996   <li><code>PHINode::reserveOperandSpace</code> has been removed. Instead, you
 997       must specify how many operands to reserve space for when you create the
 998       PHINode, by passing an extra argument
 999       into <code>PHINode::Create</code>.</li>
1000
1001   <li>PHINodes no longer store their incoming BasicBlocks as operands. Instead,
1002       the list of incoming BasicBlocks is stored separately, and can be accessed
1003       with new functions <code>PHINode::block_begin</code>
1004       and <code>PHINode::block_end</code>.</li>
1005
1006   <li>Various functions now take an <code>ArrayRef</code> instead of either a
1007       pair of pointers (or iterators) to the beginning and end of a range, or a
1008       pointer and a length. Others now return an <code>ArrayRef</code> instead
1009       of a reference to a <code>SmallVector</code>
1010       or <code>std::vector</code>. These include:
1011 <ul>
1012 <!-- Please keep this list sorted. -->
1013 <li><code>CallInst::Create</code></li>
1014 <li><code>ComputeLinearIndex</code> (in <code>llvm/CodeGen/Analysis.h</code>)</li>
1015 <li><code>ConstantArray::get</code></li>
1016 <li><code>ConstantExpr::getExtractElement</code></li>
1017 <li><code>ConstantExpr::getGetElementPtr</code></li>
1018 <li><code>ConstantExpr::getInBoundsGetElementPtr</code></li>
1019 <li><code>ConstantExpr::getIndices</code></li>
1020 <li><code>ConstantExpr::getInsertElement</code></li>
1021 <li><code>ConstantExpr::getWithOperands</code></li>
1022 <li><code>ConstantFoldCall</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1023 <li><code>ConstantFoldInstOperands</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1024 <li><code>ConstantVector::get</code></li>
1025 <li><code>DIBuilder::createComplexVariable</code></li>
1026 <li><code>DIBuilder::getOrCreateArray</code></li>
1027 <li><code>ExtractValueInst::Create</code></li>
1028 <li><code>ExtractValueInst::getIndexedType</code></li>
1029 <li><code>ExtractValueInst::getIndices</code></li>
1030 <li><code>FindInsertedValue</code> (in <code>llvm/Analysis/ValueTracking.h</code>)</li>
1031 <li><code>gep_type_begin</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1032 <li><code>gep_type_end</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1033 <li><code>GetElementPtrInst::Create</code></li>
1034 <li><code>GetElementPtrInst::CreateInBounds</code></li>
1035 <li><code>GetElementPtrInst::getIndexedType</code></li>
1036 <li><code>InsertValueInst::Create</code></li>
1037 <li><code>InsertValueInst::getIndices</code></li>
1038 <li><code>InvokeInst::Create</code></li>
1039 <li><code>IRBuilder::CreateCall</code></li>
1040 <li><code>IRBuilder::CreateExtractValue</code></li>
1041 <li><code>IRBuilder::CreateGEP</code></li>
1042 <li><code>IRBuilder::CreateInBoundsGEP</code></li>
1043 <li><code>IRBuilder::CreateInsertValue</code></li>
1044 <li><code>IRBuilder::CreateInvoke</code></li>
1045 <li><code>MDNode::get</code></li>
1046 <li><code>MDNode::getIfExists</code></li>
1047 <li><code>MDNode::getTemporary</code></li>
1048 <li><code>MDNode::getWhenValsUnresolved</code></li>
1049 <li><code>SimplifyGEPInst</code> (in <code>llvm/Analysis/InstructionSimplify.h</code>)</li>
1050 <li><code>TargetData::getIndexedOffset</code></li>
1051 </ul></li>
1052
1053   <li>All forms of <code>StringMap::getOrCreateValue</code> have been remove
1054       except for the one which takes a <code>StringRef</code>.</li>
1055
1056   <li>The <code>LLVMBuildUnwind</code> function from the C API was removed. The
1057       LLVM <code>unwind</code> instruction has been deprecated for a long time
1058       and isn't used by the current front-ends. So this was removed during the
1059       exception handling rewrite.</li>
1060
1061   <li>The <code>LLVMAddLowerSetJmpPass</code> function from the C API was
1062       removed because the <code>LowerSetJmp</code> pass was removed.</li>
1063
1064   <li>The <code>DIBuilder</code> interface used by front ends to encode
1065       debugging information in the LLVM IR now expects clients to
1066       use <code>DIBuilder::finalize()</code> at the end of translation unit to
1067       complete debugging information encoding.</li>
1068
1069   <li>The way the type system works has been
1070       rewritten: <code>PATypeHolder</code> and <code>OpaqueType</code> are gone,
1071       and all APIs deal with <code>Type*</code> instead of <code>const
1072       Type*</code>.  If you need to create recursive structures, then create a
1073       named structure, and use <code>setBody()</code> when all its elements are
1074       built.  Type merging and refining is gone too: named structures are not
1075       merged with other structures, even if their layout is identical.  (of
1076       course anonymous structures are still uniqued by layout).</li>
1077
1078   <li>TargetSelect.h moved to Support/ from Target/</li>
1079
1080   <li>UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for
1081       example <code>llvm.memset.i32</code>).</li>
1082
1083   <li>It is mandatory to initialize all out-of-tree passes too and their dependencies now with
1084       <code>INITIALIZE_PASS{BEGIN,END,}</code>
1085       and <code>INITIALIZE_{PASS,AG}_DEPENDENCY</code>.</li>
1086
1087   <li>The interface for MemDepResult in MemoryDependenceAnalysis has been
1088       enhanced with new return types Unknown and NonFuncLocal, in addition to
1089       the existing types Clobber, Def, and NonLocal.</li>
1090 </ul>
1091
1092 </div>
1093
1094 </div>
1095
1096 <!-- *********************************************************************** -->
1097 <h2>
1098   <a name="knownproblems">Known Problems</a>
1099 </h2>
1100 <!-- *********************************************************************** -->
1101
1102 <div>
1103
1104 <p>This section contains significant known problems with the LLVM system, listed
1105    by component.  If you run into a problem, please check
1106    the <a href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
1107    there isn't already one.</p>
1108
1109 <!-- ======================================================================= -->
1110 <h3>
1111   <a name="experimental">Experimental features included with this release</a>
1112 </h3>
1113
1114 <div>
1115
1116 <p>The following components of this LLVM release are either untested, known to
1117    be broken or unreliable, or are in early development.  These components
1118    should not be relied on, and bugs should not be filed against them, but they
1119    may be useful to some people.  In particular, if you would like to work on
1120    one of these components, please contact us on
1121    the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev
1122    list</a>.</p>
1123
1124 <ul>
1125   <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and
1126       XCore backends are experimental.</li>
1127
1128   <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets other
1129       than darwin and ELF X86 systems.</li>
1130 </ul>
1131
1132 </div>
1133
1134 <!-- ======================================================================= -->
1135 <h3>
1136   <a name="x86-be">Known problems with the X86 back-end</a>
1137 </h3>
1138
1139 <div>
1140
1141 <ul>
1142   <li>The X86 backend does not yet support
1143       all <a href="http://llvm.org/PR879">inline assembly that uses the X86
1144       floating point stack</a>.  It supports the 'f' and 't' constraints, but
1145       not 'u'.</li>
1146
1147   <li>The X86-64 backend does not yet support the LLVM IR instruction
1148       <tt>va_arg</tt>. Currently, front-ends support variadic argument
1149       constructs on X86-64 by lowering them manually.</li>
1150
1151   <li>Windows x64 (aka Win64) code generator has a few issues.
1152     <ul>
1153       <li>llvm-gcc cannot build the mingw-w64 runtime currently due to lack of
1154           support for the 'u' inline assembly constraint and for X87 floating
1155           point inline assembly.</li>
1156
1157       <li>On mingw-w64, you will see unresolved symbol <tt>__chkstk</tt> due
1158           to <a href="http://llvm.org/bugs/show_bug.cgi?id=8919">Bug 8919</a>.
1159           It is fixed
1160           in <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110321/118499.html">r128206</a>.</li>
1161
1162       <li>Miss-aligned MOVDQA might crash your program. It is due to
1163           <a href="http://llvm.org/bugs/show_bug.cgi?id=9483">Bug 9483</a>, lack
1164           of handling aligned internal globals.</li>
1165       </ul>
1166   </li>
1167
1168 </ul>
1169
1170 </div>
1171
1172 <!-- ======================================================================= -->
1173 <h3>
1174   <a name="ppc-be">Known problems with the PowerPC back-end</a>
1175 </h3>
1176
1177 <div>
1178
1179 <ul>
1180   <li>The PPC32/ELF support lacks PIC support.</li>
1181 </ul>
1182
1183 </div>
1184
1185 <!-- ======================================================================= -->
1186 <h3>
1187   <a name="arm-be">Known problems with the ARM back-end</a>
1188 </h3>
1189
1190 <div>
1191
1192 <ul>
1193   <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
1194       processors, thumb programs can crash or produce wrong results
1195       (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
1196
1197   <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully
1198       tested.</li>
1199 </ul>
1200
1201 </div>
1202
1203 <!-- ======================================================================= -->
1204 <h3>
1205   <a name="sparc-be">Known problems with the SPARC back-end</a>
1206 </h3>
1207
1208 <div>
1209
1210 <ul>
1211   <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
1212       support the 64-bit SPARC ABI (-m64).</li>
1213 </ul>
1214
1215 </div>
1216
1217 <!-- ======================================================================= -->
1218 <h3>
1219   <a name="mips-be">Known problems with the MIPS back-end</a>
1220 </h3>
1221
1222 <div>
1223
1224 <ul>
1225   <li>64-bit MIPS targets are not supported yet.</li>
1226 </ul>
1227
1228 </div>
1229
1230 <!-- ======================================================================= -->
1231 <h3>
1232   <a name="alpha-be">Known problems with the Alpha back-end</a>
1233 </h3>
1234
1235 <div>
1236
1237 <ul>
1238   <li>On 21164s, some rare FP arithmetic sequences which may trap do not have
1239       the appropriate nops inserted to ensure restartability.</li>
1240 </ul>
1241
1242 </div>
1243
1244 <!-- ======================================================================= -->
1245 <h3>
1246   <a name="c-be">Known problems with the C back-end</a>
1247 </h3>
1248
1249 <div>
1250
1251 <p>The C backend has numerous problems and is not being actively maintained.
1252    Depending on it for anything serious is not advised.</p>
1253
1254 <ul>
1255   <li><a href="http://llvm.org/PR802">The C backend has only basic support for
1256       inline assembly code</a>.</li>
1257
1258   <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
1259       C++ programs</a>, preventing intermixing between C++ compiled by the CBE
1260       and C++ code compiled with <tt>llc</tt> or native compilers.</li>
1261
1262   <li>The C backend does not support all exception handling constructs.</li>
1263
1264   <li>The C backend does not support arbitrary precision integers.</li>
1265 </ul>
1266
1267 </div>
1268
1269
1270 <!-- ======================================================================= -->
1271 <h3>
1272   <a name="llvm-gcc">Known problems with the llvm-gcc front-end</a>
1273 </h3>
1274
1275 <div>
1276
1277 <p><b>LLVM 2.9 was the last release of llvm-gcc.</b></p>
1278
1279 <p>llvm-gcc is generally very stable for the C family of languages.  The only
1280    major language feature of GCC not supported by llvm-gcc is the
1281    <tt>__builtin_apply</tt> family of builtins.   However, some extensions
1282    are only supported on some targets.  For example, trampolines are only
1283    supported on some targets (these are used when you take the address of a
1284    nested function).</p>
1285
1286 <p>Fortran support generally works, but there are still several unresolved bugs
1287    in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
1288    tools/gfortran component for details.  Note that llvm-gcc is missing major
1289    Fortran performance work in the frontend and library that went into GCC after
1290    4.2.  If you are interested in Fortran, we recommend that you consider using
1291    <a href="#dragonegg">dragonegg</a> instead.</p>
1292
1293 <p>The llvm-gcc 4.2 Ada compiler has basic functionality, but is no longer being
1294    actively maintained.  If you are interested in Ada, we recommend that you
1295    consider using <a href="#dragonegg">dragonegg</a> instead.</p>
1296
1297 </div>
1298
1299 </div>
1300
1301 <!-- *********************************************************************** -->
1302 <h2>
1303   <a name="additionalinfo">Additional Information</a>
1304 </h2>
1305 <!-- *********************************************************************** -->
1306
1307 <div>
1308
1309 <p>A wide variety of additional information is available on
1310    the <a href="http://llvm.org/">LLVM web page</a>, in particular in
1311    the <a href="http://llvm.org/docs/">documentation</a> section.  The web page
1312    also contains versions of the API documentation which is up-to-date with the
1313    Subversion version of the source code.  You can access versions of these
1314    documents specific to this release by going into the "<tt>llvm/doc/</tt>"
1315    directory in the LLVM tree.</p>
1316
1317 <p>If you have any questions or comments about LLVM, please feel free to contact
1318    us via the <a href="http://llvm.org/docs/#maillist"> mailing lists</a>.</p>
1319
1320 </div>
1321
1322 <!-- *********************************************************************** -->
1323
1324 <hr>
1325 <address>
1326   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1327   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1328   <a href="http://validator.w3.org/check/referer"><img
1329   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1330
1331   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1332   Last modified: $Date$
1333 </address>
1334
1335 </body>
1336 </html>