i686-linux-gnu-4.7/usr/share/doc/gcc-4.7-base/NEWS.html

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2   <!DOCTYPE html
   3             PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   4             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19      <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  20
  21
  22    <head>
  23
  24     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  25     <link rev="made" href="mailto:gcc@gcc.gnu.org" />
  26     <link rel="shortcut icon" href="http://gcc.gnu.org/favicon.ico" />
  27     <link rel="stylesheet" type="text/css" href="http://gcc.gnu.org/gcc.css" />
  28
  29  <title>
  30 GCC 4.7 Release Series &mdash; Changes, New Features, and Fixes
  31 - GNU Project - Free Software Foundation (FSF)</title>
  32    </head>
  33
  34
  35 <!-- GCC maintainers, please do not hesitate to update/contribute entries
  36      concerning those part of GCC you maintain!  2002-03-23, Gerald.
  37 -->
  38
  39 <body>
  40
  41
  42
  43 <h1>GCC 4.7 Release Series<br />Changes, New Features, and Fixes</h1>
  44
  45
  46 <h2>Caveats</h2>
  47
  48   <ul>
  49     <li><p>The <code>-fconserve-space</code> flag has been
  50     deprecated.  The flag had no effect for most targets: only
  51     targets without a global <code>.bss</code> section and without
  52     support for switchable sections.  Furthermore, the flag only
  53     had an effect for G++, where it could result in wrong semantics
  54     (please refer to the GCC manual for further details).
  55     The flag will be removed in GCC 4.8</p></li>
  56
  57     <li><p>Support for a number of older systems and recently
  58     unmaintained or untested target ports of GCC has been declared
  59     obsolete in GCC 4.7.  Unless there is activity to revive them, the
  60     next release of GCC will have their sources permanently
  61     <strong>removed</strong>.</p>
  62
  63     <p id="obsoleted">All GCC ports for the following processor
  64     architectures have been declared obsolete:</p>
  65
  66     <ul>
  67           <li>picoChip (<code>picochip-*</code>)</li>
  68     </ul>
  69
  70     <p>The following ports for individual systems on
  71     particular architectures have been obsoleted:</p>
  72
  73     <ul>
  74           <li>IRIX 6.5 (mips-sgi-irix6.5)</li>
  75           <li>MIPS OpenBSD (mips*-*-openbsd*)</li>
  76           <li>Solaris 8 (*-*-solaris2.8).  Details can be found in the
  77           <a href="http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01263.html">
  78               announcement</a>.</li>
  79           <li>Tru64 UNIX V5.1 (alpha*-dec-osf5.1*)</li>
  80     </ul>
  81
  82     </li>
  83
  84     <li>On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A,
  85     ARMv7-R, or ARMv7-M, the new option
  86     <code>-munaligned-access</code> is active by default, which for
  87     some source codes generates code that accesses memory on unaligned
  88     addresses.  This will require the kernel of those systems to enable
  89     such accesses (controlled by CP15 register <code>c1</code>, refer
  90     to ARM documentation).  Alternatively or for compatibility with
  91     kernels where unaligned accesses are not supported, all code has
  92     to be compiled with <code>-mno-unaligned-access</code>.
  93     Linux/ARM in official releases has automatically and
  94     unconditionally supported unaligned accesses as emitted by GCC due
  95     to this option being active, since Linux version 2.6.28.</li>
  96
  97     <li>Support on ARM for the legacy floating-point accelerator (FPA) and
  98     the mixed-endian floating-point format that it used has been obsoleted.
  99     The ports that still use this format have been obsoleted as well.
 100     Many legacy ARM ports already provide an alternative that uses the
 101     VFP floating-point format.  The obsolete ports will be deleted in the
 102     next release.
 103
 104     <p>The obsolete ports with alternatives are:</p>
 105
 106     <ul>
 107           <li>arm*-*-rtems (use arm*-*-rtemseabi)</li>
 108           <li>arm*-*-linux-gnu (use arm*-*-linux-gnueabi)</li>
 109           <li>arm*-*-elf (use arm*-*-eabi)</li>
 110           <li>arm*-*-uclinux* (use arm*-*-uclinux*eabi)</li>
 111     </ul>
 112     <p>Note, however, that these alternatives are not binary compatible
 113     with their legacy counterparts (although some can support running legacy
 114     applications).</p>
 115     <p>The obsolete ports that currently lack a modern alternative are:</p>
 116
 117     <ul>
 118           <li>arm*-*-ecos-elf</li>
 119           <li>arm*-*-freebsd</li>
 120           <li>arm*-wince-pe*</li>
 121     </ul>
 122
 123     New ports that support more recent versions of the architecture
 124     are welcome.</li>
 125     <li>Support for the Maverick co-processor on ARM has been obsoleted.
 126     Code to support it will be deleted in the next release.</li>
 127     <li>Support has been removed for Unix International threads on Solaris
 128     2, so the <code>--enable-threads=solaris</code> configure option and
 129     the <code>-threads</code> compiler option don't work any longer.</li>
 130     <li>Support has been removed for the Solaris BSD Compatibility Package,
 131     which lives in <code>/usr/ucbinclude</code> and
 132     <code>/usr/ucblib</code>.  It has been removed from Solaris 11, and was
 133     only intended as a migration aid from SunOS 4 to SunOS 5.  The
 134     <code>-compat-bsd</code> compiler option is not recognized any
 135     longer.</li>
 136
 137     <li>The AVR port's libgcc has been improved and its multilib structure
 138       has been enhanced.  As a result, all objects contributing to an
 139       application must either be compiled with GCC versions up to 4.6.x or
 140       with GCC versions 4.7.0 or later.</li>
 141
 142     <li>The ARM port's <code>-mwords-little-endian</code> option has
 143     been deprecated.  It will be removed in a future release.</li>
 144
 145     <li>Support has been removed for the NetWare x86 configuration
 146     obsoleted in GCC 4.6.</li>
 147
 148     <li>It is no longer possible to use the <code>"l"</code>
 149     constraint in MIPS16 <code>asm</code> statements.</li>
 150
 151     <li>GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library
 152     which affected the ABI in C++11 mode: a data member was added to
 153     <code>std::list</code> changing its size and altering the definitions of
 154     some member functions, and <code>std::pair</code>'s move constructor was
 155     non-trivial which altered the calling convention for functions with
 156     <code>std::pair</code> arguments or return types.  The ABI incompatibilities
 157     have been fixed for GCC version 4.7.2 but as a result C++11 code compiled
 158     with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with
 159     different GCC versions and with C++98/C++03 code compiled with any version.
 160     </li>
 161
 162     <li>On ARM, a bug has been fixed in GCC's implementation of the AAPCS
 163     rules for the layout of vectors that could lead to wrong code being
 164     generated.  Vectors larger than 8 bytes in size are now by default
 165     aligned to an 8-byte boundary.  This is an ABI change: code that makes
 166     explicit use of vector types may be incompatible with binary objects
 167     built with older versions of GCC.  Auto-vectorized code is not affected
 168     by this change.  (This change affects GCC versions 4.7.2 and later.)</li>
 169
 170     <li>More information on porting to GCC 4.7 from previous versions
 171     of GCC can be found in
 172     the <a href="http://gcc.gnu.org/gcc-4.7/porting_to.html">porting
 173     guide</a> for this release.</li>
 174   </ul>
 175
 176
 177 <h2>General Optimizer Improvements</h2>
 178
 179   <ul>
 180     <li>Support for a new parameter <code>--param case-values-threshold=n</code>
 181     was added to allow users to control the cutoff between doing switch statements
 182     as a series of if statements and using a jump table.
 183     </li>
 184
 185     <li>Link-time optimization (LTO) improvements:
 186     <ul>
 187       <li>Improved scalability and reduced memory usage.  Link time
 188       optimization of Firefox now requires 3GB of RAM on a 64-bit system,
 189       while over 8GB was needed previously. Linking time has been improved,
 190       too. The serial stage of linking Firefox has been sped up by about a
 191       factor of 10.</li>
 192       <li>Reduced size of object files and temporary storage used during linking.</li>
 193       <li>Streaming performance (both outbound and inbound) has been improved.</li>
 194       <li><code>ld -r</code> is now supported with LTO.</li>
 195       <li>Several bug fixes, especially in symbol table handling and merging.</li>
 196     </ul></li>
 197
 198     <li>Interprocedural optimization improvements:
 199     <ul>
 200       <li>Heuristics now take into account that after inlining code will
 201       be optimized out because of known values (or properties) of function
 202       parameters.
 203       For example:
 204       <pre>
 205 void foo(int a)
 206 {
 207   if (a &gt; 10)
 208     ... huge code ...
 209 }
 210 void bar (void)
 211 {
 212   foo (0);
 213 }
 214       </pre>
 215       The call of <code>foo</code> will be inlined into <code>bar</code> even when
 216       optimizing for code size. Constructs based on <code>__builtin_constant_p</code>
 217       are now understood by the inliner and code size estimates are evaluated a lot
 218       more realistically.</li>
 219       <li>The representation of C++ virtual thunks and aliases (both implicit and defined
 220       via the <code>alias</code> attribute) has been re-engineered. Aliases no
 221       longer pose optimization barriers and calls to an alias can be inlined
 222       and otherwise optimized.</li>
 223       <li>The inter-procedural constant propagation pass has been rewritten.
 224       It now performs generic function specialization.  For example when
 225       compiling the following:
 226       <pre>
 227 void foo(bool flag)
 228 {
 229   if (flag)
 230     ... do something ...
 231   else
 232     ... do something else ...
 233 }
 234 void bar (void)
 235 {
 236   foo (false);
 237   foo (true);
 238   foo (false);
 239   foo (true);
 240   foo (false);
 241   foo (true);
 242 }
 243       </pre>
 244       GCC will now produce two copies of <code>foo</code>. One with <code>flag</code> being
 245       <code>true</code>, while other with <code>flag</code> being
 246       <code>false</code>.  This leads to performance improvements previously
 247       possible only by inlining all calls.  Cloning causes a lot less code size
 248       growth.</li>
 249     </ul></li>
 250
 251     <li>A string length optimization pass has been added.  It attempts
 252       to track string lengths and optimize various standard C string functions
 253       like <code>strlen</code>, <code>strchr</code>, <code>strcpy</code>,
 254       <code>strcat</code>, <code>stpcpy</code> and their
 255       <code>_FORTIFY_SOURCE</code> counterparts into faster alternatives.
 256       This pass is enabled by default at <code>-O2</code> or above, unless
 257       optimizing for size, and can be disabled by the
 258       <code>-fno-optimize-strlen</code> option.  The pass can e.g. optimize
 259       <pre>
 260 char *bar (const char *a)
 261 {
 262   size_t l = strlen (a) + 2;
 263   char *p = malloc (l); if (p == NULL) return p;
 264   strcpy (p, a); strcat (p, "/"); return p;
 265 }
 266       </pre>
 267       into:
 268       <pre>
 269 char *bar (const char *a)
 270 {
 271   size_t tmp = strlen (a);
 272   char *p = malloc (tmp + 2); if (p == NULL) return p;
 273   memcpy (p, a, tmp); memcpy (p + tmp, "/", 2); return p;
 274 }
 275       </pre>
 276       or for hosted compilations where <code>stpcpy</code> is available in the
 277       runtime and headers provide its prototype, e.g.
 278       <pre>
 279 void foo (char *a, const char *b, const char *c, const char *d)
 280 {
 281   strcpy (a, b); strcat (a, c); strcat (a, d);
 282 }
 283       </pre>
 284       can be optimized into:
 285       <pre>
 286 void foo (char *a, const char *b, const char *c, const char *d)
 287 {
 288   strcpy (stpcpy (stpcpy (a, b), c), d);
 289 }
 290       </pre>
 291     </li>
 292   </ul>
 293
 294
 295 <h2>New Languages and Language specific improvements</h2>
 296
 297   <ul>
 298     <li>Version 3.1 of the <a
 299     href="http://openmp.org/wp/openmp-specifications/">OpenMP specification</a>
 300     is now supported for the C, C++, and Fortran compilers.</li>
 301   </ul>
 302
 303 <h3>Ada</h3>
 304
 305   <ul>
 306     <li>The command-line option <code>-feliminate-unused-debug-types</code>
 307       has been re-enabled by default, as it is for the other languages,
 308       leading to a reduction in debug info size of 12.5% and more for
 309       relevant cases, as well as to a small compilation speedup.</li>
 310   </ul>
 311
 312 <h3>C family</h3>
 313
 314 <ul>
 315   <li>A new built-in, <code>__builtin_assume_aligned</code>, has been added,
 316       through which the compiler can be hinted about pointer alignment
 317       and can use it to improve generated code.
 318   </li>
 319
 320   <li>A new -Wunused-local-typedefs warning was added for C, C++,
 321       Objective-C and Objective-C++.  This warning diagnoses typedefs
 322       locally defined in a function, and otherwise not used.
 323   </li>
 324
 325   <li>A new experimental -ftrack-macro-expansion option was added for
 326       C, C++, Objective-C, Objective-C++ and Fortran.  It allows the
 327       compiler to emit diagnostic about the current macro expansion
 328       stack when a compilation error occurs in a macro expansion.
 329   </li>
 330
 331   <li>
 332     <p>
 333       Experimental support for transactional memory has been added.
 334       It includes support in the compiler, as well as a supporting
 335       runtime library called <code>libitm</code>.  To compile code
 336       with transactional memory constructs, use
 337       the <code>-fgnu-tm</code> option.
 338     </p>
 339
 340     <p>
 341       Support is currently available for Alpha, ARM, PowerPC, SH, SPARC,
 342       and 32-bit/64-bit x86 platforms.
 343     </p>
 344
 345     <p>
 346       For more details on transactional memory
 347       see <a href="http://gcc.gnu.org/wiki/TransactionalMemory">the GCC
 348       WiKi</a>.
 349     </p>
 350   </li>
 351
 352   <li>
 353     <p>
 354       Support for atomic operations specifying the C++11/C11 memory model
 355       has been added.  These new <code>__atomic</code> routines replace the
 356       existing <code>__sync</code> built-in routines.
 357     </p>
 358     <p>
 359       Atomic support is also available for memory blocks.  Lock-free
 360       instructions will be used if a memory block is the same size and
 361       alignment as a supported integer type.  Atomic operations which do not
 362       have lock-free support are left as function calls.  A set of library
 363       functions is available on the GCC atomic wiki in the "External
 364       Atomics Library" section.
 365     </p>
 366     <p>
 367       For more details on the memory models and features, see the
 368       <a href="http://gcc.gnu.org/wiki/Atomic/GCCMM">atomic wiki</a>.
 369     </p>
 370   </li>
 371
 372   <li>When a binary operation is performed on vector types and one of the operands
 373       is a uniform vector, it is possible to replace the vector with the
 374       generating element. For example:
 375       <pre>
 376 typedef int v4si __attribute__ ((vector_size (16)));
 377 v4si res, a = {1,2,3,4};
 378 int x;
 379
 380 res = 2 + a;  /* means {2,2,2,2} + a  */
 381 res = a - x;  /* means a - {x,x,x,x}  */
 382       </pre>
 383   </li>
 384 </ul>
 385
 386 <h3>C</h3>
 387
 388   <ul>
 389     <li>There is support for some more features from the C11 revision
 390     of the ISO C standard.  GCC now accepts the
 391     options <code>-std=c11</code> and <code>-std=gnu11</code>, in
 392     addition to the previous <code>-std=c1x</code>
 393     and <code>-std=gnu1x</code>.
 394     <ul>
 395       <li>Unicode strings (previously supported only with options such
 396       as <code>-std=gnu11</code>, now supported
 397       with <code>-std=c11</code>), and the predefined
 398       macros <code>__STDC_UTF_16__</code>
 399       and <code>__STDC_UTF_32__</code>.</li>
 400       <li>Nonreturning functions (<code>_Noreturn</code>
 401       and <code>&lt;stdnoreturn.h&gt;</code>).</li>
 402       <li>Alignment support
 403       (<code>_Alignas</code>, <code>_Alignof</code>,
 404       <code>max_align_t</code>, <code>&lt;stdalign.h&gt;</code>).</li>
 405       <li>A built-in function <code>__builtin_complex</code> is
 406       provided to support C library implementation of
 407       the <code>CMPLX</code> family of macros.</li>
 408     </ul>
 409     </li>
 410   </ul>
 411
 412 <a name="cxx" />
 413 <h3>C++</h3>
 414
 415 <ul>
 416   <li>G++ now accepts the <code>-std=c++11</code>,
 417     <code>-std=gnu++11</code>, and <code>-Wc++11-compat</code> options,
 418     which are equivalent to <code>-std=c++0x</code>,
 419     <code>-std=gnu++0x</code>, and <code>-Wc++0x-compat</code>,
 420     respectively.</li>
 421
 422   <li>G++ now implements <a href="cxx0x_status.html">C++11</a> extended friend syntax:
 423     <blockquote><pre>
 424 template&lt;class W&gt;
 425 class Q
 426 {
 427   static const int I = 2;
 428 public:
 429   friend W;
 430 };
 431
 432 struct B
 433 {
 434   int ar[Q&lt;B&gt;::I];
 435 };</pre></blockquote></li>
 436
 437   <li>Thanks to Ville Voutilainen, G++ now implements <a href="cxx0x_status.html">C++11</a> explicit override control.
 438     <blockquote><pre>
 439 struct B {
 440   virtual void f() const final;
 441   virtual void f(int);
 442 };
 443
 444 struct D : B {
 445   void f() const;            // error: D::f attempts to override final B::f
 446   void f(long) override;     // error: doesn't override anything
 447   void f(int) override;      // ok
 448 };
 449
 450 struct E final { };
 451 struct F: E { }; // error: deriving from final class</pre></blockquote></li>
 452
 453   <li>G++ now implements <a href="cxx0x_status.html">C++11</a> non-static data member initializers.
 454     <blockquote><pre>
 455 struct A {
 456   int i = 42;
 457 } a; // initializes a.i to 42</pre></blockquote></li>
 458
 459   <li>Thanks to Ed Smith-Rowland, G++ now implements
 460     <a href="cxx0x_status.html">C++11</a> user-defined literals.
 461     <blockquote><pre>
 462 // Not actually a good approximation.  :)
 463 constexpr long double operator"" _degrees (long double d) { return d * 0.0175; }
 464 long double pi = 180.0_degrees;</pre></blockquote></li>
 465
 466   <li>G++ now implements
 467     <a href="cxx0x_status.html">C++11</a> alias-declarations.
 468     <blockquote><pre>
 469 template &lt;class T> using Ptr = T*;
 470 Ptr&lt;int> ip;  // decltype(ip) is int*</pre></blockquote></li>
 471
 472   <li>Thanks to Ville Voutilainen and Pedro Lamar&atilde;o, G++ now implements <a href="cxx0x_status.html">C++11</a> delegating constructors.
 473     <blockquote><pre>
 474 struct A {
 475   A(int);
 476   A(): A(42) { } // delegate to the A(int) constructor
 477 };</pre></blockquote></li>
 478
 479   <li>G++ now fully implements C++11 atomic classes rather than just integer
 480     derived classes.
 481     <blockquote><pre>
 482 class POD {
 483   int a;
 484   int b;
 485 };
 486 std::atomic&lt;POD> my_atomic_POD;
 487 </pre></blockquote></li>
 488
 489   <li>G++ now sets the predefined macro <code>__cplusplus</code> to the
 490     correct value, <code>199711L</code> for C++98/03,
 491     and <code>201103L</code> for C++11.
 492   </li>
 493
 494   <li>G++ now correctly implements the two-phase lookup rules such that an
 495   unqualified name used in a template must have an appropriate declaration
 496   found either in scope at the point of definition of the template or by
 497   argument-dependent lookup at the point of instantiation.  As a result,
 498   code that relies on a second unqualified lookup at the point of
 499   instantiation to find functions declared after the template or in
 500   dependent bases will be rejected.  The compiler will suggest ways to fix
 501   affected code, and using the <code>-fpermissive</code> compiler flag will
 502   allow the code to compile with a warning.
 503
 504     <blockquote><pre>
 505 template &lt;class T&gt;
 506 void f() { g(T()); } // error, g(int) not found by argument-dependent lookup
 507 void g(int) { } // fix by moving this declaration before the declaration of f
 508
 509 template &lt;class T&gt;
 510 struct A: T {
 511   // error, B::g(B) not found by argument-dependent lookup
 512   void f() { g(T()); } // fix by using this-&gt;g or A::g
 513 };
 514
 515 struct B { void g(B); };
 516
 517 int main()
 518 {
 519   f&lt;int&gt;();
 520   A&lt;B&gt;().f();
 521 }</pre></blockquote></li>
 522
 523   <li>G++ now properly re-uses stack space allocated for temporary objects
 524 when their lifetime ends, which can significantly lower stack consumption
 525 for some C++ functions.  As a result of this, some code with undefined
 526 behavior will now break:
 527 <blockquote><pre>
 528 const int &amp;f(const int &amp;i) { return i; }
 529 ....
 530 const int &amp;x = f(1);
 531 const int &amp;y = f(2);</pre></blockquote>
 532 Here, <code>x</code> refers to the temporary allocated to hold the
 533 <code>1</code> argument, which only lives until the end of the
 534 initialization; it immediately becomes a dangling reference.  So the
 535 next statement re-uses the stack slot to hold the <code>2</code>
 536 argument, and users of <code>x</code> get that value instead.
 537
 538 <p>Note that this should not cause any change of behavior for temporaries
 539 of types with non-trivial destructors, as they are already destroyed at end
 540 of full-expression; the change is that now the storage is released as
 541 well.</p></li>
 542
 543   <li>A new command-line option <code>-Wdelete-non-virtual-dtor</code>
 544       has been added to warn when <code>delete</code> is used to destroy
 545       an instance of a class which has virtual functions and non-virtual
 546       destructor. It is unsafe to delete an instance of a derived class
 547       through a pointer to a base class if the base class does not have a
 548       virtual destructor.  This warning is enabled by <code>-Wall</code>.
 549   </li>
 550
 551   <li>A new command-line option <code>-Wzero-as-null-pointer-constant</code>
 552       has been added to warn when a literal '0' is used as null pointer
 553       constant.  It can be useful to facilitate the conversion to
 554       <code>nullptr</code> in C++11.
 555   </li>
 556
 557   <li>As per C++98, access-declarations are now deprecated by
 558       G++. Using-declarations are to be used instead. Furthermore,
 559       some efforts have been made to improve the support of class
 560       scope using-declarations. In particular, using-declarations
 561       referring to a dependent type now work as expected
 562       (<a href="http://gcc.gnu.org/PR14258">bug c++/14258</a>).
 563   </li>
 564
 565   <li>The ELF symbol visibility of a template instantiation is now properly
 566     constrained by the visibility of its template arguments
 567     (<a href="http://gcc.gnu.org/PR35688">bug c++/35688</a>).</li>
 568
 569 </ul>
 570
 571   <h4>Runtime Library (libstdc++)</h4>
 572
 573   <ul>
 574     <li><a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/libstdc++/manual/manual/status.html#status.iso.2011">
 575        Improved experimental support for the new ISO C++ standard, C++11</a>,
 576        including:
 577        <ul>
 578          <li> using <code>noexcept</code> in most of the library;</li>
 579          <li> implementations of <code>pointer_traits</code>, <code>allocator_traits</code>
 580               and <code>scoped_allocator_adaptor</code>; </li>
 581          <li> uses-allocator construction for <code>tuple</code>; </li>
 582          <li> <code>vector</code> meets the allocator-aware container requirements; </li>
 583          <li> replacing <code>monotonic_clock</code> with <code>steady_clock</code>; </li>
 584          <li> enabling the thread support library on most POSIX targets; </li>
 585          <li> many small improvements to conform to the FDIS. </li>
 586        </ul>
 587      </li>
 588      <li>Added <code>--enable-clocale=newlib</code> configure option. </li>
 589      <li>Debug Mode iterators for unordered associative containers. </li>
 590      <li>Avoid polluting the global namespace and do not include
 591         <code>&lt;unistd.h&gt;</code>.</li>
 592
 593
 594   </ul>
 595
 596 <h3 id="fortran">Fortran</h3>
 597   <ul>
 598     <li>The compile flag <a
 599       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254"
 600       ><code>-fstack-arrays</code></a> has been added, which causes
 601       all local arrays to be put on stack memory. For some
 602       programs this will improve the performance significantly. If your
 603       program uses very large local arrays, it is possible that you will
 604       have to extend your runtime limits for stack memory.</li>
 605     <li>The <code><a
 606       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#index-Ofast-689"
 607       >-Ofast</a></code> flag now also implies <code><a
 608       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfno-protect-parens_007d-270"
 609       >-fno-protect-parens</a></code> and <code><a
 610       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254"
 611       >-fstack-arrays</a></code>.</li>
 612     <li>Front-end optimizations can now be selected by the
 613       <code><a
 614       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfrontend-optimize_007d-275"
 615       >-ffrontend-optimize</a></code> option and deselected by
 616       the <code>-fno-frontend-optimize</code> option.</li>
 617     <li>When front-end optimization removes a function call,
 618       <code><a
 619       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWfunction-elimination_007d-170"
 620       >-Wfunction-elimination</a></code> warns about that.</li>
 621     <li>When performing front-end-optimization, the
 622       <code><a
 623       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfaggressive-function-elimination_007d-270">-faggressive-function-elimination</a></code> option
 624       allows the removal of duplicate function calls even for impure
 625       functions.</li>
 626     <li>The flag <code><a
 627       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWreal-q-constant_007d-149"
 628       >-Wreal-q-constant</a></code> has been added, which
 629       warns if floating-point literals have been specified using
 630       <code>q</code> (such as <code>1.0q0</code>); the <code>q</code>
 631       marker is now supported as a vendor extension to denote quad precision
 632       (<code>REAL(16)</code> or, if not available, <code>REAL(10)</code>).
 633       Consider using a kind parameter (such as in <code>1.0_qp</code>)
 634       instead, which can be obtained via <a
 635       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/SELECTED_005fREAL_005fKIND.html"
 636       ><code>SELECTED_REAL_KIND</code></a>.</li>
 637     <li>The <code>GFORTRAN_USE_STDERR</code> environment variable has
 638       been removed. GNU Fortran now always prints error messages to
 639       standard error. If you wish to redirect standard error, please
 640       consult the manual for your OS, shell, batch environment etc.
 641       as appropriate.</li>
 642     <li>The <code>-fdump-core</code> option and
 643       <code>GFORTRAN_ERROR_DUMPCORE</code> environment variable have
 644       been removed. When encountering a serious error, gfortran will
 645       now always abort the program. Whether a core dump is generated
 646       depends on the user environment settings; see the <code>ulimit -c</code>
 647       setting for POSIX shells, <code>limit coredumpsize</code> for C shells,
 648       and the <a
 649       href="http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx"
 650       >WER user-mode dumps settings</a> on Windows.</li>
 651     <li>The <a
 652       href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Debugging-Options.html#index-g_t_0040code_007bfno-backtrace_007d-183"
 653       ><code>-fbacktrace</code></a> option is now enabled by default.
 654       When encountering a fatal error, gfortran will attempt to
 655       print a backtrace to standard error before aborting. It can be
 656       disabled with <code>-fno-backtrace</code>. Note: On POSIX targets
 657       with the <code>addr2line</code> utility from GNU binutils, GNU
 658       Fortran can print a backtrace with function name, file name,
 659       line number information in addition to the addresses; otherwise
 660       only the addresses are printed.</li>
 661     <li><a href="http://gcc.gnu.org/wiki/Fortran2003Status">Fortran 2003</a>:
 662       <ul>
 663        <li>Generic interface names which have the same name as derived types
 664          are now supported, which allows to write constructor functions. Note
 665          that Fortran does not support static constructor functions; only
 666          default initialization or an explicit structure-constructor
 667          initialization are available.</li>
 668        <li><a href="http://gcc.gnu.org/wiki/OOP">Polymorphic</a>
 669          (<code>class</code>) arrays are now supported.</li>
 670       </ul></li>
 671     <li><a href="http://gcc.gnu.org/wiki/Fortran2008Status">Fortran 2008</a>:
 672       <ul>
 673         <li>Support for the <code>DO CONCURRENT</code> construct has been
 674           added, which allows the user to specify that individual loop
 675           iterations have no interdependencies.</li>
 676         <li><a href="http://gcc.gnu.org/wiki/Coarray">Coarrays</a>:
 677           Full single-image support except for polymorphic coarrays.
 678           Additionally, preliminary support for multiple images via an
 679           MPI-based <a href="http://gcc.gnu.org/wiki/CoarrayLib">
 680           coarray communication library</a> has been added. Note:
 681           The library version is not yet usable as remote coarray
 682           access is not yet possible.</li>
 683       </ul></li>
 684     <li><a href="http://gcc.gnu.org/wiki/TS29113Status">TS 29113</a>:
 685       <ul>
 686         <li>New flag <code><a
 687           href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Fortran-Dialect-Options.html#index-g_t_0040code_007bstd_003d_007d_0040var_007bstd_007d-option-53"
 688           >-std=f2008ts</a></code> permits programs that are expected
 689           to conform to the Fortran 2008 standard and the draft Technical
 690           Specification (TS) 29113 on Further Interoperability of Fortran
 691           with C.</li>
 692         <li>The <code>OPTIONAL</code> attribute is now allowed
 693           for dummy arguments of <code>BIND(C)</code> procedures.</li>
 694         <li>The <code>RANK</code> intrinsic has been added.</li>
 695         <li>The implementation of the <code>ASYNCHRONOUS</code> attribute
 696           in GCC is compatible with the candidate draft of TS 29113
 697           (since GCC 4.6).</li>
 698       </ul></li>
 699   </ul>
 700
 701 <h3 id="go">Go</h3>
 702   <ul>
 703     <li>GCC 4.7 implements
 704       the <a href="http://weekly.golang.org/doc/go1.html">Go 1
 705       language standard.</a>  The library support in 4.7.0 is not
 706       quite complete, due to release timing.  Release 4.7.1 includes
 707       complete support for Go 1.  The Go library is from the Go 1.0.1
 708       release.</li>
 709     <li>Go has been tested on GNU/Linux and Solaris platforms.  It may
 710       work on other platforms as well.</li>
 711   </ul>
 712
 713 <!--
 714 <h3>Java (GCJ)</h3>
 715 -->
 716
 717
 718 <h2 id="targets">New Targets and Target Specific Improvements</h2>
 719
 720 <h3 id="arm">ARM</h3>
 721   <ul>
 722     <li>GCC now supports the Cortex-A7 processor implementing the
 723       v7-a version of the architecture using the option
 724       <code>-mcpu=cortex-a7</code>.</li>
 725     <li>The default vector size in auto-vectorization for NEON is now 128 bits.
 726       If vectorization fails thusly, the vectorizer tries again with
 727       64-bit vectors.</li>
 728     <li>A new option <code>-mvectorize-with-neon-double</code> was added to
 729       allow users to change the vector size to 64 bits.</li>
 730
 731   </ul>
 732
 733 <h3 id="avr">AVR</h3>
 734   <ul>
 735     <li>GCC now supports the XMEGA architecture.
 736       This requires GNU binutils 2.22 or later.</li>
 737     <li>Support for the
 738       <a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Named-Address-Spaces.html">named address spaces</a>
 739       <code>__flash</code>, <code>__flash1</code>, &hellip;,
 740       <code>__flash5</code> and <code>__memx</code> has been added.
 741       These address spaces locate read-only data in
 742       flash memory and allow reading from flash memory by means of ordinary
 743       C code, i.e. without the need of (inline) assembler code:
 744       <blockquote><pre>
 745 const __flash int values[] = { 42, 31 };
 746
 747 int add_values (const __flash int *p, int i)
 748 {
 749     return values[i] + *p;
 750 }</pre></blockquote></li>
 751     <li>Support has been added for a new AVR-specific configure option
 752       <code>--with-avrlibc=yes</code> in order to arrange for better
 753       integration of <a href="http://nongnu.org/avr-libc/">AVR-Libc</a>.
 754       This configure option is supported in avr-gcc 4.7.2 and newer and will
 755       only take effect in non-RTEMS configurations.  If avr-gcc is configured
 756       for RTEMS, the option will be ignored which is the same as
 757       specifying <code>--with-avrlibc=no</code>.
 758       See <a href="http://gcc.gnu.org/PR54461">PR54461</a> for more technical
 759       details.</li>
 760     <li>Support for AVR-specific <a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built%5f002din-Functions.html">built-in functions</a>
 761       has been added.</li>
 762     <li>Support has been added for the signed and unsigned 24-bit scalar
 763       integer types <code>__int24</code> and <code>__uint24</code>.</li>
 764     <li>New command-line options <code>-maccumulate-args</code>,
 765       <code>-mbranch-cost=<i>cost</i></code> and <code>-mstrict-X</code>
 766       were added to allow better fine-tuning of code optimization.</li>
 767     <li>The command option <code>-fdata-sections</code> now also takes affect
 768       on the section names of variables with the <code>progmem</code>
 769       attribute.</li>
 770     <li>A new inline assembler print modifier <code>%i</code> to print a RAM address as I/O
 771     address has been added:
 772       <blockquote><pre>
 773 #include &lt;avr/io.h&gt; /* Port Definitions from AVR-LibC */
 774
 775 void set_portb (uint8_t value)
 776 {
 777     asm volatile ("out %0, %i1" :: "r" (value), "n" (&amp;PORTB) : "memory");
 778 }</pre></blockquote>
 779       The offset between an I/O address and the RAM address for that I/O
 780       location is device-specific.  This offset is taken into account when
 781       printing a RAM address with the <code>%i</code> modifier so that the
 782       address is suitable to be used as operand in an I/O command.
 783       The address must be a constant integer known at compile time.</li>
 784     <li>The inline assembler constraint <code>"R"</code> to represent integers
 785       in the range &minus;6&nbsp;&hellip;&nbsp;5 has been removed
 786       without replacement.</li>
 787     <li>Many optimizations to:
 788       <ul>
 789         <li>64-bit integer arithmetic</li>
 790         <li>Widening multiplication</li>
 791         <li>Integer division by a constant</li>
 792         <li>Avoid constant reloading in multi-byte instructions.</li>
 793         <li>Micro-optimizations for special instruction sequences.</li>
 794         <li>Generic built-in functions like
 795           <code>__builtin_ffs*</code>, <code>__builtin_clz*</code>, etc.</li>
 796         <li>If-else decision trees generated by <code>switch</code>
 797           instructions</li>
 798         <li>Merging of data located in flash memory</li>
 799         <li>New libgcc variants for devices with 8-bit wide stack pointer</li>
 800         <li>&hellip;</li>
 801       </ul>
 802     </li>
 803     <li>Better documentation:
 804       <ul>
 805         <li>Handling of <code>EIND</code> and indirect jumps on devices with
 806           more than 128 KiB of program memory.</li>
 807         <li>Handling of the <code>RAMPD</code>, <code>RAMPX</code>,
 808           <code>RAMPY</code> and <code>RAMPZ</code> special function registers.</li>
 809         <li>Function attributes <code>OS_main</code> and <code>OS_task</code>.</li>
 810         <li>AVR-specific built-in macros.</li>
 811       </ul>
 812     </li>
 813   </ul>
 814
 815 <h3>C6X</h3>
 816   <ul>
 817     <li>Support has been added for the Texas Instruments C6X family of
 818       processors.</li>
 819   </ul>
 820
 821 <h3>CR16</h3>
 822   <ul>
 823     <li>Support has been added for National Semiconductor's CR16
 824       architecture.</li>
 825   </ul>
 826
 827 <h3>Epiphany</h3>
 828   <ul>
 829     <li>Support has been added for Adapteva's Epiphany architecture.</li>
 830   </ul>
 831
 832 <h3>IA-32/x86-64</h3>
 833   <ul>
 834     <li>Support for Intel AVX2 intrinsics, built-in functions and code generation is
 835         available via <code>-mavx2</code>.</li>
 836     <li>Support for Intel BMI2 intrinsics, built-in functions and code generation is
 837         available via <code>-mbmi2</code>.</li>
 838     <li>Implementation and automatic generation of <code>__builtin_clz*</code>
 839       using the <code>lzcnt</code> instruction is available via <code>-mlzcnt</code>.</li>
 840     <li>Support for Intel FMA3 intrinsics and code generation is available via
 841       <code>-mfma</code>.</li>
 842     <li>A new <code>-mfsgsbase</code> command-line option is available that makes GCC
 843     generate new segment register read/write instructions through dedicated built-ins.</li>
 844     <li>Support for the new Intel <code>rdrnd</code> instruction is available via <code>-mrdrnd</code>.</li>
 845     <li>Two additional AVX vector conversion instructions are available via <code>-mf16c</code>.</li>
 846     <li>Support for new Intel processor codename IvyBridge with RDRND, FSGSBASE and F16C
 847       is available through <code>-march=core-avx-i</code>.</li>
 848     <li>Support for the new Intel processor codename Haswell with AVX2, FMA, BMI,
 849       BMI2, LZCNT is available through <code>-march=core-avx2</code>.</li>
 850     <li>Support for new AMD family 15h processors (Piledriver core) is now available
 851       through <code>-march=bdver2</code> and <code>-mtune=bdver2</code> options.</li>
 852     <li>Support for <a href="http://sites.google.com/site/x32abi/">the x32 psABI</a>
 853       is now available through the <code>-mx32</code> option.</li>
 854     <li>Windows mingw targets are using the <code>-mms-bitfields</code> option
 855       by default.</li>
 856     <li>Windows x86 targets are using the <code>__thiscall</code> calling
 857       convention for C++ class-member functions.</li>
 858     <li>Support for the configure option <code>--with-threads=posix</code>
 859       for Windows mingw targets.</li>
 860   </ul>
 861
 862 <h3 id="mips">MIPS</h3>
 863   <ul>
 864     <li>GCC now supports thread-local storage (TLS) for MIPS16.
 865         This requires GNU binutils 2.22 or later.</li>
 866
 867     <li>GCC can now generate code specifically for the Cavium Octeon+
 868         and Octeon2 processors.  The associated command-line options are
 869         <code>-march=octeon+</code> and <code>-march=octeon2</code>
 870         respectively.  Both options require GNU binutils 2.22 or later.</li>
 871
 872     <li>GCC can now work around certain 24k errata, under the control
 873         of the command-line option <code>-mfix-24k</code>.
 874         These workarounds require GNU binutils 2.20 or later.</li>
 875
 876     <li>32-bit MIPS GNU/Linux targets such as <code>mips-linux-gnu</code>
 877         can now build n32 and n64 multilibs.  The result is effectively
 878         a 64-bit GNU/Linux toolchain that generates 32-bit code by default.
 879         Use the configure-time option <code>--enable-targets=all</code>
 880         to select these extra multilibs.</li>
 881
 882     <li>Passing <code>-fno-delayed-branch</code> now also stops the
 883         assembler from automatically filling delay slots.</li>
 884   </ul>
 885
 886 <!--
 887 <h3 id="picochip">picochip</h3>
 888 -->
 889
 890 <h3>PowerPC/PowerPC64</h3>
 891   <ul>
 892     <li>Vectors of type <i>vector long long</i> or <i>vector long</i> are
 893         passed and returned using the same method as other vectors with the VSX
 894         instruction set.  Previously GCC did not adhere to the ABI
 895         for 128-bit vectors with 64-bit integer base types (PR 48857).
 896         This will also be fixed in the GCC 4.6.1 and 4.5.4 releases.</li>
 897
 898      <li>A new option <code>-mno-pointers-to-nested-functions</code> was
 899         added to allow AIX 32-bit/64-bit and GNU/Linux 64-bit PowerPC users to
 900         specify that the compiler should not load up the chain register
 901         (<code>r11</code>) before calling a function through a pointer.
 902         If you use this option, you cannot call nested functions through a
 903         pointer, or call other languages that might use the static chain.</li>
 904
 905      <li>A new option <code>msave-toc-indirect</code> was added to allow AIX
 906         32-bit/64-bit and GNU/Linux 64-bit PowerPC users control whether we
 907         save the TOC in the prologue for indirect calls or generate the save
 908         inline.  This can speed up some programs that call through a function
 909         pointer a lot, but it can slow down other functions that only call
 910         through a function pointer in exceptional cases.</li>
 911
 912         <li>The PowerPC port will now enable machine-specific built-in
 913         functions when the user switches the target machine using the
 914         <code>#pragma GCC target</code> or
 915         <code>__attribute__ ((__target__ ("<em>target</em>")))</code>
 916         code sequences.  In addition, the target macros are updated.
 917         However, due to the way the <code>-save-temps</code> switch is
 918         implemented, you won't see the effect of these additional macros
 919         being defined in preprocessor output.</li>
 920   </ul>
 921
 922 <h3>SH</h3>
 923   <ul>
 924     <li>A new option <code>-msoft-atomic</code> has been added.  When it is
 925         specified, GCC will generate GNU/Linux-compatible gUSA atomic sequences
 926         for the new <code>__atomic</code> routines.</li>
 927     <li>Since it is neither supported by GAS nor officially documented, code
 928         generation for little endian SH2A has been disabled.  Specifying
 929         <code>-ml</code> with <code>-m2a*</code> will now result in a compiler
 930         error.</li>
 931     <li>The defunct <code>-mbranch-cost</code> option has been fixed.</li>
 932     <li>Some improvements to the generated code of:
 933       <ul>
 934         <li>Utilization of the <code>tst #imm,R0</code> instruction.</li>
 935         <li>Dynamic shift instructions on SH2A.</li>
 936         <li>Integer absolute value calculations.</li>
 937       </ul></li>
 938   </ul>
 939
 940 <h3>SPARC</h3>
 941   <ul>
 942     <li>The option <code>-mflat</code> has been reinstated.  When it is
 943         specified, the compiler will generate code for a single register
 944         window model.  This is essentially a new implementation and the
 945         corresponding debugger support has been added to GDB 7.4.</li>
 946     <li>Support for the options <code>-mtune=native</code> and
 947         <code>-mcpu=native</code> has been added on selected native platforms
 948         (GNU/Linux and Solaris).</li>
 949     <li>Support for the SPARC T3 (Niagara 3) processor has been added.</li>
 950     <li>VIS:
 951       <ul>
 952         <li>An intrinsics header <code>visintrin.h</code> has been added.</li>
 953         <li>Builtin intrinsics for the VIS 1.0 edge handling and pixel compare
 954             instructions have been added.</li>
 955         <li>The little-endian version of <code>alignaddr</code> is now
 956             supported.</li>
 957         <li>When possible, VIS builtins are marked <code>const</code>, which
 958             should increase the compiler's ability to optimize VIS
 959             operations.</li>
 960         <li>The compiler now properly tracks the <code>%gsr</code> register
 961             and how it behaves as an input for various VIS instructions.</li>
 962         <li>Akin to <code>fzero</code>, the compiler can now generate
 963             <code>fone</code> instructions in order to set all of the bits
 964             of a floating-point register to <code>1</code>.</li>
 965         <li>The documentation for the VIS intrinsics in the GCC manual has
 966             been brought up to date and many inaccuracies were fixed.</li>
 967         <li>Intrinsics for the VIS 2.0 <code>bmask</code>,
 968             <code>bshuffle</code>, and non-condition-code
 969             setting edge instructions have been added.  Their availability
 970             is controlled by the new <code>-mvis2</code> and
 971             <code>-mno-vis2</code> options.  They are enabled by default
 972             on UltraSPARC-III and later CPUs.</li>
 973       </ul>
 974     </li>
 975     <li>Support for UltraSPARC Fused Multiply-Add floating-point
 976         extensions has been added.  These instructions are enabled by
 977         default on SPARC T3 (Niagara 3) and later CPUs.</li>
 978   </ul>
 979
 980 <h3>TILE-Gx/TILEPro</h3>
 981   <ul>
 982     <li>Support has been added for the Tilera TILE-Gx and TILEPro families of
 983       processors.</li>
 984   </ul>
 985
 986 <!--
 987 <h2>Documentation improvements</h2>
 988 -->
 989
 990
 991 <h2>Other significant improvements</h2>
 992
 993 <ul>
 994   <li>
 995     A new option (<code>-grecord-gcc-switches</code>) was added that
 996     appends compiler command-line options that might affect code
 997     generation to the <code>DW_AT_producer</code> attribute string in the
 998     DWARF debugging information.
 999   </li>
