docs/ReleaseNotes.html

   1
   2 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   3                       "http://www.w3.org/TR/html4/strict.dtd">
   4 <html>
   5 <head>
   6   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   7   <link rel="stylesheet" href="llvm.css" type="text/css">
   8   <title>LLVM 2.3 Release Notes</title>
   9 </head>
  10 <body>
  11
  12 <div class="doc_title">LLVM 2.3 Release Notes</div>
  13
  14 <ol>
  15   <li><a href="#intro">Introduction</a></li>
  16   <li><a href="#whatsnew">What's New?</a></li>
  17   <li><a href="GettingStarted.html">Installation Instructions</a></li>
  18   <li><a href="#portability">Portability and Supported Platforms</a></li>
  19   <li><a href="#knownproblems">Known Problems</a>
  20   <li><a href="#additionalinfo">Additional Information</a></li>
  21 </ol>
  22
  23 <div class="doc_author">
  24   <p>Written by the <a href="http://llvm.org">LLVM Team</a><p>
  25 </div>
  26
  27 <!-- Done through Week-of-Mon-20080324.txt -->
  28
  29 <!-- *********************************************************************** -->
  30 <div class="doc_section">
  31   <a name="intro">Introduction</a>
  32 </div>
  33 <!-- *********************************************************************** -->
  34
  35 <div class="doc_text">
  36
  37 <p>This document contains the release notes for the LLVM compiler
  38 infrastructure, release 2.3.  Here we describe the status of LLVM, including
  39 major improvements from the previous release and any known problems.  All LLVM
  40 releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM
  41 releases web site</a>.</p>
  42
  43 <p>For more information about LLVM, including information about the latest
  44 release, please check out the <a href="http://llvm.org/">main LLVM
  45 web site</a>.  If you have questions or comments, the <a
  46 href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
  47 list</a> is a good place to send them.</p>
  48
  49 <p>Note that if you are reading this file from a Subversion checkout or the
  50 main LLVM web page, this document applies to the <i>next</i> release, not the
  51 current one.  To see the release notes for a specific releases, please see the
  52 <a href="http://llvm.org/releases/">releases page</a>.</p>
  53
  54 </div>
  55
  56 <!-- *********************************************************************** -->
  57 <div class="doc_section">
  58   <a name="whatsnew">What's New?</a>
  59 </div>
  60 <!-- *********************************************************************** -->
  61
  62 <div class="doc_text">
  63
  64 <p>This is the fourteenth public release of the LLVM Compiler Infrastructure.
  65 It includes a large number of features and refinements from LLVM 2.2.</p>
  66
  67 </div>
  68
  69 <!-- Unfinished features in 2.3:
  70   Machine LICM
  71   Machine Sinking
  72   LegalizeDAGTypes
  73  -->
  74
  75 <!--=========================================================================-->
  76 <div class="doc_subsection">
  77 <a name="changes">Major Changes in LLVM 2.3</a>
  78 </div>
  79
  80 <div class="doc_text">
  81
  82 <p>LLVM 2.2 was the last LLVM release to support llvm-gcc 4.0 and llvm-upgrade.
  83 llvm-gcc 4.0 has been replaced with llvm-gcc 4.2.  llvm-upgrade was useful for
  84 upgrading LLVM 1.9 files to LLVM 2.x syntax, but you can always use a previous
  85 LLVM release to do this.  One nice impact of this is that the LLVM regression
  86 test suite no longer depends on llvm-upgrade, which makes it run faster.</p>
  87
  88 <p>LLVM API Changes:</p>
  89
  90 <ul>
  91 <li>Several core LLVM IR classes have migrated to use 'FOOCLASS::Create(...)'
  92     instead of 'new FOOCLASS(...)' (e.g. where FOOCLASS=BasicBlock).  We hope to
  93     standardize on FOOCLASS::Create for all IR classes in the future, but not
  94     all of them have been moved over yet.</li>
  95 <li>LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to
  96    IRBuilder.</li>
  97 <li>MRegisterInfo was renamed to TargetRegisterInfo.</li>
  98 <li>The MappedFile class is gone, please use MemoryBuffer instead.</li>
  99 <li>The '-enable-eh' flag to llc has been removed.  Now code should encode
 100     whether it is safe to not generate unwind information for a function by
 101     tagging the Function object with the 'nounwind' attribute.</li>
 102
 103 </ul>
 104 </div>
 105
 106 <!--=========================================================================-->
 107 <div class="doc_subsection">
 108 <a name="majorfeatures">Major New Features</a>
 109 </div>
 110
 111 <div class="doc_text">
 112
 113 <p>LLVM 2.3 includes several major new capabilities:</p>
 114
 115 <ul>
 116 <li>Multiple Return Value Support.</li>
 117
 118
 119 <li><p>LLVM 2.3 includes a complete reimplementation of the "llvmc" tool.  It is
 120 designed to overcome several problems with the original llvmc and to provide a
 121 superset of the features of the 'gcc' driver.</p>
 122
 123 <p>The main features of llvmc2 is:</p>
 124
 125 <ul>
 126 <li>Extended handling of command line options and smart rules for
 127 dispatching them to different tools.</li>
 128 <li>Flexible (and extensible) rules for defining different tools.</li>
 129 <li>The different intermediate steps performed by tools are represented
 130 as edges in the abstract graph.</li>
 131 <li>The 'language' for driver behavior definition is tablegen and thus
 132 it's relatively easy to add new features.</li>
 133 <li>The definition of driver is transformed into set of C++ classes, thus
 134 no runtime interpretation is needed.</li>
 135 </ul>
 136 </li>
 137
 138
 139 <li>Reimplemented <a href="LinkTimeOptimization.html">LTO interface</a> in
 140  C.</li>
 141
 142
 143 <li>Kaleidoscope tutorial in Ocaml.</li>
 144
 145 </ul>
 146
 147 </div>
 148
 149
 150 <!--=========================================================================-->
 151 <div class="doc_subsection">
 152 <a name="frontends">llvm-gcc 4.2 Improvements and Clang</a>
 153 </div>
 154
 155 <div class="doc_text">
 156
 157 <p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end.</p>
 158
 159 <p>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
 160 front-end.  Objective-C now works very well on Mac OS/X.</p>
 161
 162 <p>llvm-gcc 4.2 includes many other fixes which improve conformance with the
 163 relevant parts of the GCC testsuite.</p>
 164
 165 <p>The <a href="http://clang.llvm.org/">clang project</a> is an effort to build
 166 a set of new 'llvm native' front-end technologies for the LLVM optimizer
 167 and code generator.  Currently, its C and Objective-C support is maturing
 168 nicely, and it has advanced source-to-source analysis and transformation
 169 capabilities.  If you are interested in building source-level tools for C and
 170 Objective-C (and eventually C++), you should take a look.  However, note that
 171 clang is not an official part of the LLVM 2.3 release.  If you are interested in
 172 this project, please see its <a href="http://clang.llvm.org/">web site</a>.</p>
 173
 174 </div>
 175
 176
 177 <!--=========================================================================-->
 178 <div class="doc_subsection">
 179 <a name="coreimprovements">LLVM Core Improvements</a>
 180 </div>
 181
 182 <div class="doc_text">
 183 <p>New features include:
 184 </p>
 185
 186
 187 Common linkage?
 188
 189 Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize",
 190 "__sync_val_compare_and_swap", etc
 191
 192 <ul>
 193 <li>The C and Ocaml bindings have received additional improvements. The
 194 bindings now cover pass managers, several transformation passes, iteration
 195 over the LLVM IR, target data, and parameter attribute lists.</li>
 196 </ul>
 197
 198 </div>
 199
 200 <!--=========================================================================-->
 201 <div class="doc_subsection">
 202 <a name="optimizer">Optimizer Improvements</a>
 203 </div>
 204
 205 <div class="doc_text">
 206
 207 <p>In addition to a huge array of bug fixes and minor performance tweaks, the
 208 LLVM 2.3 optimizers support a few major enhancements:</p>
 209
 210 <ul>
 211
 212 <li>Loop index set splitting on by default.<p>
 213 This transformation hoists conditions from loop bodies and reduces loop's
 214 iteration space to improve performance. For example, <p>
 215 <pre>
 216 for (i = LB; i < UB; ++i)
 217   if (i <= NV)
 218     LOOP_BODY
 219 </pre>
 220 is transformed into
 221 <pre>
 222 NUB = min(NV+1, UB)
 223 for (i = LB; i < NUB; ++i)
 224   LOOP_BODY
 225 </pre>
 226 </li>
 227
 228 <li>LLVM includes a new <tt>memcpy</tt> optimization pass removes
 229 dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and performs
 230 return slot optimization.  The LLVM optimizer now notices long sequences of
 231 consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
 232
 233 <li>Alignment detection for vector memory references and for <tt>memcpy</tt> and
 234 <tt>memset</tt> is now more aggressive.</li>
 235
 236 <li>The aggressive dead code elimination (ADCE) optimization has been rewritten
 237 to make it both faster and safer in the presence of code containing infinite
 238 loops.  Some of its prior functionality has been factored out into the loop
 239 deletion pass, which <em>is</em> safe for infinite loops.</li>
 240
 241 <li>Several optimizations have been sped up, leading to faster code generation
 242     with the same code quality.</li>
 243
 244 <li>The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
 245     functions for C-based languages, has been rewritten to be a FunctionPass
 246     instead a ModulePass.  This allows it to be run more often and to be
 247     included at -O1 in llvm-gcc.  It was also extended to include more
 248     optimizations and several corner case bugs were fixed.</li>
 249
 250 <li>LLVM now includes a simple 'Jump Threading' pass, which attempts to simplify
 251     conditional branches using information about predecessor blocks, simplifying
 252     the control flow graph.  This pass is pretty basic at this point, but catches
 253     some important cases and provides a foundation to build on.</li>
 254 </ul>
 255
 256 </div>
 257
 258 <!--=========================================================================-->
 259 <div class="doc_subsection">
 260 <a name="codegen">Code Generator Improvements</a>
 261 </div>
 262
 263 <div class="doc_text">
 264
 265 <p>We put a significant amount of work into the code generator infrastructure,
 266 which allows us to implement more aggressive algorithms and make it run
 267 faster:</p>
 268
 269 <ul>
 270 <li>MemOperand in the code generator: describe me!.</li>
 271
 272 <li>The target-independent code generator infrastructure now uses LLVM's APInt
 273     class to handle integer values, which allows it to support integer types
 274     larger than 64 bits. Note that support for such types is also dependent on
 275     target-specific support. Use of APInt is also a step toward support for
 276     non-power-of-2 integer sizes.</li>
 277
 278 <li>Several compile time speedups for code with large basic blocks.</li>
 279
 280 <li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
 281     visualization of scheduling dependency graphs easier to understand.</li>
 282
 283 <li>The code generator allows targets to write patterns that generate subreg
 284     references directly in .td files now.</li>
 285
 286 <li><tt>memcpy</tt> lowering in the backend is more aggressive, particularly for
 287     <tt>memcpy</tt> calls introduced by the code generator when handling
 288     pass-by-value structure argument copies.</li>
 289 </ul>
 290
 291 </div>
 292
 293
 294 <!--=========================================================================-->
 295 <div class="doc_subsection">
 296 <a name="x86specific">X86/X86-64 Specific Improvements</a>
 297 </div>
 298
 299 <div class="doc_text">
 300 <p>New target-specific features include:
 301 </p>
 302
 303 <ul>
 304 <li>llvm-gcc's X86-64 ABI conformance is far improved, particularly in the
 305     area of passing and returning structures by value.  llvm-gcc compiled code
 306     now interoperates very well on X86-64 systems with other compilers.</li>
 307
 308 <li>Support for Win64 was added. This includes code generation itself, JIT
 309     support and necessary changes to llvm-gcc.</li>
 310
 311 <li>The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
 312     the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins.  Various
 313     generic vector operations (insert/extract/shuffle) are much more efficient
 314     when SSE 4.1 is enabled.  The JIT automatically takes advantage of these
 315     instructions, but llvm-gcc must be explicitly told to use them, e.g. with
 316     <tt>-march=penryn</tt>.</li>
 317
 318 <li>The X86 backend now does a number of optimizations that aim to avoid
 319     converting numbers back and forth from SSE registers to the X87 floating
 320     point stack.</li>
 321
 322 <li>The X86 backend supports stack realignment, which is particularly useful for
 323     vector code on OS's without 16-byte aligned stacks.</li>
 324
 325 <li>The X86 backend now supports the "sseregparm" options in GCC, which allow
 326     functions to be tagged as passing floating point values in SSE
 327     registers.</li>
 328
 329 <li>Trampolines (taking the address of a nested function) now work on
 330     Linux/X86-64.</li>
 331
 332 <li><tt>__builtin_prefetch</tt> is now compiled into the appropriate prefetch
 333     instructions instead of being ignored.</li>
 334
 335 <li>128-bit integers are now supported on X86-64 targets.</li>
 336
 337 <li>The register allocator can now rematerialize PIC-base computations.</li>
 338
 339 </ul>
 340
 341 </div>
 342
 343 <!--=========================================================================-->
 344 <div class="doc_subsection">
 345 <a name="targetspecific">Other Target Specific Improvements</a>
 346 </div>
 347
 348 <div class="doc_text">
 349 <p>New target-specific features include:
 350 </p>
 351
 352 <ul>
 353 <li>The LLVM C backend now supports vector code.</li>
 354
 355
 356 </ul>
 357
 358 </div>
 359
 360
 361
 362 <!--=========================================================================-->
 363 <div class="doc_subsection">
 364 <a name="otherimprovements">Other Improvements</a>
 365 </div>
 366
 367 <div class="doc_text">
 368 <p>New features include:
 369 </p>
 370
 371 <ul>
 372 <li>LLVM now builds with GCC 4.3.</li>
 373 <li><tt>llvm2cpp</tt> tool has been folded into llc, use
 374     <tt>llc -march=cpp</tt></li>
 375 </ul>
 376
 377 </div>
 378
 379 <!-- *********************************************************************** -->
 380 <div class="doc_section">
 381   <a name="portability">Portability and Supported Platforms</a>
 382 </div>
 383 <!-- *********************************************************************** -->
 384
 385 <div class="doc_text">
 386
 387 <p>LLVM is known to work on the following platforms:</p>
 388
 389 <ul>
 390 <li>Intel and AMD machines (IA32) running Red Hat Linux, Fedora Core and FreeBSD
 391       (and probably other unix-like systems).</li>
 392 <li>PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and
 393     64-bit modes.</li>
 394 <li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
 395 <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
 396     support is available for native builds with Visual C++).</li>
 397 <li>Sun UltraSPARC workstations running Solaris 10.</li>
 398 <li>Alpha-based machines running Debian GNU/Linux.</li>
 399 <li>Itanium-based (IA64) machines running Linux and HP-UX.</li>
 400 </ul>
 401
 402 <p>The core LLVM infrastructure uses GNU autoconf to adapt itself
 403 to the machine and operating system on which it is built.  However, minor
 404 porting may be required to get LLVM to work on new platforms.  We welcome your
 405 portability patches and reports of successful builds or error messages.</p>
 406
 407 </div>
 408
 409 <!-- *********************************************************************** -->
 410 <div class="doc_section">
 411   <a name="knownproblems">Known Problems</a>
 412 </div>
 413 <!-- *********************************************************************** -->
 414
 415 <div class="doc_text">
 416
 417 <p>This section contains all known problems with the LLVM system, listed by
 418 component.  As new problems are discovered, they will be added to these
 419 sections.  If you run into a problem, please check the <a
 420 href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
 421 there isn't already one.</p>
 422
 423 </div>
 424
 425 <!-- ======================================================================= -->
 426 <div class="doc_subsection">
 427   <a name="experimental">Experimental features included with this release</a>
 428 </div>
 429
 430 <div class="doc_text">
 431
 432 <p>The following components of this LLVM release are either untested, known to
 433 be broken or unreliable, or are in early development.  These components should
 434 not be relied on, and bugs should not be filed against them, but they may be
 435 useful to some people.  In particular, if you would like to work on one of these
 436 components, please contact us on the <a
 437 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 438
 439 <ul>
 440 <li>The MSIL, IA64, Alpha, SPU, and MIPS backends are experimental.</li>
 441 <li>The llc "<tt>-filetype=asm</tt>" (the default) is the only supported
 442     value for this option.</li>
 443 </ul>
 444
 445 </div>
 446
 447 <!-- ======================================================================= -->
 448 <div class="doc_subsection">
 449   <a name="x86-be">Known problems with the X86 back-end</a>
 450 </div>
 451
 452 <div class="doc_text">
 453
 454 <ul>
 455   <li>The X86 backend does not yet support
 456     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
 457     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
 458     'u'.</li>
 459   <li>The X86 backend generates inefficient floating point code when configured to
 460     generate code for systems that don't have SSE2.</li>
 461   <li>Win64 code generation wasn't widely tested. Everything should work, but we
 462     expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
 463     currently due
 464     to <a href="http://llvm.org/PR2255">several</a>
 465     <a href="http://llvm.org/PR2257">bugs</a> in FP stackifier
 466 </ul>
 467
 468 </div>
 469
 470 <!-- ======================================================================= -->
 471 <div class="doc_subsection">
 472   <a name="ppc-be">Known problems with the PowerPC back-end</a>
 473 </div>
 474
 475 <div class="doc_text">
 476
 477 <ul>
 478 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
 479 compilation, and lacks support for debug information.</li>
 480 </ul>
 481
 482 </div>
 483
 484 <!-- ======================================================================= -->
 485 <div class="doc_subsection">
 486   <a name="arm-be">Known problems with the ARM back-end</a>
 487 </div>
 488
 489 <div class="doc_text">
 490
 491 <ul>
 492 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
 493 processors, thumb programs can crash or produce wrong
 494 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
 495 <li>Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
 496 </li>
 497 <li>There is a bug in QEMU-ARM (&lt;= 0.9.0) which causes it to incorrectly execute
 498 programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 499 </ul>
 500
 501 </div>
 502
 503 <!-- ======================================================================= -->
 504 <div class="doc_subsection">
 505   <a name="sparc-be">Known problems with the SPARC back-end</a>
 506 </div>
 507
 508 <div class="doc_text">
 509
 510 <ul>
 511 <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
 512     support the 64-bit SPARC ABI (-m64).</li>
 513 </ul>
 514
 515 </div>
 516
 517 <!-- ======================================================================= -->
 518 <div class="doc_subsection">
 519   <a name="alpha-be">Known problems with the Alpha back-end</a>
 520 </div>
 521
 522 <div class="doc_text">
 523
 524 <ul>
 525
 526 <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
 527 appropriate nops inserted to ensure restartability.</li>
 528
 529 </ul>
 530 </div>
 531
 532 <!-- ======================================================================= -->
 533 <div class="doc_subsection">
 534   <a name="ia64-be">Known problems with the IA64 back-end</a>
 535 </div>
 536
 537 <div class="doc_text">
 538
 539 <ul>
 540
 541 <li>C++ programs are likely to fail on IA64, as calls to <tt>setjmp</tt> are
 542 made where the argument is not 16-byte aligned, as required on IA64. (Strictly
 543 speaking this is not a bug in the IA64 back-end; it will also be encountered
 544 when building C++ programs using the C back-end.)</li>
 545
 546 <li>The C++ front-end does not use <a href="http://llvm.org/PR406">IA64
 547 ABI compliant layout of v-tables</a>.  In particular, it just stores function
 548 pointers instead of function descriptors in the vtable.  This bug prevents
 549 mixing C++ code compiled with LLVM with C++ objects compiled by other C++
 550 compilers.</li>
 551
 552 <li>There are a few ABI violations which will lead to problems when mixing LLVM
 553 output with code built with other compilers, particularly for floating-point
 554 programs.</li>
 555
 556 <li>Defining vararg functions is not supported (but calling them is OK).</li>
 557
 558 <li>The Itanium backend has bitrotted somewhat.</li>
 559 </ul>
 560
 561 </div>
 562
 563 <!-- ======================================================================= -->
 564 <div class="doc_subsection">
 565   <a name="c-be">Known problems with the C back-end</a>
 566 </div>
 567
 568 <div class="doc_text">
 569
 570 <ul>
 571 <li><a href="http://llvm.org/PR802">The C backend has only basic support for
 572     inline assembly code</a>.</li>
 573 <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
 574     C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
 575     C++ code compiled with llc or native compilers.</li>
 576 <li>The C backend does not support all exception handling constructs.</li>
 577 </ul>
 578
 579 </div>
 580
 581
 582 <!-- ======================================================================= -->
 583 <div class="doc_subsection">
 584   <a name="c-fe">Known problems with the llvm-gcc C front-end</a>
 585 </div>
 586
 587 <!-- _______________________________________________________________________ -->
 588 <div class="doc_subsubsection">Bugs</div>
 589
 590 <div class="doc_text">
 591
 592 <p>llvm-gcc does not currently support <a href="http://llvm.org/PR869">Link-Time
 593 Optimization</a> on most platforms "out-of-the-box".  Please inquire on the
 594 llvmdev mailing list if you are interested.</p>
 595
 596 <p>The only major language feature of GCC not supported by llvm-gcc is
 597     the <tt>__builtin_apply</tt> family of builtins.   However, some extensions
 598     are only supported on some targets.  For example, trampolines are only
 599     supported on some targets (these are used when you take the address of a
 600     nested function).</p>
 601
 602 <p>If you run into GCC extensions which are not supported, please let us know.
 603 </p>
 604
 605 </div>
 606
 607 <!-- ======================================================================= -->
 608 <div class="doc_subsection">
 609   <a name="c++-fe">Known problems with the llvm-gcc C++ front-end</a>
 610 </div>
 611
 612 <div class="doc_text">
 613
 614 <p>The C++ front-end is considered to be fully
 615 tested and works for a number of non-trivial programs, including LLVM
 616 itself, Qt, Mozilla, etc.</p>
 617
 618 <ul>
 619 <li>Exception handling works well on the X86 and PowerPC targets, including
 620 X86-64 darwin.  This works when linking to a libstdc++ compiled by GCC.  It is
 621 supported on X86-64 linux, but that is disabled by default in this release.</li>
 622 </ul>
 623
 624 </div>
 625
 626
 627 <!-- ======================================================================= -->
 628 <div class="doc_subsection">
 629   <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
 630 </div>
 631
 632 <div class="doc_text">
 633 The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
 634 technology and problems should be expected.
 635 <ul>
 636 <li>The Ada front-end currently only builds on X86-32.  This is mainly due
 637 to lack of trampoline support (pointers to nested functions) on other platforms,
 638 however it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
 639 which does support trampolines.</li>
 640 <li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
 641 Workaround: configure with --disable-bootstrap.</li>
 642 <li>The c380004 and <a href="http://llvm.org/PR2010">c393010</a> ACATS tests
 643 fail (c380004 also fails with gcc-4.2 mainline).  When built at -O3, the
 644 <a href="http://llvm.org/PR2421">cxg2021</a> ACATS test also fails.</li>
 645 <li>Some gcc specific Ada tests continue to crash the compiler.  The testsuite
 646 reports most tests as having failed even though they pass.</li>
 647 <li>The -E binder option (exception backtraces)
 648 <a href="http://llvm.org/PR1982">does not work</a> and will result in programs
 649 crashing if an exception is raised.  Workaround: do not use -E.</li>
 650 <li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
 651 or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
 652 or use representation clauses that result in a field of a non-discrete type
 653 starting or finishing in the middle of a byte.</li>
 654 <li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers 'main'
 655 as generated by the Ada binder to be invalid</a>.
 656 Workaround: hand edit the file to use pointers for <tt>argv</tt> and <tt>envp</tt> rather than
 657 integers.</li>
 658 <li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is ignored</a>.</li>
 659 </ul>
 660 </div>
 661
 662 <!-- *********************************************************************** -->
 663 <div class="doc_section">
 664   <a name="additionalinfo">Additional Information</a>
 665 </div>
 666 <!-- *********************************************************************** -->
 667
 668 <div class="doc_text">
 669
 670 <p>A wide variety of additional information is available on the <a
 671 href="http://llvm.org">LLVM web page</a>, in particular in the <a
 672 href="http://llvm.org/docs/">documentation</a> section.  The web page also
 673 contains versions of the API documentation which is up-to-date with the
 674 Subversion version of the source code.
 675 You can access versions of these documents specific to this release by going
 676 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
 677
 678 <p>If you have any questions or comments about LLVM, please feel free to contact
 679 us via the <a href="http://llvm.org/docs/#maillist"> mailing
 680 lists</a>.</p>
 681
 682 </div>
 683
 684 <!-- *********************************************************************** -->
 685
 686 <hr>
 687 <address>
 688   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 689   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
 690   <a href="http://validator.w3.org/check/referer"><img
 691   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 692
 693   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
 694   Last modified: $Date$
 695 </address>
 696
 697 </body>
 698 </html>