--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+ <!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+
+ <head>
+
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+ <link rev="made" href="mailto:gcc@gcc.gnu.org" />
+ <link rel="shortcut icon" href="http://gcc.gnu.org/favicon.ico" />
+ <link rel="stylesheet" type="text/css" href="http://gcc.gnu.org/gcc.css" />
+
+ <title>
+GCC 4.7 Release Series — Changes, New Features, and Fixes
+- GNU Project - Free Software Foundation (FSF)</title>
+ </head>
+
+
+<!-- GCC maintainers, please do not hesitate to update/contribute entries
+ concerning those part of GCC you maintain! 2002-03-23, Gerald.
+-->
+
+<body>
+
+
+
+<h1>GCC 4.7 Release Series<br />Changes, New Features, and Fixes</h1>
+
+
+<h2>Caveats</h2>
+
+ <ul>
+ <li><p>The <code>-fconserve-space</code> flag has been
+ deprecated. The flag had no effect for most targets: only
+ targets without a global <code>.bss</code> section and without
+ support for switchable sections. Furthermore, the flag only
+ had an effect for G++, where it could result in wrong semantics
+ (please refer to the GCC manual for further details).
+ The flag will be removed in GCC 4.8</p></li>
+
+ <li><p>Support for a number of older systems and recently
+ unmaintained or untested target ports of GCC has been declared
+ obsolete in GCC 4.7. Unless there is activity to revive them, the
+ next release of GCC will have their sources permanently
+ <strong>removed</strong>.</p>
+
+ <p id="obsoleted">All GCC ports for the following processor
+ architectures have been declared obsolete:</p>
+
+ <ul>
+ <li>picoChip (<code>picochip-*</code>)</li>
+ </ul>
+
+ <p>The following ports for individual systems on
+ particular architectures have been obsoleted:</p>
+
+ <ul>
+ <li>IRIX 6.5 (mips-sgi-irix6.5)</li>
+ <li>MIPS OpenBSD (mips*-*-openbsd*)</li>
+ <li>Solaris 8 (*-*-solaris2.8). Details can be found in the
+ <a href="http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01263.html">
+ announcement</a>.</li>
+ <li>Tru64 UNIX V5.1 (alpha*-dec-osf5.1*)</li>
+ </ul>
+
+ </li>
+
+ <li>On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A,
+ ARMv7-R, or ARMv7-M, the new option
+ <code>-munaligned-access</code> is active by default, which for
+ some source codes generates code that accesses memory on unaligned
+ addresses. This will require the kernel of those systems to enable
+ such accesses (controlled by CP15 register <code>c1</code>, refer
+ to ARM documentation). Alternatively or for compatibility with
+ kernels where unaligned accesses are not supported, all code has
+ to be compiled with <code>-mno-unaligned-access</code>.
+ Linux/ARM in official releases has automatically and
+ unconditionally supported unaligned accesses as emitted by GCC due
+ to this option being active, since Linux version 2.6.28.</li>
+
+ <li>Support on ARM for the legacy floating-point accelerator (FPA) and
+ the mixed-endian floating-point format that it used has been obsoleted.
+ The ports that still use this format have been obsoleted as well.
+ Many legacy ARM ports already provide an alternative that uses the
+ VFP floating-point format. The obsolete ports will be deleted in the
+ next release.
+
+ <p>The obsolete ports with alternatives are:</p>
+
+ <ul>
+ <li>arm*-*-rtems (use arm*-*-rtemseabi)</li>
+ <li>arm*-*-linux-gnu (use arm*-*-linux-gnueabi)</li>
+ <li>arm*-*-elf (use arm*-*-eabi)</li>
+ <li>arm*-*-uclinux* (use arm*-*-uclinux*eabi)</li>
+ </ul>
+ <p>Note, however, that these alternatives are not binary compatible
+ with their legacy counterparts (although some can support running legacy
+ applications).</p>
+ <p>The obsolete ports that currently lack a modern alternative are:</p>
+
+ <ul>
+ <li>arm*-*-ecos-elf</li>
+ <li>arm*-*-freebsd</li>
+ <li>arm*-wince-pe*</li>
+ </ul>
+
+ New ports that support more recent versions of the architecture
+ are welcome.</li>
+ <li>Support for the Maverick co-processor on ARM has been obsoleted.
+ Code to support it will be deleted in the next release.</li>
+ <li>Support has been removed for Unix International threads on Solaris
+ 2, so the <code>--enable-threads=solaris</code> configure option and
+ the <code>-threads</code> compiler option don't work any longer.</li>
+ <li>Support has been removed for the Solaris BSD Compatibility Package,
+ which lives in <code>/usr/ucbinclude</code> and
+ <code>/usr/ucblib</code>. It has been removed from Solaris 11, and was
+ only intended as a migration aid from SunOS 4 to SunOS 5. The
+ <code>-compat-bsd</code> compiler option is not recognized any
+ longer.</li>
+
+ <li>The AVR port's libgcc has been improved and its multilib structure
+ has been enhanced. As a result, all objects contributing to an
+ application must either be compiled with GCC versions up to 4.6.x or
+ with GCC versions 4.7.0 or later.</li>
+
+ <li>The ARM port's <code>-mwords-little-endian</code> option has
+ been deprecated. It will be removed in a future release.</li>
+
+ <li>Support has been removed for the NetWare x86 configuration
+ obsoleted in GCC 4.6.</li>
+
+ <li>It is no longer possible to use the <code>"l"</code>
+ constraint in MIPS16 <code>asm</code> statements.</li>
+
+ <li>GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library
+ which affected the ABI in C++11 mode: a data member was added to
+ <code>std::list</code> changing its size and altering the definitions of
+ some member functions, and <code>std::pair</code>'s move constructor was
+ non-trivial which altered the calling convention for functions with
+ <code>std::pair</code> arguments or return types. The ABI incompatibilities
+ have been fixed for GCC version 4.7.2 but as a result C++11 code compiled
+ with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with
+ different GCC versions and with C++98/C++03 code compiled with any version.
+ </li>
+
+ <li>On ARM, a bug has been fixed in GCC's implementation of the AAPCS
+ rules for the layout of vectors that could lead to wrong code being
+ generated. Vectors larger than 8 bytes in size are now by default
+ aligned to an 8-byte boundary. This is an ABI change: code that makes
+ explicit use of vector types may be incompatible with binary objects
+ built with older versions of GCC. Auto-vectorized code is not affected
+ by this change. (This change affects GCC versions 4.7.2 and later.)</li>
+
+ <li>More information on porting to GCC 4.7 from previous versions
+ of GCC can be found in
+ the <a href="http://gcc.gnu.org/gcc-4.7/porting_to.html">porting
+ guide</a> for this release.</li>
+ </ul>
+
+
+<h2>General Optimizer Improvements</h2>
+
+ <ul>
+ <li>Support for a new parameter <code>--param case-values-threshold=n</code>
+ was added to allow users to control the cutoff between doing switch statements
+ as a series of if statements and using a jump table.
+ </li>
+
+ <li>Link-time optimization (LTO) improvements:
+ <ul>
+ <li>Improved scalability and reduced memory usage. Link time
+ optimization of Firefox now requires 3GB of RAM on a 64-bit system,
+ while over 8GB was needed previously. Linking time has been improved,
+ too. The serial stage of linking Firefox has been sped up by about a
+ factor of 10.</li>
+ <li>Reduced size of object files and temporary storage used during linking.</li>
+ <li>Streaming performance (both outbound and inbound) has been improved.</li>
+ <li><code>ld -r</code> is now supported with LTO.</li>
+ <li>Several bug fixes, especially in symbol table handling and merging.</li>
+ </ul></li>
+
+ <li>Interprocedural optimization improvements:
+ <ul>
+ <li>Heuristics now take into account that after inlining code will
+ be optimized out because of known values (or properties) of function
+ parameters.
+ For example:
+ <pre>
+void foo(int a)
+{
+ if (a > 10)
+ ... huge code ...
+}
+void bar (void)
+{
+ foo (0);
+}
+ </pre>
+ The call of <code>foo</code> will be inlined into <code>bar</code> even when
+ optimizing for code size. Constructs based on <code>__builtin_constant_p</code>
+ are now understood by the inliner and code size estimates are evaluated a lot
+ more realistically.</li>
+ <li>The representation of C++ virtual thunks and aliases (both implicit and defined
+ via the <code>alias</code> attribute) has been re-engineered. Aliases no
+ longer pose optimization barriers and calls to an alias can be inlined
+ and otherwise optimized.</li>
+ <li>The inter-procedural constant propagation pass has been rewritten.
+ It now performs generic function specialization. For example when
+ compiling the following:
+ <pre>
+void foo(bool flag)
+{
+ if (flag)
+ ... do something ...
+ else
+ ... do something else ...
+}
+void bar (void)
+{
+ foo (false);
+ foo (true);
+ foo (false);
+ foo (true);
+ foo (false);
+ foo (true);
+}
+ </pre>
+ GCC will now produce two copies of <code>foo</code>. One with <code>flag</code> being
+ <code>true</code>, while other with <code>flag</code> being
+ <code>false</code>. This leads to performance improvements previously
+ possible only by inlining all calls. Cloning causes a lot less code size
+ growth.</li>
+ </ul></li>
+
+ <li>A string length optimization pass has been added. It attempts
+ to track string lengths and optimize various standard C string functions
+ like <code>strlen</code>, <code>strchr</code>, <code>strcpy</code>,
+ <code>strcat</code>, <code>stpcpy</code> and their
+ <code>_FORTIFY_SOURCE</code> counterparts into faster alternatives.
+ This pass is enabled by default at <code>-O2</code> or above, unless
+ optimizing for size, and can be disabled by the
+ <code>-fno-optimize-strlen</code> option. The pass can e.g. optimize
+ <pre>
+char *bar (const char *a)
+{
+ size_t l = strlen (a) + 2;
+ char *p = malloc (l); if (p == NULL) return p;
+ strcpy (p, a); strcat (p, "/"); return p;
+}
+ </pre>
+ into:
+ <pre>
+char *bar (const char *a)
+{
+ size_t tmp = strlen (a);
+ char *p = malloc (tmp + 2); if (p == NULL) return p;
+ memcpy (p, a, tmp); memcpy (p + tmp, "/", 2); return p;
+}
+ </pre>
+ or for hosted compilations where <code>stpcpy</code> is available in the
+ runtime and headers provide its prototype, e.g.
+ <pre>
+void foo (char *a, const char *b, const char *c, const char *d)
+{
+ strcpy (a, b); strcat (a, c); strcat (a, d);
+}
+ </pre>
+ can be optimized into:
+ <pre>
+void foo (char *a, const char *b, const char *c, const char *d)
+{
+ strcpy (stpcpy (stpcpy (a, b), c), d);
+}
+ </pre>
+ </li>
+ </ul>
+
+
+<h2>New Languages and Language specific improvements</h2>
+
+ <ul>
+ <li>Version 3.1 of the <a
+ href="http://openmp.org/wp/openmp-specifications/">OpenMP specification</a>
+ is now supported for the C, C++, and Fortran compilers.</li>
+ </ul>
+
+<h3>Ada</h3>
+
+ <ul>
+ <li>The command-line option <code>-feliminate-unused-debug-types</code>
+ has been re-enabled by default, as it is for the other languages,
+ leading to a reduction in debug info size of 12.5% and more for
+ relevant cases, as well as to a small compilation speedup.</li>
+ </ul>
+
+<h3>C family</h3>
+
+<ul>
+ <li>A new built-in, <code>__builtin_assume_aligned</code>, has been added,
+ through which the compiler can be hinted about pointer alignment
+ and can use it to improve generated code.
+ </li>
+
+ <li>A new -Wunused-local-typedefs warning was added for C, C++,
+ Objective-C and Objective-C++. This warning diagnoses typedefs
+ locally defined in a function, and otherwise not used.
+ </li>
+
+ <li>A new experimental -ftrack-macro-expansion option was added for
+ C, C++, Objective-C, Objective-C++ and Fortran. It allows the
+ compiler to emit diagnostic about the current macro expansion
+ stack when a compilation error occurs in a macro expansion.
+ </li>
+
+ <li>
+ <p>
+ Experimental support for transactional memory has been added.
+ It includes support in the compiler, as well as a supporting
+ runtime library called <code>libitm</code>. To compile code
+ with transactional memory constructs, use
+ the <code>-fgnu-tm</code> option.
+ </p>
+
+ <p>
+ Support is currently available for Alpha, ARM, PowerPC, SH, SPARC,
+ and 32-bit/64-bit x86 platforms.
+ </p>
+
+ <p>
+ For more details on transactional memory
+ see <a href="http://gcc.gnu.org/wiki/TransactionalMemory">the GCC
+ WiKi</a>.
+ </p>
+ </li>
+
+ <li>
+ <p>
+ Support for atomic operations specifying the C++11/C11 memory model
+ has been added. These new <code>__atomic</code> routines replace the
+ existing <code>__sync</code> built-in routines.
+ </p>
+ <p>
+ Atomic support is also available for memory blocks. Lock-free
+ instructions will be used if a memory block is the same size and
+ alignment as a supported integer type. Atomic operations which do not
+ have lock-free support are left as function calls. A set of library
+ functions is available on the GCC atomic wiki in the "External
+ Atomics Library" section.
+ </p>
+ <p>
+ For more details on the memory models and features, see the
+ <a href="http://gcc.gnu.org/wiki/Atomic/GCCMM">atomic wiki</a>.
+ </p>
+ </li>
+
+ <li>When a binary operation is performed on vector types and one of the operands
+ is a uniform vector, it is possible to replace the vector with the
+ generating element. For example:
+ <pre>
+typedef int v4si __attribute__ ((vector_size (16)));
+v4si res, a = {1,2,3,4};
+int x;
+
+res = 2 + a; /* means {2,2,2,2} + a */
+res = a - x; /* means a - {x,x,x,x} */
+ </pre>
+ </li>
+</ul>
+
+<h3>C</h3>
+
+ <ul>
+ <li>There is support for some more features from the C11 revision
+ of the ISO C standard. GCC now accepts the
+ options <code>-std=c11</code> and <code>-std=gnu11</code>, in
+ addition to the previous <code>-std=c1x</code>
+ and <code>-std=gnu1x</code>.
+ <ul>
+ <li>Unicode strings (previously supported only with options such
+ as <code>-std=gnu11</code>, now supported
+ with <code>-std=c11</code>), and the predefined
+ macros <code>__STDC_UTF_16__</code>
+ and <code>__STDC_UTF_32__</code>.</li>
+ <li>Nonreturning functions (<code>_Noreturn</code>
+ and <code><stdnoreturn.h></code>).</li>
+ <li>Alignment support
+ (<code>_Alignas</code>, <code>_Alignof</code>,
+ <code>max_align_t</code>, <code><stdalign.h></code>).</li>
+ <li>A built-in function <code>__builtin_complex</code> is
+ provided to support C library implementation of
+ the <code>CMPLX</code> family of macros.</li>
+ </ul>
+ </li>
+ </ul>
+
+<a name="cxx" />
+<h3>C++</h3>
+
+<ul>
+ <li>G++ now accepts the <code>-std=c++11</code>,
+ <code>-std=gnu++11</code>, and <code>-Wc++11-compat</code> options,
+ which are equivalent to <code>-std=c++0x</code>,
+ <code>-std=gnu++0x</code>, and <code>-Wc++0x-compat</code>,
+ respectively.</li>
+
+ <li>G++ now implements <a href="cxx0x_status.html">C++11</a> extended friend syntax:
+ <blockquote><pre>
+template<class W>
+class Q
+{
+ static const int I = 2;
+public:
+ friend W;
+};
+
+struct B
+{
+ int ar[Q<B>::I];
+};</pre></blockquote></li>
+
+ <li>Thanks to Ville Voutilainen, G++ now implements <a href="cxx0x_status.html">C++11</a> explicit override control.
+ <blockquote><pre>
+struct B {
+ virtual void f() const final;
+ virtual void f(int);
+};
+
+struct D : B {
+ void f() const; // error: D::f attempts to override final B::f
+ void f(long) override; // error: doesn't override anything
+ void f(int) override; // ok
+};
+
+struct E final { };
+struct F: E { }; // error: deriving from final class</pre></blockquote></li>
+
+ <li>G++ now implements <a href="cxx0x_status.html">C++11</a> non-static data member initializers.
+ <blockquote><pre>
+struct A {
+ int i = 42;
+} a; // initializes a.i to 42</pre></blockquote></li>
+
+ <li>Thanks to Ed Smith-Rowland, G++ now implements
+ <a href="cxx0x_status.html">C++11</a> user-defined literals.
+ <blockquote><pre>
+// Not actually a good approximation. :)
+constexpr long double operator"" _degrees (long double d) { return d * 0.0175; }
+long double pi = 180.0_degrees;</pre></blockquote></li>
+
+ <li>G++ now implements
+ <a href="cxx0x_status.html">C++11</a> alias-declarations.
+ <blockquote><pre>
+template <class T> using Ptr = T*;
+Ptr<int> ip; // decltype(ip) is int*</pre></blockquote></li>
+
+ <li>Thanks to Ville Voutilainen and Pedro Lamarão, G++ now implements <a href="cxx0x_status.html">C++11</a> delegating constructors.
+ <blockquote><pre>
+struct A {
+ A(int);
+ A(): A(42) { } // delegate to the A(int) constructor
+};</pre></blockquote></li>
+
+ <li>G++ now fully implements C++11 atomic classes rather than just integer
+ derived classes.
+ <blockquote><pre>
+class POD {
+ int a;
+ int b;
+};
+std::atomic<POD> my_atomic_POD;
+</pre></blockquote></li>
+
+ <li>G++ now sets the predefined macro <code>__cplusplus</code> to the
+ correct value, <code>199711L</code> for C++98/03,
+ and <code>201103L</code> for C++11.
+ </li>
+
+ <li>G++ now correctly implements the two-phase lookup rules such that an
+ unqualified name used in a template must have an appropriate declaration
+ found either in scope at the point of definition of the template or by
+ argument-dependent lookup at the point of instantiation. As a result,
+ code that relies on a second unqualified lookup at the point of
+ instantiation to find functions declared after the template or in
+ dependent bases will be rejected. The compiler will suggest ways to fix
+ affected code, and using the <code>-fpermissive</code> compiler flag will
+ allow the code to compile with a warning.
+
+ <blockquote><pre>
+template <class T>
+void f() { g(T()); } // error, g(int) not found by argument-dependent lookup
+void g(int) { } // fix by moving this declaration before the declaration of f
+
+template <class T>
+struct A: T {
+ // error, B::g(B) not found by argument-dependent lookup
+ void f() { g(T()); } // fix by using this->g or A::g
+};
+
+struct B { void g(B); };
+
+int main()
+{
+ f<int>();
+ A<B>().f();
+}</pre></blockquote></li>
+
+ <li>G++ now properly re-uses stack space allocated for temporary objects
+when their lifetime ends, which can significantly lower stack consumption
+for some C++ functions. As a result of this, some code with undefined
+behavior will now break:
+<blockquote><pre>
+const int &f(const int &i) { return i; }
+....
+const int &x = f(1);
+const int &y = f(2);</pre></blockquote>
+Here, <code>x</code> refers to the temporary allocated to hold the
+<code>1</code> argument, which only lives until the end of the
+initialization; it immediately becomes a dangling reference. So the
+next statement re-uses the stack slot to hold the <code>2</code>
+argument, and users of <code>x</code> get that value instead.
+
+<p>Note that this should not cause any change of behavior for temporaries
+of types with non-trivial destructors, as they are already destroyed at end
+of full-expression; the change is that now the storage is released as
+well.</p></li>
+
+ <li>A new command-line option <code>-Wdelete-non-virtual-dtor</code>
+ has been added to warn when <code>delete</code> is used to destroy
+ an instance of a class which has virtual functions and non-virtual
+ destructor. It is unsafe to delete an instance of a derived class
+ through a pointer to a base class if the base class does not have a
+ virtual destructor. This warning is enabled by <code>-Wall</code>.
+ </li>
+
+ <li>A new command-line option <code>-Wzero-as-null-pointer-constant</code>
+ has been added to warn when a literal '0' is used as null pointer
+ constant. It can be useful to facilitate the conversion to
+ <code>nullptr</code> in C++11.
+ </li>
+
+ <li>As per C++98, access-declarations are now deprecated by
+ G++. Using-declarations are to be used instead. Furthermore,
+ some efforts have been made to improve the support of class
+ scope using-declarations. In particular, using-declarations
+ referring to a dependent type now work as expected
+ (<a href="http://gcc.gnu.org/PR14258">bug c++/14258</a>).
+ </li>
+
+ <li>The ELF symbol visibility of a template instantiation is now properly
+ constrained by the visibility of its template arguments
+ (<a href="http://gcc.gnu.org/PR35688">bug c++/35688</a>).</li>
+
+</ul>
+
+ <h4>Runtime Library (libstdc++)</h4>
+
+ <ul>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/libstdc++/manual/manual/status.html#status.iso.2011">
+ Improved experimental support for the new ISO C++ standard, C++11</a>,
+ including:
+ <ul>
+ <li> using <code>noexcept</code> in most of the library;</li>
+ <li> implementations of <code>pointer_traits</code>, <code>allocator_traits</code>
+ and <code>scoped_allocator_adaptor</code>; </li>
+ <li> uses-allocator construction for <code>tuple</code>; </li>
+ <li> <code>vector</code> meets the allocator-aware container requirements; </li>
+ <li> replacing <code>monotonic_clock</code> with <code>steady_clock</code>; </li>
+ <li> enabling the thread support library on most POSIX targets; </li>
+ <li> many small improvements to conform to the FDIS. </li>
+ </ul>
+ </li>
+ <li>Added <code>--enable-clocale=newlib</code> configure option. </li>
+ <li>Debug Mode iterators for unordered associative containers. </li>
+ <li>Avoid polluting the global namespace and do not include
+ <code><unistd.h></code>.</li>
+
+
+ </ul>
+
+<h3 id="fortran">Fortran</h3>
+ <ul>
+ <li>The compile flag <a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254"
+ ><code>-fstack-arrays</code></a> has been added, which causes
+ all local arrays to be put on stack memory. For some
+ programs this will improve the performance significantly. If your
+ program uses very large local arrays, it is possible that you will
+ have to extend your runtime limits for stack memory.</li>
+ <li>The <code><a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#index-Ofast-689"
+ >-Ofast</a></code> flag now also implies <code><a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfno-protect-parens_007d-270"
+ >-fno-protect-parens</a></code> and <code><a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254"
+ >-fstack-arrays</a></code>.</li>
+ <li>Front-end optimizations can now be selected by the
+ <code><a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfrontend-optimize_007d-275"
+ >-ffrontend-optimize</a></code> option and deselected by
+ the <code>-fno-frontend-optimize</code> option.</li>
+ <li>When front-end optimization removes a function call,
+ <code><a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWfunction-elimination_007d-170"
+ >-Wfunction-elimination</a></code> warns about that.</li>
+ <li>When performing front-end-optimization, the
+ <code><a
+ 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
+ allows the removal of duplicate function calls even for impure
+ functions.</li>
+ <li>The flag <code><a
+ 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"
+ >-Wreal-q-constant</a></code> has been added, which
+ warns if floating-point literals have been specified using
+ <code>q</code> (such as <code>1.0q0</code>); the <code>q</code>
+ marker is now supported as a vendor extension to denote quad precision
+ (<code>REAL(16)</code> or, if not available, <code>REAL(10)</code>).
+ Consider using a kind parameter (such as in <code>1.0_qp</code>)
+ instead, which can be obtained via <a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/SELECTED_005fREAL_005fKIND.html"
+ ><code>SELECTED_REAL_KIND</code></a>.</li>
+ <li>The <code>GFORTRAN_USE_STDERR</code> environment variable has
+ been removed. GNU Fortran now always prints error messages to
+ standard error. If you wish to redirect standard error, please
+ consult the manual for your OS, shell, batch environment etc.
+ as appropriate.</li>
+ <li>The <code>-fdump-core</code> option and
+ <code>GFORTRAN_ERROR_DUMPCORE</code> environment variable have
+ been removed. When encountering a serious error, gfortran will
+ now always abort the program. Whether a core dump is generated
+ depends on the user environment settings; see the <code>ulimit -c</code>
+ setting for POSIX shells, <code>limit coredumpsize</code> for C shells,
+ and the <a
+ href="http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx"
+ >WER user-mode dumps settings</a> on Windows.</li>
+ <li>The <a
+ href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Debugging-Options.html#index-g_t_0040code_007bfno-backtrace_007d-183"
+ ><code>-fbacktrace</code></a> option is now enabled by default.
+ When encountering a fatal error, gfortran will attempt to
+ print a backtrace to standard error before aborting. It can be
+ disabled with <code>-fno-backtrace</code>. Note: On POSIX targets
+ with the <code>addr2line</code> utility from GNU binutils, GNU
+ Fortran can print a backtrace with function name, file name,
+ line number information in addition to the addresses; otherwise
+ only the addresses are printed.</li>
+ <li><a href="http://gcc.gnu.org/wiki/Fortran2003Status">Fortran 2003</a>:
+ <ul>
+ <li>Generic interface names which have the same name as derived types
+ are now supported, which allows to write constructor functions. Note
+ that Fortran does not support static constructor functions; only
+ default initialization or an explicit structure-constructor
+ initialization are available.</li>
+ <li><a href="http://gcc.gnu.org/wiki/OOP">Polymorphic</a>
+ (<code>class</code>) arrays are now supported.</li>
+ </ul></li>
+ <li><a href="http://gcc.gnu.org/wiki/Fortran2008Status">Fortran 2008</a>:
+ <ul>
+ <li>Support for the <code>DO CONCURRENT</code> construct has been
+ added, which allows the user to specify that individual loop
+ iterations have no interdependencies.</li>
+ <li><a href="http://gcc.gnu.org/wiki/Coarray">Coarrays</a>:
+ Full single-image support except for polymorphic coarrays.
+ Additionally, preliminary support for multiple images via an
+ MPI-based <a href="http://gcc.gnu.org/wiki/CoarrayLib">
+ coarray communication library</a> has been added. Note:
+ The library version is not yet usable as remote coarray
+ access is not yet possible.</li>
+ </ul></li>
+ <li><a href="http://gcc.gnu.org/wiki/TS29113Status">TS 29113</a>:
+ <ul>
+ <li>New flag <code><a
+ 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"
+ >-std=f2008ts</a></code> permits programs that are expected
+ to conform to the Fortran 2008 standard and the draft Technical
+ Specification (TS) 29113 on Further Interoperability of Fortran
+ with C.</li>
+ <li>The <code>OPTIONAL</code> attribute is now allowed
+ for dummy arguments of <code>BIND(C)</code> procedures.</li>
+ <li>The <code>RANK</code> intrinsic has been added.</li>
+ <li>The implementation of the <code>ASYNCHRONOUS</code> attribute
+ in GCC is compatible with the candidate draft of TS 29113
+ (since GCC 4.6).</li>
+ </ul></li>
+ </ul>
+
+<h3 id="go">Go</h3>
+ <ul>
+ <li>GCC 4.7 implements
+ the <a href="http://weekly.golang.org/doc/go1.html">Go 1
+ language standard.</a> The library support in 4.7.0 is not
+ quite complete, due to release timing. Release 4.7.1 includes
+ complete support for Go 1. The Go library is from the Go 1.0.1
+ release.</li>
+ <li>Go has been tested on GNU/Linux and Solaris platforms. It may
+ work on other platforms as well.</li>
+ </ul>
+
+<!--
+<h3>Java (GCJ)</h3>
+-->
+
+
+<h2 id="targets">New Targets and Target Specific Improvements</h2>
+
+<h3 id="arm">ARM</h3>
+ <ul>
+ <li>GCC now supports the Cortex-A7 processor implementing the
+ v7-a version of the architecture using the option
+ <code>-mcpu=cortex-a7</code>.</li>
+ <li>The default vector size in auto-vectorization for NEON is now 128 bits.
+ If vectorization fails thusly, the vectorizer tries again with
+ 64-bit vectors.</li>
+ <li>A new option <code>-mvectorize-with-neon-double</code> was added to
+ allow users to change the vector size to 64 bits.</li>
+
+ </ul>
+
+<h3 id="avr">AVR</h3>
+ <ul>
+ <li>GCC now supports the XMEGA architecture.
+ This requires GNU binutils 2.22 or later.</li>
+ <li>Support for the
+ <a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Named-Address-Spaces.html">named address spaces</a>
+ <code>__flash</code>, <code>__flash1</code>, …,
+ <code>__flash5</code> and <code>__memx</code> has been added.
+ These address spaces locate read-only data in
+ flash memory and allow reading from flash memory by means of ordinary
+ C code, i.e. without the need of (inline) assembler code:
+ <blockquote><pre>
+const __flash int values[] = { 42, 31 };
+
+int add_values (const __flash int *p, int i)
+{
+ return values[i] + *p;
+}</pre></blockquote></li>
+ <li>Support has been added for a new AVR-specific configure option
+ <code>--with-avrlibc=yes</code> in order to arrange for better
+ integration of <a href="http://nongnu.org/avr-libc/">AVR-Libc</a>.
+ This configure option is supported in avr-gcc 4.7.2 and newer and will
+ only take effect in non-RTEMS configurations. If avr-gcc is configured
+ for RTEMS, the option will be ignored which is the same as
+ specifying <code>--with-avrlibc=no</code>.
+ See <a href="http://gcc.gnu.org/PR54461">PR54461</a> for more technical
+ details.</li>
+ <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>
+ has been added.</li>
+ <li>Support has been added for the signed and unsigned 24-bit scalar
+ integer types <code>__int24</code> and <code>__uint24</code>.</li>
+ <li>New command-line options <code>-maccumulate-args</code>,
+ <code>-mbranch-cost=<i>cost</i></code> and <code>-mstrict-X</code>
+ were added to allow better fine-tuning of code optimization.</li>
+ <li>The command option <code>-fdata-sections</code> now also takes affect
+ on the section names of variables with the <code>progmem</code>
+ attribute.</li>
+ <li>A new inline assembler print modifier <code>%i</code> to print a RAM address as I/O
+ address has been added:
+ <blockquote><pre>
+#include <avr/io.h> /* Port Definitions from AVR-LibC */
+
+void set_portb (uint8_t value)
+{
+ asm volatile ("out %0, %i1" :: "r" (value), "n" (&PORTB) : "memory");
+}</pre></blockquote>
+ The offset between an I/O address and the RAM address for that I/O
+ location is device-specific. This offset is taken into account when
+ printing a RAM address with the <code>%i</code> modifier so that the
+ address is suitable to be used as operand in an I/O command.
+ The address must be a constant integer known at compile time.</li>
+ <li>The inline assembler constraint <code>"R"</code> to represent integers
+ in the range −6 … 5 has been removed
+ without replacement.</li>
+ <li>Many optimizations to:
+ <ul>
+ <li>64-bit integer arithmetic</li>
+ <li>Widening multiplication</li>
+ <li>Integer division by a constant</li>
+ <li>Avoid constant reloading in multi-byte instructions.</li>
+ <li>Micro-optimizations for special instruction sequences.</li>
+ <li>Generic built-in functions like
+ <code>__builtin_ffs*</code>, <code>__builtin_clz*</code>, etc.</li>
+ <li>If-else decision trees generated by <code>switch</code>
+ instructions</li>
+ <li>Merging of data located in flash memory</li>
+ <li>New libgcc variants for devices with 8-bit wide stack pointer</li>
+ <li>…</li>
+ </ul>
+ </li>
+ <li>Better documentation:
+ <ul>
+ <li>Handling of <code>EIND</code> and indirect jumps on devices with
+ more than 128 KiB of program memory.</li>
+ <li>Handling of the <code>RAMPD</code>, <code>RAMPX</code>,
+ <code>RAMPY</code> and <code>RAMPZ</code> special function registers.</li>
+ <li>Function attributes <code>OS_main</code> and <code>OS_task</code>.</li>
+ <li>AVR-specific built-in macros.</li>
+ </ul>
+ </li>
+ </ul>
+
+<h3>C6X</h3>
+ <ul>
+ <li>Support has been added for the Texas Instruments C6X family of
+ processors.</li>
+ </ul>
+
+<h3>CR16</h3>
+ <ul>
+ <li>Support has been added for National Semiconductor's CR16
+ architecture.</li>
+ </ul>
+
+<h3>Epiphany</h3>
+ <ul>
+ <li>Support has been added for Adapteva's Epiphany architecture.</li>
+ </ul>
+
+<h3>IA-32/x86-64</h3>
+ <ul>
+ <li>Support for Intel AVX2 intrinsics, built-in functions and code generation is
+ available via <code>-mavx2</code>.</li>
+ <li>Support for Intel BMI2 intrinsics, built-in functions and code generation is
+ available via <code>-mbmi2</code>.</li>
+ <li>Implementation and automatic generation of <code>__builtin_clz*</code>
+ using the <code>lzcnt</code> instruction is available via <code>-mlzcnt</code>.</li>
+ <li>Support for Intel FMA3 intrinsics and code generation is available via
+ <code>-mfma</code>.</li>
+ <li>A new <code>-mfsgsbase</code> command-line option is available that makes GCC
+ generate new segment register read/write instructions through dedicated built-ins.</li>
+ <li>Support for the new Intel <code>rdrnd</code> instruction is available via <code>-mrdrnd</code>.</li>
+ <li>Two additional AVX vector conversion instructions are available via <code>-mf16c</code>.</li>
+ <li>Support for new Intel processor codename IvyBridge with RDRND, FSGSBASE and F16C
+ is available through <code>-march=core-avx-i</code>.</li>
+ <li>Support for the new Intel processor codename Haswell with AVX2, FMA, BMI,
+ BMI2, LZCNT is available through <code>-march=core-avx2</code>.</li>
+ <li>Support for new AMD family 15h processors (Piledriver core) is now available
+ through <code>-march=bdver2</code> and <code>-mtune=bdver2</code> options.</li>
+ <li>Support for <a href="http://sites.google.com/site/x32abi/">the x32 psABI</a>
+ is now available through the <code>-mx32</code> option.</li>
+ <li>Windows mingw targets are using the <code>-mms-bitfields</code> option
+ by default.</li>
+ <li>Windows x86 targets are using the <code>__thiscall</code> calling
+ convention for C++ class-member functions.</li>
+ <li>Support for the configure option <code>--with-threads=posix</code>
+ for Windows mingw targets.</li>
+ </ul>
+
+<h3 id="mips">MIPS</h3>
+ <ul>
+ <li>GCC now supports thread-local storage (TLS) for MIPS16.
+ This requires GNU binutils 2.22 or later.</li>
+
+ <li>GCC can now generate code specifically for the Cavium Octeon+
+ and Octeon2 processors. The associated command-line options are
+ <code>-march=octeon+</code> and <code>-march=octeon2</code>
+ respectively. Both options require GNU binutils 2.22 or later.</li>
+
+ <li>GCC can now work around certain 24k errata, under the control
+ of the command-line option <code>-mfix-24k</code>.
+ These workarounds require GNU binutils 2.20 or later.</li>
+
+ <li>32-bit MIPS GNU/Linux targets such as <code>mips-linux-gnu</code>
+ can now build n32 and n64 multilibs. The result is effectively
+ a 64-bit GNU/Linux toolchain that generates 32-bit code by default.
+ Use the configure-time option <code>--enable-targets=all</code>
+ to select these extra multilibs.</li>
+
+ <li>Passing <code>-fno-delayed-branch</code> now also stops the
+ assembler from automatically filling delay slots.</li>
+ </ul>
+
+<!--
+<h3 id="picochip">picochip</h3>
+-->
+
+<h3>PowerPC/PowerPC64</h3>
+ <ul>
+ <li>Vectors of type <i>vector long long</i> or <i>vector long</i> are
+ passed and returned using the same method as other vectors with the VSX
+ instruction set. Previously GCC did not adhere to the ABI
+ for 128-bit vectors with 64-bit integer base types (PR 48857).
+ This will also be fixed in the GCC 4.6.1 and 4.5.4 releases.</li>
+
+ <li>A new option <code>-mno-pointers-to-nested-functions</code> was
+ added to allow AIX 32-bit/64-bit and GNU/Linux 64-bit PowerPC users to
+ specify that the compiler should not load up the chain register
+ (<code>r11</code>) before calling a function through a pointer.
+ If you use this option, you cannot call nested functions through a
+ pointer, or call other languages that might use the static chain.</li>
+
+ <li>A new option <code>msave-toc-indirect</code> was added to allow AIX
+ 32-bit/64-bit and GNU/Linux 64-bit PowerPC users control whether we
+ save the TOC in the prologue for indirect calls or generate the save
+ inline. This can speed up some programs that call through a function
+ pointer a lot, but it can slow down other functions that only call
+ through a function pointer in exceptional cases.</li>
+
+ <li>The PowerPC port will now enable machine-specific built-in
+ functions when the user switches the target machine using the
+ <code>#pragma GCC target</code> or
+ <code>__attribute__ ((__target__ ("<em>target</em>")))</code>
+ code sequences. In addition, the target macros are updated.
+ However, due to the way the <code>-save-temps</code> switch is
+ implemented, you won't see the effect of these additional macros
+ being defined in preprocessor output.</li>
+ </ul>
+
+<h3>SH</h3>
+ <ul>
+ <li>A new option <code>-msoft-atomic</code> has been added. When it is
+ specified, GCC will generate GNU/Linux-compatible gUSA atomic sequences
+ for the new <code>__atomic</code> routines.</li>
+ <li>Since it is neither supported by GAS nor officially documented, code
+ generation for little endian SH2A has been disabled. Specifying
+ <code>-ml</code> with <code>-m2a*</code> will now result in a compiler
+ error.</li>
+ <li>The defunct <code>-mbranch-cost</code> option has been fixed.</li>
+ <li>Some improvements to the generated code of:
+ <ul>
+ <li>Utilization of the <code>tst #imm,R0</code> instruction.</li>
+ <li>Dynamic shift instructions on SH2A.</li>
+ <li>Integer absolute value calculations.</li>
+ </ul></li>
+ </ul>
+
+<h3>SPARC</h3>
+ <ul>
+ <li>The option <code>-mflat</code> has been reinstated. When it is
+ specified, the compiler will generate code for a single register
+ window model. This is essentially a new implementation and the
+ corresponding debugger support has been added to GDB 7.4.</li>
+ <li>Support for the options <code>-mtune=native</code> and
+ <code>-mcpu=native</code> has been added on selected native platforms
+ (GNU/Linux and Solaris).</li>
+ <li>Support for the SPARC T3 (Niagara 3) processor has been added.</li>
+ <li>VIS:
+ <ul>
+ <li>An intrinsics header <code>visintrin.h</code> has been added.</li>
+ <li>Builtin intrinsics for the VIS 1.0 edge handling and pixel compare
+ instructions have been added.</li>
+ <li>The little-endian version of <code>alignaddr</code> is now
+ supported.</li>
+ <li>When possible, VIS builtins are marked <code>const</code>, which
+ should increase the compiler's ability to optimize VIS
+ operations.</li>
+ <li>The compiler now properly tracks the <code>%gsr</code> register
+ and how it behaves as an input for various VIS instructions.</li>
+ <li>Akin to <code>fzero</code>, the compiler can now generate
+ <code>fone</code> instructions in order to set all of the bits
+ of a floating-point register to <code>1</code>.</li>
+ <li>The documentation for the VIS intrinsics in the GCC manual has
+ been brought up to date and many inaccuracies were fixed.</li>
+ <li>Intrinsics for the VIS 2.0 <code>bmask</code>,
+ <code>bshuffle</code>, and non-condition-code
+ setting edge instructions have been added. Their availability
+ is controlled by the new <code>-mvis2</code> and
+ <code>-mno-vis2</code> options. They are enabled by default
+ on UltraSPARC-III and later CPUs.</li>
+ </ul>
+ </li>
+ <li>Support for UltraSPARC Fused Multiply-Add floating-point
+ extensions has been added. These instructions are enabled by
+ default on SPARC T3 (Niagara 3) and later CPUs.</li>
+ </ul>
+
+<h3>TILE-Gx/TILEPro</h3>
+ <ul>
+ <li>Support has been added for the Tilera TILE-Gx and TILEPro families of
+ processors.</li>
+ </ul>
+
+<!--
+<h2>Documentation improvements</h2>
+-->
+
+
+<h2>Other significant improvements</h2>
+
+<ul>
+ <li>
+ A new option (<code>-grecord-gcc-switches</code>) was added that
+ appends compiler command-line options that might affect code
+ generation to the <code>DW_AT_producer</code> attribute string in the
+ DWARF debugging information.
+ </li>
+
+ <li>
+ GCC now supports various new GNU extensions to the DWARF debugging
+ information format, like
+ <a
+ href="http://www.dwarfstd.org/ShowIssue.php?issue=100909.1">entry
+ value</a> and <a
+ href="http://www.dwarfstd.org/ShowIssue.php?issue=100909.2">call
+ site</a> information, <a
+ href="http://www.dwarfstd.org/doc/040408.1.html">typed DWARF stack</a>
+ or <a
+ href="http://www.dwarfstd.org/ShowIssue.php?issue=110722.1">a
+ more compact macro representation</a>. Support for these extensions
+ has been added to GDB 7.4. They can be disabled through the
+ <code>-gstrict-dwarf</code> command-line option.
+ </li>
+</ul>
+
+<h2><a name="4.7.1">GCC 4.7.1</a></h2>
+
+<p>This is the <a
+href="http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1">list
+of problem reports (PRs)</a> from GCC's bug tracking system that are
+known to be fixed in the 4.7.1 release. This list might not be
+complete (that is, it is possible that some PRs that have been fixed
+are not listed here).</p>
+
+<p>The Go frontend in the 4.7.1 release fully supports
+the <a href="http://weekly.golang.org/doc/go1.html">Go 1 language
+standard.</a></p>
+
+<h2><a name="4.7.2">GCC 4.7.2</a></h2>
+
+<p>This is the <a
+href="http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.2">list
+of problem reports (PRs)</a> from GCC's bug tracking system that are
+known to be fixed in the 4.7.2 release. This list might not be
+complete (that is, it is possible that some PRs that have been fixed
+are not listed here).</p>
+
+
+
+
+<!-- ==================================================================== -->
+
+<div class="copyright">
+
+<address style="margin-top:0;">For questions related to the use of GCC,
+please consult these web pages and the
+<a href="http://gcc.gnu.org/onlinedocs/">GCC manuals</a>. If that fails,
+the <a href="mailto:gcc-help@gcc.gnu.org">gcc-help@gcc.gnu.org</a>
+mailing list might help.
+Comments on these web pages and the development of GCC are welcome on our
+developer list at <a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a>.
+All of <a href="http://gcc.gnu.org/lists.html">our lists</a>
+have public archives.
+</address>
+
+<p>Copyright (C)
+<a href="http://www.fsf.org">Free Software Foundation, Inc.</a>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.</p>
+
+<p style="margin-bottom:0;">These pages are
+<a href="http://gcc.gnu.org/about.html">maintained by the GCC team</a>.
+Last modified 2012-09-20<!-- IGNORE DIFF
+--><a href="http://validator.w3.org/check/referer">.</a></p>
+
+</div>
+
+<!-- ==================================================================== -->
+
+</body>
+ </html>
+
+
projects / cross.git / blobdiff