llvm.org GIT mirror llvm / 8a06c1f
Add release notes for 2.3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_23@52124 91177308-0d34-0410-b5e6-96231b3b80d8 Tanya Lattner 11 years ago
1 changed file(s) with 470 addition(s) and 199 deletion(s). Raw diff Collapse all Expand all
0
1
12 "http://www.w3.org/TR/html4/strict.dtd">
23
1112
1213
1314
  • Introduction
  • 15
  • Major Changes and Sub-project Status
  • 1416
  • What's New?
  • 1517
  • Installation Instructions
  • 1618
  • Portability and Supported Platforms
  • 2224

    Written by the LLVM Team

    2325
    2426
    25

    THIS IS A WORK IN PROGRESS FOR LLVM 2.3 (currently in

    26 progress on SVN HEAD)>
    27
    2930
    5455
    5556
    5657
    57 What's New?
    58 Major Changes and Sub-project Status
    5859
    5960
    6061
    6162
    6263
    6364

    This is the fourteenth public release of the LLVM Compiler Infrastructure.

    64 It includes many features and refinements from LLVM 2.2.

    65 It includes a large number of features and refinements from LLVM 2.2.

    6566
    6667
    6768
    6869
    7676
    77 Removed features in LLVM 2.3
    78
    79
    80
    81
    82

    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.

    86
    87
    88
    89
    90
    91 llvm-gcc 4.2 and clang
    92
    93
    94
    95
    96

    LLVM 2.3 fully supports llvm-gcc 4.2 front-end.

    97
    98

    The clang project is an effort to build

    99 a set of new 'llvm native' front-end technologies for the LLVM optimizer
    100 and code generator. Currently, its C and Objective-C support is maturing
    101 nicely, and it has advanced source-to-source analysis and transformation
    102 capabilities. If you are interested in building source-level tools for C and
    103 Objective-C (and eventually C++), you should take a look. However, note that
    104 clang is not an official part of the LLVM 2.3 release. If you are interested in
    105 this project, please see its web site.

    106
    77 Major Changes in LLVM 2.3
    78
    79
    80
    81
    82

    LLVM 2.3 no longer supports llvm-gcc 4.0, it has been replaced with

    83 llvm-gcc 4.2.

    84
    85

    LLVM 2.3 no longer includes the llvm-upgrade tool. It was useful

    86 for upgrading LLVM 1.9 files to LLVM 2.x syntax, but you can always use a
    87 previous LLVM release to do this. One nice impact of this is that the LLVM
    88 regression test suite no longer depends on llvm-upgrade, which makes it run
    89 faster.

    90
    91

    The llvm2cpp tool has been folded into llc, use

    92 llc -march=cpp instead of llvm2cpp.

    93
    94

    LLVM API Changes:

    95
    96
    97
  • Several core LLVM IR classes have migrated to use the
  • 98 'FOOCLASS::Create(...)' pattern instead of 'new
    99 FOOCLASS(...)' (e.g. where FOOCLASS=BasicBlock). We hope to
    100 standardize on FOOCLASS::Create for all IR classes in the future,
    101 but not all of them have been moved over yet.
    102
  • LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to
  • 103 IRBuilder.
    104
    105
  • MRegisterInfo was renamed to
  • 106
    107 TargetRegisterInfo.
    108
  • The MappedFile class is gone, please use
  • 109
    110 MemoryBuffer instead.
    111
  • The '-enable-eh' flag to llc has been removed. Now code should
  • 112 encode whether it is safe to omit unwind information for a function by
    113 tagging the Function object with the 'nounwind' attribute.
    114
  • The ConstantFP::get method that uses APFloat now takes one argument
  • 115 instead of two. The type argument has been removed, and the type is
    116 now inferred from the size of the given APFloat value.
    117
    118
    119
    120
    121
    122
    123 Other LLVM Sub-Projects
    124
    125
    126
    127

    128 The core LLVM 2.3 distribution currently consists of code from the core LLVM
    129 repository (which roughly contains the LLVM optimizer, code generators and
    130 supporting tools) and the llvm-gcc repository. In addition to this code, the
    131 LLVM Project includes other sub-projects that are in development. The two which
    132 are the most actively developed are the new vmkit Project
    133 and the Clang Project.
    134

    135
    136
    137
    138
    139 vmkit
    140
    141
    142
    143

    144 The "vmkit" project is a new addition to the LLVM family. It is an
    145 implementation of a JVM and a CLI Virtual Machines (Microsoft .NET is an
    146 implementation of the CLI) using the Just-In-Time compiler of LLVM.

    147
    148

    The JVM, called JnJVM, executes real-world applications such as Apache

    149 projects (e.g. Felix and Tomcat) and the SpecJVM98 benchmark. It uses the GNU
    150 Classpath project for the base classes. The CLI implementation, called N3, is
    151 its in early stages but can execute simple applications and the "pnetmark"
    152 benchmark. It uses the pnetlib project as its core library.

    153
    154

    The 'vmkit' VMs compare in performance with industrial and top open-source

    155 VMs on scientific applications. Besides the JIT, the VMs use many features of
    156 the LLVM framework, including the standard set of optimizations, atomic
    157 operations, custom function provider and memory manager for JITed methods, and
    158 specific virtual machine optimizations. vmkit is not an official part of LLVM
    159 2.3 release. It is publicly available under the LLVM license and can be
    160 downloaded from:
    161

    162
    163

    164 svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit
    165

    166
    167
    168
    169
    170
    171 Clang
    172
    173
    174
    175
    176

    The Clang project is an effort to build

    177 a set of new 'LLVM native' front-end technologies for the LLVM optimizer
    178 and code generator. Clang is continuing to make major strides forward in all
    179 areas. Its C and Objective-C parsing support is very solid, and the code
    180 generation support is far enough along to build many C applications. While not
    181 yet production quality, it is progressing very nicely. In addition, C++
    182 front-end work has started to make significant progress.

    183
    184

    At this point, Clang is most useful if you are interested in source-to-source

    185 transformations (such as refactoring) and other source-level tools for C and
    186 Objective-C. Clang now also includes tools for turning C code into pretty HTML,
    187 and includes a new static
    188 analysis tool in development. This tool focuses on automatically finding
    189 bugs in C and Objective-C code.

    190
    191
    192
    193
    194
    195
    196 What's New?
    197
    198
    199
    200
    201
    202

    LLVM 2.3 includes a huge number of bug fixes, performance tweaks and minor

    203 improvements. Some of the major improvements and new features are listed in
    204 this section.
    205

    107206
    108207
    109208
    116215

    LLVM 2.3 includes several major new capabilities:

    117216
    118217
    119
    120
    121 </div>
    218 <li>

    The biggest change in LLVM 2.3 is Multiple Return Value (MRV) support.

    219 MRVs allow LLVM IR to directly represent functions that return multiple
    220 values without having to pass them "by reference" in the LLVM IR. This
    221 allows a front-end to generate more efficient code, as MRVs are generally
    222 returned in registers if a target supports them. See the
    223 href="LangRef.html#i_getresult">LLVM IR Reference for more details.

    224
    225

    MRVs are fully supported in the LLVM IR, but are not yet fully supported in

    226 on all targets. However, it is generally safe to return up to 2 values from
    227 a function: most targets should be able to handle at least that. MRV
    228 support is a critical requirement for X86-64 ABI support, as X86-64 requires
    229 the ability to return multiple registers from functions, and we use MRVs to
    230 accomplish this in a direct way.

    231
    232
  • LLVM 2.3 includes a complete reimplementation of the "llvmc"

  • 233 tool. It is designed to overcome several problems with the original
    234 llvmc and to provide a superset of the features of the
    235 'gcc' driver.

    236
    237

    The main features of llvmc2 are:

    238
    239
  • Extended handling of command line options and smart rules for
  • 240 dispatching them to different tools.
    241
  • Flexible (and extensible) rules for defining different tools.
  • 242
  • The different intermediate steps performed by tools are represented
  • 243 as edges in the abstract graph.
    244
  • The 'language' for driver behavior definition is tablegen and thus
  • 245 it's relatively easy to add new features.
    246
  • The definition of driver is transformed into set of C++ classes, thus
  • 247 no runtime interpretation is needed.
    248

    249
    250
    251
  • LLVM 2.3 includes a completely rewritten interface for

  • 252 href="LinkTimeOptimization.html">Link Time Optimization. This interface
    253 is written in C, which allows for easier integration with C code bases, and
    254 incorporates improvements we learned about from the first incarnation of the
    255 interface.

    256
    257
  • The Kaleidoscope tutorial now

  • 258 includes a "port" of the tutorial that
    259 href="tutorial/OCamlLangImpl1.html">uses the Ocaml bindings to implement
    260 the Kaleidoscope language.

    261
    262
    263
    264
    265
    266
    267
    268
    269 llvm-gcc 4.2 Improvements
    270
    271
    272
    273
    274

    LLVM 2.3 fully supports the llvm-gcc 4.2 front-end, and includes support

    275 for the C, C++, Objective-C, Ada, and Fortran front-ends.

    276
    277

    278
    279
  • llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
  • 280 front-end. Objective-C now works very well on Mac OS/X.
    281
    282
  • Fortran EQUIVALENCEs are now supported by the gfortran front-end.
  • 283
    284
  • llvm-gcc 4.2 includes many other fixes which improve conformance with the
  • 285 relevant parts of the GCC testsuite.
    286
    287

    288
    289
    290
    122291
    123292
    124293
    130299

    131300
    132301
    133
    302
  • LLVM IR now directly represents "common" linkage, instead of representing it
  • 303 as a form of weak linkage.
    304
    305
  • LLVM IR now has support for atomic operations, and this functionality can
  • 306 be accessed through the llvm-gcc "__sync_synchronize",
    307 "__sync_val_compare_and_swap", and related builtins. Support for atomics are
    308 available in the Alpha, X86, X86-64, and PowerPC backends.
    309
    310
  • The C and Ocaml bindings have extended to cover pass managers, several
  • 311 transformation passes, iteration over the LLVM IR, target data, and parameter
    312 attribute lists.
    134313
    135314
    315
    316
    317
    318
    319 Optimizer Improvements
    320
    321
    322
    323
    324

    In addition to a huge array of bug fixes and minor performance tweaks, the

    325 LLVM 2.3 optimizers support a few major enhancements:

    326
    327
    328
    329
  • Loop index set splitting on by default.

  • 330 This transformation hoists conditions from loop bodies and reduces a loop's
    331 iteration space to improve performance. For example,

    332
    333
    
                      
                    
    334 for (i = LB; i < UB; ++i)
    335 if (i <= NV)
    336 LOOP_BODY
    337
    338
    339

    is transformed into:

    340
    341
    
                      
                    
    342 NUB = min(NV+1, UB)
    343 for (i = LB; i < NUB; ++i)
    344 LOOP_BODY
    345
    346
    347
    348
  • LLVM now includes a new memcpy optimization pass which removes
  • 349 dead memcpy calls, unneeded copies of aggregates, and performs
    350 return slot optimization. The LLVM optimizer now notices long sequences of
    351 consecutive stores and merges them into memcpy's where profitable.
    352
    353
  • Alignment detection for vector memory references and for memcpy and
  • 354 memset is now more aggressive.
    355
    356
  • The Aggressive Dead Code Elimination (ADCE) optimization has been rewritten
  • 357 to make it both faster and safer in the presence of code containing infinite
    358 loops. Some of its prior functionality has been factored out into the loop
    359 deletion pass, which is safe for infinite loops. The new ADCE pass is
    360 no longer based on control dependence, making it run faster.
    361
    362
  • The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
  • 363 functions for C-based languages, has been rewritten to be a FunctionPass
    364 instead a ModulePass. This allows it to be run more often and to be
    365 included at -O1 in llvm-gcc. It was also extended to include more
    366 optimizations and several corner case bugs were fixed.
    367
    368
  • LLVM now includes a simple 'Jump Threading' pass, which attempts to simplify
  • 369 conditional branches using information about predecessor blocks, simplifying
    370 the control flow graph. This pass is pretty basic at this point, but
    371 catches some important cases and provides a foundation to build on.
    372
    373
  • Several corner case bugs which could lead to deleting volatile memory
  • 374 accesses have been fixed.
    375
    376
  • Several optimizations have been sped up, leading to faster code generation
  • 377 with the same code quality.
    378
    379
    380
    136381
    137382
    138383
    147392 faster:

    148393
    149394
    150
  • MemOperand in the code generator.
  • 151
    152
    153
    154
    155
    156
    157 Optimizer Improvements
    158
    159
    160
    161
    162

    In addition to a huge array of bug fixes and minor performance tweaks, the

    163 LLVM 2.3 optimizers support a few major enhancements:

    164
    165
    166
    167
  • Index set splitting on by default.
  • 168
    169
    170
    171
    172
    173
    174
    175
    176 <a name="targetspecific">Target Specific Improvements
    395 <li>The code generator now has support for carrying information about memory
    396 references throughout the entire code generation process, via the
    397
    398 MachineMemOperand class. In the future this will be used to improve
    399 both pre-pass and post-pass scheduling, and to improve compiler-debugging
    400 output.
    401
    402
  • The target-independent code generator infrastructure now uses LLVM's
  • 403 APInt
    404 class to handle integer values, which allows it to support integer types
    405 larger than 64 bits (for example i128). Note that support for such types is
    406 also dependent on target-specific support. Use of APInt is also a step
    407 toward support for non-power-of-2 integer sizes.
    408
    409
  • LLVM 2.3 includes several compile time speedups for code with large basic
  • 410 blocks, particularly in the instruction selection phase, register
    411 allocation, scheduling, and tail merging/jump threading.
    412
    413
  • LLVM 2.3 includes several improvements which make llc's
  • 414 --view-sunit-dags visualization of scheduling dependency graphs
    415 easier to understand.
    416
    417
  • The code generator allows targets to write patterns that generate subreg
  • 418 references directly in .td files now.
    419
    420
  • memcpy lowering in the backend is more aggressive, particularly for
  • 421 memcpy calls introduced by the code generator when handling
    422 pass-by-value structure argument copies.
    423
    424
  • Inline assembly with multiple register results now returns those results
  • 425 directly in the appropriate registers, rather than going through memory.
    426 Inline assembly that uses constraints like "ir" with immediates now use the
    427 'i' form when possible instead of always loading the value in a register.
    428 This saves an instruction and reduces register use.
    429
    430
  • Added support for PIC/GOT style
  • 431 href="CodeGenerator.html#tailcallopt">tail calls on X86/32 and initial
    432 support for tail calls on PowerPC 32 (it may also work on PowerPC 64 but is
    433 not thoroughly tested).
    434
    435
    436
    437
    438
    439
    440
    441 X86/X86-64 Specific Improvements
    177442
    178443
    179444
    181446

    182447
    183448
    449
  • llvm-gcc's X86-64 ABI conformance is far improved, particularly in the
  • 450 area of passing and returning structures by value. llvm-gcc compiled code
    451 now interoperates very well on X86-64 systems with other compilers.
    452
    453
  • Support for Win64 was added. This includes code generation itself, JIT
  • 454 support, and necessary changes to llvm-gcc.
    455
    456
  • The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
  • 457 the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins. Various
    458 generic vector operations (insert/extract/shuffle) are much more efficient
    459 when SSE 4.1 is enabled. The JIT automatically takes advantage of these
    460 instructions, but llvm-gcc must be explicitly told to use them, e.g. with
    461 -march=penryn.
    462
    463
  • The X86 backend now does a number of optimizations that aim to avoid
  • 464 converting numbers back and forth from SSE registers to the X87 floating
    465 point stack. This is important because most X86 ABIs require return values
    466 to be on the X87 Floating Point stack, but most CPUs prefer computation in
    467 the SSE units.
    468
    469
  • The X86 backend supports stack realignment, which is particularly useful for
  • 470 vector code on OS's without 16-byte aligned stacks, such as Linux and
    471 Windows.
    472
    473
  • The X86 backend now supports the "sseregparm" options in GCC, which allow
  • 474 functions to be tagged as passing floating point values in SSE
    475 registers.
    476
    477
  • Trampolines (taking the address of a nested function) now work on
  • 478 Linux/X86-64.
    479
    480
  • __builtin_prefetch is now compiled into the appropriate prefetch
  • 481 instructions instead of being ignored.
    482
    483
  • 128-bit integers are now supported on X86-64 targets. This can be used
  • 484 through __attribute__((TImode)) in llvm-gcc.
    485
    486
  • The register allocator can now rematerialize PIC-base computations, which is
  • 487 an important optimization for register use.
    488
    489
  • The "t" and "f" inline assembly constraints for the X87 floating point stack
  • 490 now work. However, the "u" constraint is still not fully supported.
    491
    184492
    185493
    186494
    495
    496
    497
    498 Other Target Specific Improvements
    499
    500
    501
    502

    New target-specific features include:

    503

    504
    505
    506
  • The LLVM C backend now supports vector code.
  • 507
  • The Cell SPU backend includes a number of improvements. It generates better
  • 508 code and its stability/completeness is improving.
    509
    510
    511
    512
    513
    187514
    188515
    189516
    195522

    196523
    197524
    525
  • LLVM now builds with GCC 4.3.
  • 526
  • Bugpoint now supports running custom scripts (with the -run-custom
  • 527 option) to determine how to execute the command and whether it is making
    528 forward process.
    198529
    199530
    200531
    210541

    LLVM is known to work on the following platforms:

    211542
    212543
    213
  • Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD
  • 544
  • Intel and AMD machines (IA32) running Red Hat Linux, Fedora Core and FreeBSD
  • 214545 (and probably other unix-like systems).
    215546
  • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and
  • 216547 64-bit modes.
    217548
  • Intel and AMD machines running on Win32 using MinGW libraries (native).
  • 218549
  • Intel and AMD machines running on Win32 with the Cygwin libraries (limited
  • 219550 support is available for native builds with Visual C++).
    220
  • Sun UltraSPARC workstations running Solaris 8.
  • 551
  • Sun UltraSPARC workstations running Solaris 10.
  • 221552
  • Alpha-based machines running Debian GNU/Linux.
  • 222
  • Itanium-based machines running Linux and HP-UX.
  • 223
    224
    225

    The core LLVM infrastructure uses

    226 <a href="http://www.gnu.org/software/autoconf/">GNU autoconf to adapt itself
    553 <li>Itanium-based (IA64) machines running Linux and HP-UX.
    554
    555
    556

    The core LLVM infrastructure uses GNU autoconf to adapt itself

    227557 to the machine and operating system on which it is built. However, minor
    228558 porting may be required to get LLVM to work on new platforms. We welcome your
    229559 portability patches and reports of successful builds or error messages.

    262592
    263593
    264594
  • The MSIL, IA64, Alpha, SPU, and MIPS backends are experimental.
  • 265
  • The LLC "-filetype=asm" (the default) is the only supported
  • 595
  • The llc "-filetype=asm" (the default) is the only supported
  • 266596 value for this option.
    267
  • The llvmc tool is not supported.
  • 268597
    269598
    270599
    277606
    278607
    279608
    280
  • The X86 backend does not yet support inline
  • 281 assembly that uses the X86 floating point stack.
    282
  • The X86 backend occasionally has alignment
  • 283 problems on operating systems that don't require 16-byte stack alignment
    284 (including most non-darwin OS's like linux).
    285
  • The X86 backend generates inefficient floating point code when configured to
  • 286 generate code for systems that don't have SSE2.
    609
  • The X86 backend does not yet support
  • 610 all inline assembly that uses the X86
    611 floating point stack. It supports the 'f' and 't' constraints, but not
    612 'u'.
    613
  • The X86 backend generates inefficient floating point code when configured
  • 614 to generate code for systems that don't have SSE2.
    615
  • Win64 code generation wasn't widely tested. Everything should work, but we
  • 616 expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
    617 currently due
    618 to several
    619 bugs due to lack of support for the
    620 'u' inline assembly constraint and X87 floating point inline assembly.
    621
  • The X86-64 backend does not yet support position-independent code (PIC)
  • 622 generation on Linux targets.
    623
  • The X86-64 backend does not yet support the LLVM IR instruction
  • 624 va_arg. Currently, the llvm-gcc front-end supports variadic
    625 argument constructs on X86-64 by lowering them manually.
    287626
    288627
    289628
    315654 results (PR1388).
    316655
  • Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
  • 317656
    318
  • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute
  • 657
  • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly
  • 658 execute
    319659 programs compiled with LLVM. Please use more recent versions of QEMU.
    320660
    321661
    358698
    359699
    360700
    361
    362
  • C++ programs are likely to fail on IA64, as calls to setjmp are
  • 363 made where the argument is not 16-byte aligned, as required on IA64. (Strictly
    364 speaking this is not a bug in the IA64 back-end; it will also be encountered
    365 when building C++ programs using the C back-end.)
    366
    367
  • The C++ front-end does not use IA64
  • 368 ABI compliant layout of v-tables. In particular, it just stores function
    369 pointers instead of function descriptors in the vtable. This bug prevents
    370 mixing C++ code compiled with LLVM with C++ objects compiled by other C++
    371 compilers.
    372
    373
  • There are a few ABI violations which will lead to problems when mixing LLVM
  • 374 output with code built with other compilers, particularly for floating-point
    375 programs.
    376
    377
  • Defining vararg functions is not supported (but calling them is ok).
  • 378
    379
  • The Itanium backend has bitrotted somewhat.
  • 701
  • The Itanium backend is highly experimental, and has a number of known
  • 702 issues. We are looking for a maintainer for the Itanium backend. If you
    703 are interested, please contact the llvmdev mailing list.
    380704
    381705
    382706
    389713
    390714
    391715
    392
  • The C backend does not support inline
  • 393 assembly code.
    394
  • The C backend does not support vectors
  • 395 yet.
    716
  • The C backend has only basic support for
  • 717 inline assembly code.
    396718
  • The C backend violates the ABI of common
  • 397719 C++ programs, preventing intermixing between C++ compiled by the CBE and
    398 C++ code compiled with LLC or native compilers.
    720 C++ code compiled with llc or native compilers.
    399721
  • The C backend does not support all exception handling constructs.
  • 400722
    401723
    404726
    405727
    406728
    407 Known problems with the C front-end
    408
    409
    410
    411
    Bugs>
    729 Known problems with the llvm-gcc C front-end>
    730
    412731
    413732
    414733
    416735 Optimization on most platforms "out-of-the-box". Please inquire on the
    417736 llvmdev mailing list if you are interested.

    418737
    419
    420
    421
    422
    423 Notes
    424
    425
    426
    427
    428
    429
  • llvm-gcc does not support __builtin_apply yet.

  • 430 See Constructing Calls: Dispatching a call to another function.

    431
    432
    433
  • llvm-gcc partially supports these GCC extensions:

  • 434
    435
  • Nested Functions:
  • 436
    437 As in Algol and Pascal, lexical scoping of functions.
    438 Nested functions are supported, but llvm-gcc does not support
    439 taking the address of a nested function (except on X86 targets)
    440 or non-local gotos.
    441
    442
  • Function Attributes:
  • 443
    444 Declaring that functions have no side effects or that they can never
    445 return.
    446
    447 Supported: alias, always_inline, cdecl,
    448 const, constructor, destructor,
    449 deprecated, fastcall, format,
    450 format_arg, non_null, noinline,
    451 noreturn, nothrow, pure, regparm
    452 section, stdcall, unused, used,
    453 visibility, warn_unused_result, weak
    454
    455 Ignored: malloc,
    456 no_instrument_function
    457
    458
    459
    460
    461
    462

    If you run into GCC extensions which have not been included in any of these

    463 lists, please let us know (also including whether or not they work).

    464
    465
    466
    467
    468
    469 Known problems with the C++ front-end
    738

    The only major language feature of GCC not supported by llvm-gcc is

    739 the __builtin_apply family of builtins. However, some extensions
    740 are only supported on some targets. For example, trampolines are only
    741 supported on some targets (these are used when you take the address of a
    742 nested function).

    743
    744

    If you run into GCC extensions which are not supported, please let us know.

    745

    746
    747
    748
    749
    750
    751 Known problems with the llvm-gcc C++ front-end
    470752
    471753
    472754
    476758 itself, Qt, Mozilla, etc.

    477759
    478760
    479
  • Exception handling only works well on the X86 and PowerPC targets.
  • 480 It works well for x86-64 darwin but not x86-64 linux.
    481
    482
    483
    484
    485
    486
    487
    488 Known problems with the Ada front-end
    761
  • Exception handling works well on the X86 and PowerPC targets, including
  • 762 X86-64 darwin. This works when linking to a libstdc++ compiled by GCC. It is
    763 supported on X86-64 linux, but that is disabled by default in this release.
    764
    765
    766
    767
    768
    769
    770
    771 Known problems with the llvm-gcc Ada front-end
    489772
    490773
    491774
    492775 The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
    493776 technology and problems should be expected.
    494777
    495
  • The Ada front-end currently only builds on x86-32. This is mainly due
  • 778
  • The Ada front-end currently only builds on X86-32. This is mainly due
  • 496779 to lack of trampoline support (pointers to nested functions) on other platforms,
    497 however it also fails to build on x86-64
    780 however it also fails to build on X86-64
    498781 which does support trampolines.
    499782
  • The Ada front-end fails to bootstrap.
  • 500783 Workaround: configure with --disable-bootstrap.
    501784
  • The c380004 and c393010 ACATS tests
  • 502 fail (c380004 also fails with gcc-4.2 mainline).
    503
  • Many gcc specific Ada tests continue to crash the compiler.
  • 785 fail (c380004 also fails with gcc-4.2 mainline). When built at -O3, the
    786 cxg2021 ACATS test also fails.
    787
  • Some gcc specific Ada tests continue to crash the compiler. The testsuite
  • 788 reports most tests as having failed even though they pass.
    504789
  • The -E binder option (exception backtraces)
  • 505790 does not work and will result in programs
    506791 crashing if an exception is raised. Workaround: do not use -E.
    508793 or finish at a non-byte offset in a record. Workaround: do not pack records
    509794 or use representation clauses that result in a field of a non-discrete type
    510795 starting or finishing in the middle of a byte.
    511
  • The lli interpreter considers 'main'
  • 512 as generated by the Ada binder to be invalid.
    513 Workaround: hand edit the file to use pointers for argv and envp rather than
    514 integers.
    515
  • The -fstack-check option is ignored.
  • 516
    517
    518
    519
    520
    521 Known problems with the Fortran front-end
    522
    523
    524
    525
    526
    527
  • The llvm-gcc 4.2 gfortran front-end supports a broad range of Fortran code, but does
  • 528 not support EQUIVALENCE yet.
    529
    530
    531
    532
    796
  • The lli interpreter considers
  • 797 'main' as generated by the Ada binder to be invalid.
    798 Workaround: hand edit the file to use pointers for argv and
    799 envp rather than integers.
    800
  • The -fstack-check option is
  • 801 ignored.
    802
    803
    533804
    534805
    535806