llvm.org GIT mirror llvm / release_21
Merge release notes from mainline. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_21@42386 91177308-0d34-0410-b5e6-96231b3b80d8 Tanya Lattner 11 years ago
1 changed file(s) with 226 addition(s) and 397 deletion(s). Raw diff Collapse all Expand all
33
44
55
6 LLVM 2.<del>0</del> Release Notes
6 LLVM 2.<ins>1</ins> Release Notes
77
88
99
10
LLVM 2.0 Release Notes
10
LLVM 2.1 Release Notes
1111
1212
1313
  • Introduction
  • 3131
    3232
    3333

    This document contains the release notes for the LLVM compiler

    34 infrastructure, release 2.0. Here we describe the status of LLVM, including
    34 infrastructure, release 2.1. Here we describe the status of LLVM, including
    3535 major improvements from the previous release and any known problems. All LLVM
    3636 releases may be downloaded from the LLVM
    3737 releases web site.

    4343 list is a good place to send them.

    4444
    4545

    Note that if you are reading this file from a Subversion checkout or the

    46 main LLVM web page,
    47 this document applies to the next release, not the current one. To see
    48 the release notes for the current or previous releases, see the
    49 href="http://llvm.org/releases/">releases page.

    46 main LLVM web page, this document applies to the next release, not the
    47 current one. To see the release notes for a specific releases, please see the
    48 releases page.

    5049
    5150
    5251
    5857
    5958
    6059
    61

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

    62 Being the first major release since 1.0, this release is different in several
    63 ways from our previous releases:

    64
    65
    66
  • We took this as an opportunity to
  • 67 break backwards compatibility with the LLVM 1.x bytecode and .ll file format.
    68 If you have LLVM 1.9 .ll files that you would like to upgrade to LLVM 2.x, we
    69 recommend the use of the stand alone llvm-upgrade
    70 tool (which is included with 2.0). We intend to keep compatibility with .ll
    71 and .bc formats within the 2.x release series, like we did within the 1.x
    72 series.
    73
  • There are several significant change to the LLVM IR and internal APIs, such
  • 74 as a major overhaul of the type system, the completely new bitcode file
    75 format, etc (described below).
    76
  • We designed the release around a 6 month release cycle instead of the usual
  • 77 3-month cycle. This gave us extra time to develop and test some of the
    78 more invasive features in this release.
    79
  • LLVM 2.0 no longer supports the llvm-gcc3 front-end. Users are required to
  • 80 upgrade to llvm-gcc4. llvm-gcc4 includes many features over
    81 llvm-gcc3, is faster, and is much easier to
    82 build from source.
    83
    84
    85

    Note that while this is a major version bump, this release has been

    86 extensively tested on a wide range of software. It is easy to say that this
    87 is our best release yet, in terms of both features and correctness. This is
    88 the first LLVM release to correctly compile and optimize major software like
    89 LLVM itself, Mozilla/Seamonkey, Qt 4.3rc1, kOffice, etc out of the box on
    90 linux/x86.
    91

    60

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

    61 It includes many features and refinements from LLVM 2.0.

    9262
    9363
    9464
    9565
    9666
    97 New Features in LLVM 2.0
    98
    99
    100
    101
    102
    103
    104

    Changes to the LLVM IR itself:

    105
    106
    107
    108
  • Integer types are now completely signless. This means that we
  • 109 have types like i8/i16/i32 instead of ubyte/sbyte/short/ushort/int
    110 etc. LLVM operations that depend on sign have been split up into
    111 separate instructions (PR950). This
    112 eliminates cast instructions that just change the sign of the operands (e.g.
    113 int -> uint), which reduces the size of the IR and makes optimizers
    114 simpler to write.
    115
    116
  • Integer types with arbitrary bitwidths (e.g. i13, i36, i42, i1057, etc) are
  • 117 now supported in the LLVM IR and optimizations (
    118 href="http://llvm.org/PR1043">PR1043). However, neither llvm-gcc
    119 (PR1284) nor the native code generators
    120 (PR1270) support non-standard width
    121 integers yet.
    122
    123
  • 'Type planes' have been removed (PR411).
  • 124 It is no longer possible to have two values with the same name in the
    125 same symbol table. This simplifies LLVM internals, allowing significant
    126 speedups.
    127
    128
  • Global variables and functions in .ll files are now prefixed with
  • 129 @ instead of % (PR645).
    130
    131
  • The LLVM 1.x "bytecode" format has been replaced with a
  • 132 completely new binary representation, named 'bitcode'. The
    133 href="BitCodeFormat.html">Bitcode Format brings a
    134 number of advantages to the LLVM over the old bytecode format: it is denser
    135 (files are smaller), more extensible, requires less memory to read,
    136 is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc
    137 files), and has many other nice features.
    138
    139
  • Load and store instructions now track the alignment of their pointer
  • 140 (PR400). This allows the IR to
    141 express loads that are not sufficiently aligned (e.g. due to '#pragma
    142 packed') or to capture extra alignment information.
    143
    144
    145

    Major new features:

    146
    147
    148
    149
  • A number of ELF features are now supported by LLVM, including 'visibility',
  • 150 extern weak linkage, Thread Local Storage (TLS) with the __thread
    151 keyword, and symbol aliases.
    152 Among other things, this means that many of the special options needed to
    153 configure llvm-gcc on linux are no longer needed, and special hacks to build
    154 large C++ libraries like Qt are not needed.
    155
    156
  • LLVM now has a new MSIL backend. llc -march=msil will now turn LLVM
  • 157 into MSIL (".net") bytecode. This is still fairly early development
    158 with a number of limitations.
    159
    160
  • A new llvm-upgrade tool
  • 161 exists to migrates LLVM 1.9 .ll files to LLVM 2.0 syntax.
    162
    163
    164
    165
    166
    167
    168
    169 Improvements>
    67 New Frontends>
    68
    69
    70
    71
    72

    LLVM 2.1 brings two new beta C front-ends. First, a new version of llvm-gcc

    73 based on GCC 4.2, innovatively called "llvm-gcc-4.2". This promises to bring
    74 FORTRAN and Ada support to LLVM as well as features like atomic builtins and
    75 OpenMP. None of these actually work yet, but don't let that stop you checking
    76 it out!

    77
    78

    Second, LLVM now includes its own native C and Objective-C front-end (C++ is

    79 in progress, but is not very far along) code named "
    80 href="http://clang.llvm.org/">clang". This front-end has a number of great
    81 features, primarily aimed at source-level analysis and speeding up compile-time.
    82 At this point though, the LLVM Code Generator component is still very early in
    83 development, so it's mostly useful for people looking to build source-level
    84 analysis tools or source-to-source translators.

    85
    86
    87
    88
    89
    90 Optimizer Improvements
    91
    92
    93
    94
    95

    Some of the most noticable feature improvements this release have been in the

    96 optimizer, speeding it up and making it more aggressive. For example:

    97
    98
    99
    100
  • Owen Anderson wrote the new MemoryDependenceAnalysis pass, which provides
  • 101 a lazy, caching layer on top of
    102 href="AliasAnalysis.html">AliasAnalysis. He then used it to rewrite
    103 DeadStoreElimination which resulted in significantly better compile time in
    104 common cases,
    105
  • Owen implemented the new GVN pass, which is also based on
  • 106 MemoryDependenceAnalysis. This pass replaces GCSE/LoadVN in the standard
    107 set of passes, providing more aggressive optimization at a some-what
    108 improved compile-time cost.
    109
  • Owen implemented GVN-PRE, a partial redundancy elimination algorithm that
  • 110 shares some details with the new GVN pass. It is still in need of compile
    111 time tuning, and is not turned on by default.
    112
  • Devang merged ETForest and DomTree into a single easier to use data
  • 113 structure. This makes it more obvious which datastructure to choose
    114 (because there is only one) and makes the compiler more memory and time
    115 efficient (less stuff to keep up-to-date).
    116
  • Nick Lewycky improved loop trip count analysis to handle many more common
  • 117 cases.
    118
    119
    120
    121
    122
    123
    124
    125 Code Generator Improvements
    126
    127
    128
    129
    130

    One of the main focuses of this release was performance tuning and bug

    131 fixing. In addition to these, several new major changes occurred:

    132
    133
    134
    135
  • Dale finished up the Tail Merging optimization in the code generator, and
  • 136 enabled it by default. This produces smaller code that is also faster in
    137 some cases.
    138
    139
  • Christopher Lamb implemented support for virtual register sub-registers,
  • 140 which can be used to better model many forms of subregisters. As an example
    141 use, he modified the X86 backend to use this to model truncates and
    142 extends more accurately (leading to better code).
    143
    144
  • Dan Gohman changed the way we represent vectors before legalization,
  • 145 significantly simplifying the SelectionDAG representation for these and
    146 making the code generator faster for vector code.
    147
    148
  • Evan contributed a new target independent if-converter. While it is
  • 149 target independent, so far only the ARM backend uses it.
    150
    151
  • Evan rewrite the way the register allocator handles rematerialization,
  • 152 allowing it to be much more effective on two-address targets like X86,
    153 and taught it to fold loads away when possible (also a big win on X86).
    154
    155
  • Dan Gohman contributed support for better alignment and volatility handling
  • 156 in the code generator, and significantly enhanced alignment analysis for SSE
    157 load/store instructions. With his changes, an insufficiently-aligned SSE
    158 load instruction turns into movups, for example.
    159
    160
  • Duraid Madina contributed a new "bigblock" register allocator, and Roman
  • 161 Levenstein contributed several big improvements. BigBlock is optimized for
    162 code that uses very large basic blocks. It is slightly slower than the
    163 "local" allocator, but produces much better code.
    164
    165
  • David Greene refactored the register allocator to split coalescing out from
  • 166 allocation, making coalescers pluggable.
    167
    168
    169
    170
    171
    172
    173
    174
    175 Target Specific Improvements
    176
    177
    170178
    171179

    New features include:

    172180

    173181
    174182
    175
  • Precompiled Headers (PCH) are now supported.
  • 176
    177
  • "#pragma packed" is now supported, as are the various features
  • 178 described above (visibility, extern weak linkage, __thread, aliases,
    179 etc).
    180
    181
  • Tracking function parameter/result attributes is now possible.
  • 182
    183
  • Many internal enhancements have been added, such as improvements to
  • 184 NON_LVALUE_EXPR, arrays with non-zero base, structs with variable sized
    185 fields, VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, nested functions, and many other
    186 things. This is primarily to supports non-C GCC front-ends, like Ada.
    187
    188
  • It is simpler to configure llvm-gcc for linux.
  • 189
    183
  • Bruno Cardoso Lopes contributed initial MIPS support. It is sufficient to
  • 184 run many small programs, but is still incomplete and is not yet
    185 fully performant.
    186
    187
  • Bill Wendling added SSSE3 support to the X86 backend.
  • 188
    189
  • Nicholas Geoffray contributed improved linux/ppc ABI and JIT support.
  • 190
    191
  • Dale Johannesen rewrote handling of 32-bit float values in the X86 backend
  • 192 when using the floating point stack, fixing several nasty bugs.
    193
    194
  • Dan contributed rematerialization support for the X86 backend, in addition
  • 195 to several X86-specific micro optimizations.
    190196
    191197
    192198
    193199
    194
    195
    196 Improvements
    200
    201
    202
    203 llvm-gcc Improvements
    204
    197205
    198206
    199207

    New features include:

    200208

    201209
    202210
    203
  • The pass manager has been entirely
  • 204 rewritten, making it significantly smaller, simpler, and more extensible.
    205 Support has been added to run FunctionPasses interlaced with
    206 CallGraphSCCPasses, we now support loop transformations
    207 explicitly with LoopPass, and ModulePasses may now use the
    208 result of FunctionPasses.
    209
    210
  • LLVM 2.0 includes a new loop rotation pass, which converts "for loops" into
  • 211 "do/while loops", where the condition is at the bottom of the loop.
    212
    213
  • The Loop Strength Reduction pass has been improved, and we now support
  • 214 sinking expressions across blocks to reduce register pressure.
    215
    216
  • The -scalarrepl pass can now promote unions containing FP values
  • 217 into a register, it can also handle unions of vectors of the same
    218 size.
    219
    220
  • The [Post]DominatorSet classes have been removed from LLVM and clients
  • 221 switched to use the more-efficient ETForest class instead.
    222
    223
  • The ImmediateDominator class has also been removed, and clients have been
  • 224 switched to use DominatorTree instead.
    225
    226
  • The predicate simplifier pass has been improved, making it able to do
  • 227 simple value range propagation and eliminate more conditionals. However,
    228 note that predsimplify is not enabled by default in llvm-gcc.
    229
    211
  • Duncan and Anton made significant progress chasing down a number of problems
  • 212 with C++ Zero-Cost exception handling in llvm-gcc 4.0 and 4.2. It is now at
    213 the point where it "just works" on linux/X86-32 and has partial support on
    214 other targets.
    215
    216
  • Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma
  • 217 pack, and variable sized fields in structures.
    218
    219
  • Tanya implemented support for __attribute__((noinline)) in
  • 220 llvm-gcc, and added support for generic variable annotations which are
    221 propagated into the LLVM IR, e.g.
    222 "int X __attribute__((annotate("myproperty")));".
    223
    224
  • Sheng Zhou and Christopher Lamb implemented alias analysis support for
  • 225 "restrict" pointer arguments to functions.
    226
    227
  • Duncan contributed support for trampolines (taking the address of a nested
  • 228 function). Currently this is only supported on the X86-32 target.
    229
    230
  • Lauro Ramos Venancio contributed support to encode alignment info in
  • 231 load and store instructions, the foundation for other alignment-related
    232 work.
    230233
    231234
    232235
    233236
    234
    235
    236 Generator Enhancements
    237
    238
    239

    240 New features include:
    237
    238
    239
    240 LLVM Core Improvements
    241
    242
    243
    244

    New features include:

    241245

    242246
    243247
    244
    245
  • LLVM now supports software floating point, which allows LLVM to target
  • 246 chips that don't have hardware FPUs (e.g. ARM thumb mode).
    247
    248
  • A new register scavenger has been implemented, which is useful for
  • 249 finding free registers after register allocation. This is useful when
    250 rewriting frame references on RISC targets, for example.
    251
    252
  • Heuristics have been added to avoid coalescing vregs with very large live
  • 253 ranges to physregs. This was bad because it effectively pinned the physical
    254 register for the entire lifetime of the virtual register (
    255 href="http://llvm.org/PR711">PR711).
    256
    257
  • Support now exists for very simple (but still very useful)
  • 258 rematerialization the register allocator, enough to move
    259 instructions like "load immediate" and constant pool loads.
    260
    261
  • Switch statement lowering is significantly better, improving codegen for
  • 262 sparse switches that have dense subregions, and implemented support
    263 for the shift/and trick.
    264
    265
  • LLVM now supports tracking physreg sub-registers and super-registers
  • 266 in the code generator, and includes extensive register
    267 allocator changes to track them.
    268
    269
  • There is initial support for virtreg sub-registers
  • 270 (PR1350).
    271
    272
    273
    274

    275 Other improvements include:
    248
  • Neil Booth contributed a new "APFloat" class, which ensures that floating
  • 249 point representation and constant folding is not dependent on the host
    250 architecture that builds the application. This support is the foundation
    251 for "long double" support that will be wrapped up in LLVM 2.2.
    252
    253
  • Based on the APFloat class, Dale redesigned the internals of the ConstantFP
  • 254 class and has been working on extending the core and optimizer components to
    255 support various target-specific 'long double's. We expect this work to be
    256 completed in LLVM 2.2.
    257
    258
  • LLVM now provides an LLVMBuilder class, which makes it significantly easier
  • 259 to create LLVM IR instructions.
    260
    261
  • Reid contributed support for intrinsics that take arbitrary integer typed
  • 262 arguments. Dan Gohman and Chandler extended it to support arbitrary
    263 floating point arguments and vectors.
    264
    265
    266
    267
    268
    269
    270 Other Improvements
    271
    272
    273
    274

    New features include:

    276275

    277276
    278277
    279
    280
  • Inline assembly support is much more solid that before.
  • 281 The two primary features still missing are support for 80-bit floating point
    282 stack registers on X86 (PR879), and
    283 support for inline asm in the C backend (
    284 href="http://llvm.org/PR802">PR802).
    285
    286
  • DWARF debug information generation has been improved. LLVM now passes
  • 287 most of the GDB testsuite on MacOS and debug info is more dense.
    288
    289
  • Codegen support for Zero-cost DWARF exception handling has been added (
  • 290 href="http://llvm.org/PR592">PR592). It is mostly
    291 complete and just in need of continued bug fixes and optimizations at
    292 this point. However, support in llvm-g++ is disabled with an
    293 #ifdef for the 2.0 release (
    294 href="http://llvm.org/PR870">PR870).
    295
    296
  • The code generator now has more accurate and general hooks for
  • 297 describing addressing modes ("isLegalAddressingMode") to
    298 optimizations like loop strength reduction and code sinking.
    299
    300
  • Progress has been made on a direct Mach-o .o file writer. Many small
  • 301 apps work, but it is still not quite complete.
    302
    303
    304
    305

    In addition, the LLVM target description format has itself been extended in

    306 several ways:

    307
    308
    309
  • TargetData now supports better target parameterization in
  • 310 the .ll/.bc files, eliminating the 'pointersize/endianness' attributes
    311 in the files (PR761).
    312
    313
  • TargetData was generalized for finer grained alignment handling,
  • 314 handling of vector alignment, and handling of preferred alignment
    315
    316
  • LLVM now supports describing target calling conventions
  • 317 explicitly in .td files, reducing the amount of C++ code that needs
    318 to be written for a port.
    319
    320
    321
    322
    323
    324
    325
    326 Improvements
    327
    328
    329
    330

    X86-specific Code Generator Enhancements:

    331

    332
    333
    334
  • The MMX instruction set is now supported through intrinsics.
  • 335
  • The scheduler was improved to better reduce register pressure on
  • 336 X86 and other targets that are register pressure sensitive.
    337
  • Linux/x86-64 support is much better.
  • 338
  • PIC support for linux/x86 has been added.
  • 339
  • The X86 backend now supports the GCC regparm attribute.
  • 340
  • LLVM now supports inline asm with multiple constraint letters per operand
  • 341 (like "mri") which is common in X86 inline asms.
    342
    343
    344

    ARM-specific Code Generator Enhancements:

    345
    346
    347
  • The ARM code generator is now stable and fully supported.
  • 348
    349
  • There are major new features, including support for ARM
  • 350 v4-v6 chips, vfp support, soft float point support, pre/postinc support,
    351 load/store multiple generation, constant pool entry motion (to support
    352 large functions), inline asm support, weak linkage support, static
    353 ctor/dtor support and many bug fixes.
    354
    355
  • Added support for Thumb code generation (llc -march=thumb).
  • 356
    357
  • The ARM backend now supports the ARM AAPCS/EABI ABI and PIC codegen on
  • 358 arm/linux.
    359
    360
  • Several bugs were fixed for DWARF debug info generation on arm/linux.
  • 361
    362
    363
    364

    PowerPC-specific Code Generator Enhancements:

    365
    366
    367
  • The PowerPC 64 JIT now supports addressing code loaded above the 2G
  • 368 boundary.
    369
    370
  • Improved support for the Linux/ppc ABI and the linux/ppc JIT is fully
  • 371 functional now. llvm-gcc and static compilation are not fully supported
    372 yet though.
    373
    374
  • Many PowerPC 64 bug fixes.
  • 375
    376
    377
    378
    379
    380
    381
    382
    383
    384
    385

    More specific changes include:

    386
    387
    388
  • LLVM no longer relies on static destructors to shut itself down. Instead,
  • 389 it lazily initializes itself and shuts down when llvm_shutdown() is
    390 explicitly called.
    391
    392
  • LLVM now has significantly fewer static constructors, reducing startup time.
  • 393
    394
    395
  • Several classes have been refactored to reduce the amount of code that
  • 396 gets linked into apps that use the JIT.
    397
    398
  • Construction of intrinsic function declarations has been simplified.
  • 399
    400
  • The gccas/gccld tools have been replaced with small shell scripts.
  • 401
    402
  • Support has been added to llvm-test for running on low-memory
  • 403 or slow machines (make SMALL_PROBLEM_SIZE=1).
    404
    405
    406
    407
    408
    409
    410
    411
    412

    LLVM 2.0 contains a revamp of the type system and several other significant

    413 internal changes. If you are programming to the C++ API, be aware of the
    414 following major changes:

    415
    416
    417
  • Pass registration is slightly different in LLVM 2.0 (you now need an
  • 418 intptr_t in your constructor), as explained in the
    419 href="WritingAnLLVMPass.html#basiccode">Writing an LLVM Pass
    420 document.
    421
    422
  • ConstantBool, ConstantIntegral and ConstantInt
  • 423 classes have been merged together, we now just have
    424 ConstantInt.
    425
    426
  • Type::IntTy, Type::UIntTy, Type::SByteTy, ... are
  • 427 replaced by Type::Int8Ty, Type::Int16Ty, etc. LLVM types
    428 have always corresponded to fixed size types
    429 (e.g. long was always 64-bits), but the type system no longer includes
    430 information about the sign of the type. Also, the
    431 Type::isPrimitiveType() method now returns false for integers.
    432
    433
  • Several classes (CallInst, GetElementPtrInst,
  • 434 ConstantArray, etc), that once took std::vector as
    435 arguments now take ranges instead. For example, you can create a
    436 GetElementPtrInst with code like:
    437
    438
    
                      
                    
    439 Value *Ops[] = { Op1, Op2, Op3 };
    440 GEP = new GetElementPtrInst(BasePtr, Ops, 3);
    441
    442
    443 This avoids creation of a temporary vector (and a call to malloc/free). If
    444 you have an std::vector, use code like this:
    445
    
                      
                    
    446 std::vector<Value*> Ops = ...;
    447 GEP = new GetElementPtrInst(BasePtr, &Ops[0], Ops.size());
    448
    449
    450
    451
    452
  • CastInst is now abstract and its functionality is split into
  • 453 several parts, one for each of the new
    454 cast instructions.
    455
    456
  • Instruction::getNext()/getPrev() are now private (along with
  • 457 BasicBlock::getNext, etc), for efficiency reasons (they are now no
    458 longer just simple pointers). Please use BasicBlock::iterator, etc
    459 instead.
    460
    461
    462
  • Module::getNamedFunction() is now called
  • 463 Module::getFunction().
    464
    465
  • SymbolTable.h has been split into ValueSymbolTable.h and
  • 466 TypeSymbolTable.h.
    467
    468
    469
    278
  • Sterling Stein contributed a new BrainF frontend, located in llvm/examples.
  • 279 This shows a some of the more modern APIs for building a front-end, and
    280 demonstrates JIT compiler support.
    281
    282
  • David Green contributed a new --enable-expensive-checks configure
  • 283 option which enables STL checking, and fixed several bugs exposed by
    284 it.
    285
    286
    287
    470288
    471289
    472290
    529347 components, please contact us on the LLVMdev list.

    530348
    531349
    532
  • The -cee pass is known to be buggy, and may be removed in in a
  • 350
  • The -cee pass is known to be buggy, and may be removed in a
  • 533351 future release.
    534
  • C++ EH support is disabled for this release.
  • 535352
  • The MSIL backend is experimental.
  • 536353
  • The IA64 code generator is experimental.
  • 537
  • The Alpha JIT is experimental.
  • 354
  • The Alpha backend is experimental.
  • 538355
  • "-filetype=asm" (the default) is the only supported value for the
  • 539356 -filetype llc option.
    540357
    551368
    552369
  • The X86 backend does not yet support inline
  • 553370 assembly that uses the X86 floating point stack.
    371
  • The X86 backend occasionally has alignment
  • 372 problems on operating systems that don't require 16-byte stack alignment
    373 (including most non-darwin OS's like linux).
    554374
    555375
    556376
    580400
    581401
    582402
  • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
  • 583 processors, thumb program can crash or produces wrong
    403 processors, thumb programs can crash or produce wrong
    584404 results (PR1388).
    585405
  • Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
  • 586406
    660480
    661481
  • The C backend does not support inline
  • 662482 assembly code.
    483
  • The C backend does not support vectors
  • 484 yet.
    485
  • The C backend violates the ABI of common
  • 486 C++ programs, preventing intermixing between C++ compiled by the CBE and
    487 C++ code compiled with LLC or native compilers.
    663488
    664489
    665490
    699524
    700525
  • llvm-gcc partially supports these GCC extensions:

  • 701526
    702
  • Nested Functions: As in Algol and Pascal, lexical scoping of functions.
  • 703 Nested functions are supported, but llvm-gcc does not support non-local
    704 gotos or taking the address of a nested function.
    527
  • Nested Functions:
  • 528
    529 As in Algol and Pascal, lexical scoping of functions.
    530 Nested functions are supported, but llvm-gcc does not support
    531 taking the address of a nested function (except on the X86-32 target)
    532 or non-local gotos.
    705533
    706534
  • Function Attributes:
  • 707535
    711539 Supported: alias, always_inline, cdecl,
    712540 constructor, destructor,
    713541 deprecated, fastcall, format,
    714 format_arg, non_null, noreturn, regparm
    542 format_arg, non_null, noinline, noreturn, regparm
    715543 section, stdcall, unused, used,
    716544 visibility, warn_unused_result, weak
    717545
    718 Ignored: noinline, pure, const, nothrow,
    546 Ignored: pure, const, nothrow,
    719547 malloc, no_instrument_function
    720548
    721549
    793621 itself, Qt, Mozilla, etc.

    794622
    795623
    796
  • llvm-gcc4 only has partial support for C++
  • 797 Exception Handling, and it is not enabled by default.
    624
  • Exception handling only works well on the linux/X86-32 target.
  • 625 In some cases, illegally throwing an exception does not result
    626 in a call to terminate.
    798627
    799628