1000
1001   <li>
1002     GCC now supports various new GNU extensions to the DWARF debugging
1003     information format, like
1004     <a
1005     href="http://www.dwarfstd.org/ShowIssue.php?issue=100909.1">entry
1006     value</a> and <a
1007     href="http://www.dwarfstd.org/ShowIssue.php?issue=100909.2">call
1008     site</a> information, <a
1009     href="http://www.dwarfstd.org/doc/040408.1.html">typed DWARF stack</a>
1010     or <a
1011     href="http://www.dwarfstd.org/ShowIssue.php?issue=110722.1">a
1012     more compact macro representation</a>.  Support for these extensions
1013     has been added to GDB 7.4. They can be disabled through the
1014     <code>-gstrict-dwarf</code> command-line option.
1015   </li>
1016 </ul>
1017
1018 <h2><a name="4.7.1">GCC 4.7.1</a></h2>
1019
1020 <p>This is the <a
1021 href="http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=FIXED&amp;target_milestone=4.7.1">list
1022 of problem reports (PRs)</a> from GCC's bug tracking system that are
1023 known to be fixed in the 4.7.1 release. This list might not be
1024 complete (that is, it is possible that some PRs that have been fixed
1025 are not listed here).</p>
1026
1027 <p>The Go frontend in the 4.7.1 release fully supports
1028 the <a href="http://weekly.golang.org/doc/go1.html">Go 1 language
1029 standard.</a></p>
1030
1031 <h2><a name="4.7.2">GCC 4.7.2</a></h2>
1032
1033 <p>This is the <a
1034 href="http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=FIXED&amp;target_milestone=4.7.2">list
1035 of problem reports (PRs)</a> from GCC's bug tracking system that are
1036 known to be fixed in the 4.7.2 release. This list might not be
1037 complete (that is, it is possible that some PRs that have been fixed
1038 are not listed here).</p>
1039
1040
1041
1042
1043 <!-- ==================================================================== -->
1044
1045 <div class="copyright">
1046
1047 <address style="margin-top:0;">For questions related to the use of GCC,
1048 please consult these web pages and the
1049 <a href="http://gcc.gnu.org/onlinedocs/">GCC manuals</a>. If that fails,
1050 the <a href="mailto:gcc-help@gcc.gnu.org">gcc-help@gcc.gnu.org</a>
1051 mailing list might help.
1052 Comments on these web pages and the development of GCC are welcome on our
1053 developer list at <a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a>.
1054 All of <a href="http://gcc.gnu.org/lists.html">our lists</a>
1055 have public archives.
1056 </address>
1057
1058 <p>Copyright (C)
1059 <a href="http://www.fsf.org">Free Software Foundation, Inc.</a>
1060 Verbatim copying and distribution of this entire article is
1061 permitted in any medium, provided this notice is preserved.</p>
1062
1063 <p style="margin-bottom:0;">These pages are
1064 <a href="http://gcc.gnu.org/about.html">maintained by the GCC team</a>.
1065 Last modified 2012-09-20<!-- IGNORE DIFF
1066 --><a href="http://validator.w3.org/check/referer">.</a></p>
1067
1068 </div>
1069
1070 <!-- ==================================================================== -->
1071
1072 </body>
1073      </html>
1074
1075