1
<?xml version="1.0" encoding="utf-8"?>
3
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
4
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
19
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
24
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
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" />
30
GCC 4.8 Release Series — Changes, New Features, and Fixes
31
- GNU Project - Free Software Foundation (FSF)</title>
35
<!-- GCC maintainers, please do not hesitate to update/contribute entries
36
concerning those part of GCC you maintain! 2002-03-23, Gerald.
43
<h1>GCC 4.8 Release Series<br />Changes, New Features, and Fixes</h1>
47
<p>GCC now uses C++ as its implementation language. This means that
48
to build GCC from sources, you will need a C++ compiler that
49
understands C++ 2003. For more details on the rationale and specific
50
changes, please refer to the <a
51
href="http://gcc.gnu.org/wiki/cxx-conversion">C++ conversion</a>
54
<p>To enable the Graphite framework for loop optimizations you now
55
need CLooG version 0.18.0 and ISL version 0.11.1. Both can be obtained
57
<a href="ftp://gcc.gnu.org/pub/gcc/infrastructure/">GCC infrastructure</a>
58
directory. The installation manual contains
59
more information about requirements to build GCC.</p>
61
<p>GCC now uses a more aggressive analysis to derive an upper bound for
62
the number of iterations of loops using constraints imposed by language
63
standards. This may cause non-conforming programs to no longer work as
64
expected, such as SPEC CPU 2006 464.h264ref and 416.gamess. A new
65
option, <code>-fno-aggressive-loop-optimizations</code>, was added
66
to disable this aggressive analysis. In some loops that have known
67
constant number of iterations, but undefined behavior is known to occur
68
in the loop before reaching or during the last iteration, GCC will warn
69
about the undefined behavior in the loop instead of deriving lower upper
70
bound of the number of iterations for the loop. The warning
71
can be disabled with <code>-Wno-aggressive-loop-optimizations</code>.</p>
73
<p>On ARM, a bug has been fixed in GCC's implementation of the AAPCS
74
rules for the layout of vectors that could lead to wrong code being
75
generated. Vectors larger than 8 bytes in size are now by default
76
aligned to an 8-byte boundary. This is an ABI change: code that makes
77
explicit use of vector types may be incompatible with binary objects
78
built with older versions of GCC. Auto-vectorized code is not affected
81
<p>On AVR, support has been removed for the command-line
82
option <code>-mshort-calls</code> deprecated in GCC 4.7.</p>
84
<p>On AVR, the configure option <code>--with-avrlibc</code> supported since
85
GCC 4.7.2 is turned on per default for all non-RTEMS configurations.
86
This option arranges for a better integration of
87
<a href="http://www.nongnu.org/avr-libc/">AVR Libc</a> with avr-gcc.
88
For technical details, see <a href="http://gcc.gnu.org/PR54461">PR54461</a>.
89
To turn off the option in non-RTEMS configurations, use
90
<code>--with-avrlibc=no</code>. If the compiler is configured for
91
RTEMS, the option is always turned off.</p>
94
More information on porting to GCC 4.8 from previous versions
95
of GCC can be found in
96
the <a href="http://gcc.gnu.org/gcc-4.8/porting_to.html">porting
97
guide</a> for this release.
100
<h2>General Optimizer Improvements (and Changes)</h2>
103
<li>DWARF4 is now the default when generating DWARF debug information.
104
When <code>-g</code> is used on a platform that uses DWARF debugging
105
information, GCC will now default to
106
<code>-gdwarf-4 -fno-debug-types-section</code>.<br />
107
GDB 7.5, Valgrind 3.8.0 and elfutils 0.154 debug information consumers
108
support DWARF4 by default. Before GCC 4.8 the default version used
109
was DWARF2. To make GCC 4.8 generate an older DWARF version use
110
<code>-g</code> together with <code>-gdwarf-2</code> or
111
<code>-gdwarf-3</code>.
112
The default for Darwin and VxWorks is still
113
<code>-gdwarf-2 -gstrict-dwarf</code>.
115
<li>A new general optimization level, <code>-Og</code>, has been
116
introduced. It addresses the need for fast compilation and a
117
superior debugging experience while providing a reasonable level
118
of runtime performance. Overall experience for development should
119
be better than the default optimization level <code>-O0</code>.
121
<li>A new option <code>-ftree-partial-pre</code> was added to control
122
the partial redundancy elimination (PRE) optimization.
123
This option is enabled by default at the <code>-O3</code> optimization
124
level, and it makes PRE more aggressive.
126
<li>The option <code>-fconserve-space</code> has been removed; it
127
was no longer useful on most targets since GCC supports putting
128
variables into BSS without making them common.</li>
129
<li>The struct reorg and matrix reorg optimizations (command-line
130
options <code>-fipa-struct-reorg</code> and
131
<code>-fipa-matrix-reorg</code>) have been removed. They did not
132
always work correctly, nor did they work with link-time optimization
133
(LTO), hence were only applicable to programs consisting of a single
136
<li>Several scalability bottle-necks have been removed from GCC's
137
optimization passes. Compilation of extremely large functions,
138
e.g. due to the use of the <code>flatten</code> attribute in the
139
"Eigen" C++ linear algebra templates library, is significantly
140
faster than previous releases of GCC.
142
<li>Link-time optimization (LTO) improvements:
144
<li>LTO partitioning has been rewritten for better reliability
145
and maintanibility. Several important bugs leading to link
146
failures have been fixed.</li>
148
<li>Interprocedural optimization improvements:
150
<li>A new symbol table has been implemented. It
151
builds on existing callgraph and varpool modules and
152
provide a new API. Unusual symbol visibilities and aliases
153
are handled more consistently leading to, for example,
154
more aggressive unreachable code removal with LTO.</li>
155
<li>The inline heuristic can now bypass limits on the size of
156
of inlined functions when the inlining is particularly profitable.
157
This happens, for example, when loop bounds or array strides
159
<li>Values passed through aggregates (either by value or reference)
160
are now propagated at the inter-procedural level leading to better
161
inlining decisions (for example in the case of Fortran
162
array descriptors) and devirtualization.</li>
164
<li><a href="https://code.google.com/p/address-sanitizer/">AddressSanitizer
165
</a>, a fast memory error detector, has been added and can be
166
enabled via <code>-fsanitize=address</code>. Memory access
167
instructions will be instrumented to detect heap-, stack-, and
168
global-buffer overflow as well as use-after-free bugs. To get
169
nicer stacktraces, use <code>-fno-omit-frame-pointer</code>. The
170
AddressSanitizer is available on IA-32/x86-64/x32/PowerPC/PowerPC64
171
GNU/Linux and on x86-64 Darwin.</li>
172
<li><a href="https://code.google.com/p/data-race-test/wiki/ThreadSanitizer"
173
>ThreadSanitizer</a> has been added and can be enabled via
174
<code>-fsanitize=thread</code>. Instructions will be instrumented to
175
detect data races. The ThreadSanitizer is available on x86-64
180
<h2>New Languages and Language specific improvements</h2>
191
<li>Each diagnostic emitted now includes the original
192
source line and a caret '^' indicating the column.
193
The option <code>-fno-diagnostics-show-caret</code>
194
suppresses this information.</li>
196
<li>The option <code>-ftrack-macro-expansion=2</code> is now
197
enabled by default. This allows the compiler to display the
198
macro expansion stack in diagnostics. Combined with the caret
199
information, an example diagnostic showing these two features
202
t.c:1:94: error: invalid operands to binary < (have ‘struct mystruct’ and ‘float’)
203
#define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
205
t.c:7:7: note: in expansion of macro 'MYMAX'
211
<li>A new <code>-Wsizeof-pointer-memaccess</code> warning has been added
212
(also enabled by <code>-Wall</code>) to warn about suspicious length parameters
213
to certain string and memory built-in functions if the argument uses
214
<code>sizeof</code>. This warning warns e.g.
215
about <code>memset (ptr, 0, sizeof (ptr));</code> if <code>ptr</code> is not an array,
216
but a pointer, and suggests a possible fix, or about
217
<code>memcpy (&foo, ptr, sizeof (&foo));</code>.</li>
219
<li>The new option <code>-Wpedantic</code> is an alias for
220
<code>-pedantic</code>, which is now deprecated. The forms
221
<code>-Wno-pedantic</code>, <code>-Werror=pedantic</code>, and
222
<code>-Wno-error=pedantic</code> work in the same way as for any other
223
<code>-W</code> option. One caveat is that
224
<code>-Werror=pedantic</code> is <strong>not</strong> equivalent to
225
<code>-pedantic-errors</code>, since the latter makes into errors
226
some warnings that are not controlled by <code>-Wpedantic</code>,
227
and the former only affects diagnostics that are disabled when using
228
<code>-Wno-pedantic</code>.</li>
230
<li>The option <code>-Wshadow</code> no longer warns if a
231
declaration shadows a function declaration, unless the former
232
declares a function or pointer to function, because this is <a
233
href="https://lkml.org/lkml/2006/11/28/239">a common and valid case
234
in real-world code</a>.</li>
242
<h3 id="cxx">C++</h3>
244
<li><p>G++ now implements the <a href="cxx0x_status.html">C++11</a>
245
<code>thread_local</code> keyword; this differs from the
246
GNU <code>__thread</code> keyword primarily in that it allows dynamic
247
initialization and destruction semantics. Unfortunately, this support
248
requires a run-time penalty for references to non-function-local
249
<code>thread_local</code> variables defined in a different
250
translation unit even if they don't need dynamic
251
initialization, so users may want to continue to
252
use <code>__thread</code> for TLS variables with static initialization
255
If the programmer can be sure that no use of the variable in a
256
non-defining TU needs to trigger dynamic initialization (either because
257
the variable is statically initialized, or a use of the variable in the
258
defining TU will be executed before any uses in another TU), they can
259
avoid this overhead with the <code>-fno-extern-tls-init</code> option.
261
OpenMP <code>threadprivate</code> variables now also support dynamic
262
initialization and destruction by the same mechanism.
264
<li>G++ now implements the <a href="cxx0x_status.html">C++11</a>
265
attribute syntax, e.g.
267
[[noreturn]] void f();
269
and also the alignment specifier, e.g.
271
alignas(double) int i;
272
</pre></blockquote></li>
274
<li>G++ now implements <a href="cxx0x_status.html">C++11</a> inheriting constructors, e.g.
276
struct A { A(int); };
277
struct B: A { using A::A; }; // defines B::B(int)
282
<li>As of GCC 4.8.1, G++ implements the change to <code>decltype</code> semantics from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf">N3276</a>.
285
decltype(f()) g(); // OK, return type of f() is not required to be complete.
289
<li>G++ now supports a <code>-std=c++1y</code> option for experimentation
290
with features proposed for the next revision of the standard, expected
291
around 2017. Currently the only difference from <code>-std=c++11</code>
292
is support for return type deduction in normal functions, as proposed in
293
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3386.html">N3386</a>.</li>
295
<li>The G++ namespace association extension,
296
<code>__attribute ((strong))</code>,
297
has been deprecated. Inline namespaces should be used instead.</li>
299
<li>G++ now supports a <code>-fext-numeric-literal</code> option to control
300
whether GNU numeric literal suffixes are accepted as extensions or processed
301
as C++11 user-defined numeric literal suffixes. The flag is on
302
(use suffixes for GNU literals) by default for <code>-std=gnu++*</code>,
303
and <code>-std=c++98</code>. The flag is off (use suffixes for user-defined
304
literals) by default for <code>-std=c++11</code> and later.</li>
307
<h4>Runtime Library (libstdc++)</h4>
310
<li><a href="http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011">
311
Improved experimental support for the new ISO C++ standard, C++11</a>,
314
<li> <code>forward_list</code> meets the allocator-aware container requirements; </li>
315
<li> <code>this_thread::sleep_for()</code>, <code>this_thread::sleep_until()</code> and
316
<code>this_thread::yield()</code> are defined without requiring the configure
317
option <code>--enable-libstdcxx-time</code>; </li>
320
<li>Improvements to <code><random></code>:
322
<li>SSE optimized <code>normal_distribution</code>. </li>
323
<li>Use of hardware RNG instruction for <code>random_device</code>
324
on new x86 processors (requires the assembler to support the
327
and <code><ext/random></code>:
329
<li>New random number engine <code>simd_fast_mersenne_twister_engine</code>
330
with an optimized SSE implementation. </li>
331
<li>New random number distributions <code>beta_distribution</code>,
332
<code>normal_mv_distribution</code>, <code>rice_distribution</code>,
333
<code>nakagami_distribution</code>, <code>pareto_distribution</code>,
334
<code>k_distribution</code>, <code>arcsine_distribution</code>,
335
<code>hoyt_distribution</code>. </li>
338
<li>Added <code>--disable-libstdcxx-verbose</code> configure option
339
to disable diagnostic messages issued when a process terminates
340
abnormally. This may be useful for embedded systems to reduce the
341
size of executables that link statically to the library.
345
<h3 id="fortran">Fortran</h3>
347
<li>Compatibility notice:
349
<li>Module files: The version of module files (<code>.mod</code>)
350
has been incremented. Fortran <code>MODULE</code>s compiled by earlier
351
GCC versions have to be recompiled, when they are <code>USE</code>d by
352
files compiled with GCC 4.8. GCC 4.8 is not able to read
353
<code>.mod</code> files created by earlier versions; attempting to do so
354
gives an error message.<br />
355
Note: The ABI of the produced assembler data itself has not changed;
356
object files and libraries are fully compatible
357
with older versions except as noted below.</li>
358
<li>ABI: Some internal names (used in the assembler/object file) have
359
changed for symbols declared in the specification part of a module.
360
If an affected module – or a file using it via use
361
association – is recompiled, the module and all files which
362
directly use such symbols have to be recompiled as well. This change
363
only affects the following kind of module symbols:
365
<li>Procedure pointers. Note: C-interoperable function pointers
366
(<code>type(c_funptr)</code>) are not affected nor are
367
procedure-pointer components.</li>
368
<li>Deferred-length character strings.</li>
372
<li>The <a href="http://gcc.gnu.org/onlinedocs/gfortran/BACKTRACE.html">
373
<code>BACKTRACE</code></a> intrinsic subroutine has been added. It shows
374
a backtrace at an arbitrary place in user code; program execution
375
continues normally afterwards.</li>
378
href="http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html">
379
-Wc-binding-type</a></code> warning option has been added (disabled
380
by default). It warns if the a variable might not be C interoperable; in
381
particular, if the variable has been declared using an intrinsic type with
382
default kind instead of using a kind parameter defined for C
383
interoperability in the intrinsic <code>ISO_C_Binding</code> module.
384
Before, this warning was always printed. The <code>-Wc-binding-type</code>
385
option is enabled by <code>-Wall</code>.</li>
388
href="http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html">
389
<code>-Wrealloc-lhs</code></a> and <code>-Wrealloc-lhs-all</code> warning
390
command-line options have been added, which diagnose when code to is
391
inserted for automatic (re)allocation of a variable during assignment.
392
This option can be used to decide whether it is safe to use <code><a
393
href="http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html">
394
-fno-realloc-lhs</a></code>. Additionally, it can be used to find automatic
395
(re)allocation in hot loops. (For arrays, replacing <q><code>var=</code></q>
396
by <q><code>var(:)=</code></q> disables the automatic reallocation.)</li>
399
href="http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html">
400
<code>-Wcompare-reals</code></a> command-line option has been added. When
401
this is set, warnings are issued when comparing <code>REAL</code> or
402
<code>COMPLEX</code> types for equality and inequality; consider replacing
403
<code>a == b</code> by <code>abs(a−b) < eps</code> with a suitable
404
<code>eps</code>. <code>-Wcompare-reals</code> is enabled by
405
<code>-Wextra</code>.</li>
408
href="http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html">
409
<code>-Wtarget-lifetime</code></a> command-line option has been added
410
(enabled with <code>-Wall</code>), which warns if the pointer in a
411
pointer assignment might outlive its target.</li>
413
<li><p>Reading floating point numbers which use <q><code>q</code></q> for
414
the exponential (such as <code>4.0q0</code>) is now supported as vendor
415
extension for better compatibility with old data files. It is strongly
416
recommended to use for I/O the equivalent but standard conforming
417
<q><code>e</code></q> (such as <code>4.0e0</code>).</p>
420
source code, consider replacing the <q><code>q</code></q> in
421
floating-point literals by a kind parameter (e.g. <code>4.0e0_qp</code>
422
with a suitable <code>qp</code>). Note that – in Fortran
423
source code – replacing <q><code>q</code></q> by a simple
424
<q><code>e</code></q> is <em>not</em> equivalent.)</p></li>
426
<li>The <code>GFORTRAN_TMPDIR</code> environment variable for specifying
427
a non-default directory for files opened with <code>STATUS="SCRATCH"</code>,
428
is not used anymore. Instead gfortran checks the POSIX/GNU standard
429
<code>TMPDIR</code> environment variable. If <code>TMPDIR</code> is not
430
defined, gfortran falls back to other methods to determine the directory
431
for temporary files as documented in the
432
<a href="http://gcc.gnu.org/onlinedocs/gfortran/TMPDIR.html">user
435
<li><a href="http://gcc.gnu.org/wiki/Fortran2003Status">Fortran 2003</a>:
437
<li>Support for unlimited polymorphic variables (<code>CLASS(*)</code>)
438
has been added. Nonconstant character lengths are not yet
442
<li><a href="http://gcc.gnu.org/wiki/TS29113Status">TS 29113</a>:
444
<li>Assumed types (<code>TYPE(*)</code>) are now supported.</li>
446
<li>Experimental support for assumed-rank arrays
447
(<code>dimension(..)</code>) has been added. Note that currently
448
gfortran's own array descriptor is used, which is different from the
449
one defined in TS29113, see <a
450
href="http://gcc.gnu.org/viewcvs/trunk/libgfortran/libgfortran.h?content-type=text%2Fplain&view=co">
451
gfortran's header file</a> or use the <a
452
href="http://chasm-interop.sourceforge.net/">Chasm Language
453
Interoperability Tools</a>.</li>
459
<li>GCC 4.8.0 implements a preliminary version of the upcoming Go
460
1.1 release. The library support is not quite complete, due to
462
<li>Go has been tested on GNU/Linux and Solaris platforms for
463
various processors including x86, x86_64, PowerPC, SPARC, and
464
Alpha. It may work on other platforms as well.</li>
471
<h2 id="targets">New Targets and Target Specific Improvements</h2>
473
<h3 id="aarch64">AArch64</h3>
475
<li> A new port has been added to support AArch64, the new 64-bit
476
architecture from ARM. Note that this is a separate port from the
477
existing 32-bit ARM port.</li>
478
<li> The port provides initial support for the Cortex-A53 and the
479
Cortex-A57 processors with the command line options
480
<code>-mcpu=cortex-a53</code> and <code>-mcpu=cortex-a57</code>.</li>
483
<h3 id="arm">ARM</h3>
485
<li>Initial support has been added for the AArch32 extensions defined
486
in the ARMv8 architecture.</li>
487
<li>Code generation improvements for the Cortex-A7 and Cortex-A15 CPUs.</li>
488
<li>A new option, <code>-mcpu=marvell-pj4</code>, has been added to
489
generate code for the Marvell PJ4 processor.</li>
490
<li>The compiler can now automatically generate the <code>VFMA</code>,
491
<code>VFMS</code>, <code>REVSH</code> and <code>REV16</code>
493
<li>A new vectorizer cost model for Advanced SIMD configurations to
494
improve the auto-vectorization strategies used.</li>
495
<li>The scheduler now takes into account the number of live registers to
496
reduce the amount of spilling that can occur. This should improve code
497
performance in large functions. The limit can be removed by using the
498
option <code>-fno-sched-pressure</code>.</li>
499
<li>Improvements have been made to the Marvell iWMMX code generation and
500
support for the iWMMX2 SIMD unit has been added. The option
501
<code>-mcpu=iwmmxt2</code> can be used to enable code generation for
503
<li>A number of code generation improvements for Thumb2 to reduce code
504
size when compiling for the M-profile processors.</li>
505
<li>The RTEMS (<code>arm-rtems</code>) port has been updated to use the
507
<li>Code generation support for the old FPA and Maverick floating-point
508
architectures has been removed. Ports that previously relied on these
509
features have also been removed. This includes the targets:
511
<li><code>arm*-*-linux-gnu</code> (use
512
<code>arm*-*-linux-gnueabi</code>)</li>
513
<li><code>arm*-*-elf</code> (use <code>arm*-*-eabi</code>)</li>
514
<li><code>arm*-*-uclinux*</code> (use
515
<code>arm*-*-uclinux*eabi</code>)</li>
516
<li><code>arm*-*-ecos-elf</code> (no alternative)</li>
517
<li><code>arm*-*-freebsd</code> (no alternative)</li>
518
<li><code>arm*-wince-pe*</code> (no alternative).</li>
522
<h3 id="avr">AVR</h3>
525
Support for the "Embedded C" fixed-point has been
526
added. For details, see the
527
<a href="http://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support">
529
<a href="http://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html">
530
user manual</a>. The support is not complete.
532
<li>A new print modifier <code>%r</code> for register operands in inline
533
assembler is supported. It will print the raw register number without the
534
register prefix '<code>r</code>':
536
/* Return the most significant byte of 'val', a 64-bit value. */
538
unsigned char msb (long long val)
541
__asm__ ("mov %0, %r1+7" : "=r" (c) : "r" (val));
544
The inline assembler in this example will generate code like
547
provided <code>c</code> is allocated to <code>R24</code> and
548
<code>val</code> is allocated to
549
<code>R8</code>…<code>R15</code>. This works because
550
the GNU assembler accepts plain register numbers without register prefix.
553
Static initializers with 3-byte symbols are supported now:
555
extern const __memx char foo;
556
const __memx void *pfoo = &foo;</pre>
557
This requires at least Binutils 2.23.
561
<h3>IA-32/x86-64</h3>
563
<li>Allow <code>-mpreferred-stack-boundary=3</code> for the x86-64
564
architecture with SSE extensions disabled. Since the x86-64 ABI
565
requires 16 byte stack alignment, this is ABI incompatible and
566
intended to be used in controlled environments where stack space
567
is an important limitation.
568
This option will lead to wrong code when functions compiled with 16 byte
569
stack alignment (such as functions from a standard library) are called
570
with misaligned stack. In this case, SSE instructions may lead to
571
misaligned memory access traps. In addition, variable arguments will
572
be handled incorrectly for 16 byte aligned objects (including x87
573
<code>long double</code> and <code>__int128</code>), leading to
574
wrong results. You must build all
575
modules with <code>-mpreferred-stack-boundary=3</code>, including any
576
libraries. This includes the system libraries and startup modules.</li>
577
<li>Support for the new Intel processor codename Broadwell with
578
<code>RDSEED</code>, <code>ADCX</code>, <code>ADOX</code>,
579
<code>PREFETCHW</code> is available through <code>-madx</code>,
580
<code>-mprfchw</code>, <code>-mrdseed</code> command-line options.</li>
581
<li> Support for the Intel RTM and HLE intrinsics, built-in
582
functions and code generation is available via <code>-mrtm</code> and
583
<code>-mhle</code>.</li>
584
<li> Support for the Intel FXSR, XSAVE and XSAVEOPT instruction
585
sets. Intrinsics and built-in functions are available
586
via <code>-mfxsr</code>, <code>-mxsave</code> and
587
<code>-mxsaveopt</code> respectively.</li>
588
<li>New <code>-maddress-mode=[short|long]</code> options for x32.
589
<code>-maddress-mode=short</code> overrides default 64-bit addresses to
590
32-bit by emitting the <code>0x67</code> address-size override prefix.
591
This is the default address mode for x32.</li>
592
<li> New built-in functions to detect run-time CPU type and ISA:
594
<li>A built-in function <code>__builtin_cpu_is</code> has been added to
595
detect if the run-time CPU is of a particular type. It returns a
596
positive integer on a match and zero otherwise. It accepts one string
597
literal argument, the CPU name. For example,
598
<code>__builtin_cpu_is("westmere")</code> returns a positive integer if
599
the run-time CPU is an Intel Core i7 Westmere processor. Please refer
601
href="http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions">
602
user manual</a> for the list of valid CPU names recognized.</li>
603
<li>A built-in function <code>__builtin_cpu_supports</code> has been
604
added to detect if the run-time CPU supports a particular ISA feature.
605
It returns a positive integer on a match and zero otherwise. It accepts
606
one string literal argument, the ISA feature. For example,
607
<code>__builtin_cpu_supports("ssse3")</code> returns a positive integer
608
if the run-time CPU supports SSSE3 instructions. Please refer to the <a
609
href="http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions">
610
user manual</a> for the list of valid ISA names recognized.</li>
612
<p>Caveat: If these built-in functions are called before any static
613
constructors are invoked, like during IFUNC initialization, then the CPU
614
detection initialization must be explicitly run using this newly provided
615
built-in function, <code>__builtin_cpu_init</code>. The initialization
616
needs to be done only once. For example, this is how the invocation would
617
look like inside an IFUNC initializer:</p>
619
static void (*some_ifunc_resolver(void))(void)
621
__builtin_cpu_init();
622
if (__builtin_cpu_is("amdfam10h") ...
623
if (__builtin_cpu_supports("popcnt") ...
627
<li> Function Multiversioning Support with G++:
628
<p>It is now possible to create multiple function versions each targeting a
629
specific processor and/or ISA. Function versions have the same signature
630
but different target attributes. For example, here is a program with
631
function versions:</p>
633
__attribute__ ((target ("default")))
639
__attribute__ ((target ("sse4.2")))
648
assert ((*p)() == foo());
653
<a href="http://gcc.gnu.org/wiki/FunctionMultiVersioning">wiki</a> for more
656
<li> The x86 backend has been improved to allow option
657
<code>-fschedule-insns</code> to work reliably.
658
This option can be used to schedule instructions better and leads to
659
improved performace in certain cases.</li>
660
<li> Windows MinGW-w64 targets (<code>*-w64-mingw*</code>) require at least r5437 from the Mingw-w64 trunk. </li>
661
<li>Support for new AMD family 15h processors (Steamroller core)
662
is now available through the <code>-march=bdver3</code> and
663
<code>-mtune=bdver3</code> options.</li>
664
<li>Support for new AMD family 16h processors (Jaguar core) is
665
now available through the <code>-march=btver2</code> and
666
<code>-mtune=btver2</code> options.</li>
669
<h3 id="frv">FRV</h3>
672
<li>This target now supports the <code>-fstack-usage</code>
673
command-line option.</li>
676
<h3 id="mips">MIPS</h3>
678
<li>GCC can now generate code specifically for the R4700, Broadcom XLP
679
and MIPS 34kn processors. The associated <code>-march</code> options
680
are <code>-march=r4700</code>, <code>-march=xlp</code>
681
and <code>-march=34kn</code> respectively.</li>
682
<li>GCC now generates better DSP code for MIPS 74k cores thanks
683
to further scheduling optimizations.</li>
684
<li>The MIPS port now supports the <code>-fstack-check</code>
686
<li>GCC now passes the <code>-mmcu</code> and <code>-mno-mcu</code>
687
options to the assembler.</li>
688
<li>Previous versions of GCC would silently accept <code>-fpic</code>
689
and <code>-fPIC</code> for <code>-mno-abicalls</code> targets
690
like <code>mips*-elf</code>. This combination was not intended
691
or supported, and did not generate position-independent code.
692
GCC 4.8 now reports an error when this combination is used.</li>
695
<h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
697
<li>SVR4 configurations (GNU/Linux, FreeBSD, NetBSD) no longer save,
698
restore or update the VRSAVE register by default. The respective
699
operating systems manage the VRSAVE register directly.</li>
700
<li>Large TOC support has been added for AIX through the command line
701
option <code>-mcmodel=large</code>.</li>
702
<li>Native Thread-Local Storage support has been added for AIX.</li>
703
<li>VMX (Altivec) and VSX instruction sets now are enabled implicitly when targetting processors that support those hardware features on AIX 6.1 and above.</li>
708
<li>This target will now issue a warning message whenever multiple fast
709
interrupt handlers are found in the same cpmpilation unit. This feature can
710
be turned off by the new <code>-mno-warn-multiple-fast-interrupts</code>
711
command-line option.</li>
714
<h3>S/390, System z</h3>
716
<li>Support for the IBM zEnterprise zEC12 processor has been
717
added. When using the <code>-march=zEC12</code> option, the
718
compiler will generate code making use of the following new
721
<li>load and trap instructions</li>
722
<li>2 new compare and trap instructions</li>
723
<li>rotate and insert selected bits - without CC clobber</li>
725
The <code>-mtune=zEC12</code> option enables zEC12 specific
726
instruction scheduling without making use of new
728
<li>Register pressure sensitive instruction scheduling is enabled
730
<li>The <code>ifunc</code> function attribute is enabled by default.</li>
731
<li><code>memcpy</code> and <code>memcmp</code> invokations on big
732
memory chunks or with run time lengths are not generated inline
733
anymore when tuning for z10 or higher. The purpose is to make
734
use of the IFUNC optimized versions in Glibc.</li>
739
<li>The default alignment settings have been reduced to be less aggressive.
740
This results in more compact code for optimization levels other than
741
<code>-Os</code>.</li>
743
<li>Improved support for the <code>__atomic</code> built-in functions:
745
<li>A new option <code>-matomic-model=<i>model</i></code> selects the
746
model for the generated atomic sequences. The following models are
749
<dt><code>soft-gusa</code></dt><dd>
750
Software gUSA sequences (SH3* and SH4* only). On SH4A targets this
751
will now also partially utilize the <code>movco.l</code> and
752
<code>movli.l</code> instructions. This is the default when the target
753
is <code>sh3*-*-linux*</code> or <code>sh4*-*-linux*</code>.</dd>
755
<dt><code>hard-llcs</code></dt><dd>
756
Hardware <code>movco.l</code> / <code>movli.l</code> sequences
759
<dt><code>soft-tcb</code></dt><dd>
760
Software thread control block sequences.</dd>
762
<dt><code>soft-imask</code></dt><dd>
763
Software interrupt flipping sequences (privileged mode only). This
764
is the default when the target is <code>sh1*-*-linux*</code> or
765
<code>sh2*-*-linux*</code>.</dd>
767
<dt><code>none</code></dt><dd>
768
Generates function calls to the respective <code>__atomic</code>
769
built-in functions. This is the default for SH64 targets or when
770
the target is not <code>sh*-*-linux*</code>.</dd>
773
<li>The option <code>-msoft-atomic</code> has been deprecated. It is
774
now an alias for <code>-matomic-model=soft-gusa</code>.</li>
776
<li>A new option <code>-mtas</code> makes the compiler generate
777
the <code>tas.b</code> instruction for the
778
<code>__atomic_test_and_set</code> built-in function regardless of the
779
selected atomic model.</li>
781
<li>The <code>__sync</code> functions in <code>libgcc</code> now reflect
782
the selected atomic model when building the toolchain.</li>
786
<li>Added support for the <code>mov.b</code> and <code>mov.w</code>
787
instructions with displacement addressing.</li>
789
<li>Added support for the SH2A instructions <code>movu.b</code> and
790
<code>movu.w</code>.</li>
792
<li>Various improvements to code generated for integer arithmetic.</li>
794
<li>Improvements to conditional branches and code that involves the T bit.
795
A new option <code>-mzdcbranch</code> tells the compiler to favor
796
zero-displacement branches. This is enabled by default for SH4* targets.
799
<li>The <code>pref</code> instruction will now be emitted by the
800
<code>__builtin_prefetch</code> built-in function for SH3* targets.</li>
802
<li>The <code>fmac</code> instruction will now be emitted by the
803
<code>fmaf</code> standard function and the <code>__builtin_fmaf</code>
804
built-in function.</li>
806
<li>The <code>-mfused-madd</code> option has been deprecated in favor of
807
the machine-independent <code>-ffp-contract</code> option. Notice that the
808
<code>fmac</code> instruction will now be generated by default for
809
expressions like <code>a * b + c</code>. This is due to the compiler
810
default setting <code>-ffp-contract=fast</code>.</li>
812
<li>Added new options <code>-mfsrra</code> and <code>-mfsca</code> to allow
813
the compiler using the <code>fsrra</code> and <code>fsca</code>
814
instructions on targets other than SH4A (where they are already enabled by
817
<li>Added support for the <code>__builtin_bswap32</code> built-in function.
818
It is now expanded as a sequence of <code>swap.b</code> and
819
<code>swap.w</code> instructions instead of a library function call.</li>
821
<li>The behavior of the <code>-mieee</code> option has been fixed and the
822
negative form <code>-mno-ieee</code> has been added to control the IEEE
823
conformance of floating point comparisons. By default <code>-mieee</code>
824
is now enabled and the option <code>-ffinite-math-only</code> implicitly
825
sets <code>-mno-ieee</code>.</li>
827
<li>Added support for the built-in functions
828
<code>__builtin_thread_pointer</code> and
829
<code>__builtin_set_thread_pointer</code>. This assumes that
830
<code>GBR</code> is used to hold the thread pointer of the current thread.
831
Memory loads and stores relative to the address returned by
832
<code>__builtin_thread_pointer</code> will now also utilize <code>GBR</code>
833
based displacement address modes.
838
<h3 id="sparc">SPARC</h3>
841
<li>Added optimized instruction scheduling for Niagara4.</li>
844
<h3 id="tilegx">TILE-Gx</h3>
847
<li>Added support for the <code>-mcmodel=<i>MODEL</i></code>
848
command-line option. The models supported are <code>small</code>
849
and <code>large</code>.</li>
852
<h3 id="v850">V850</h3>
855
<li>This target now supports the <code>E3V5</code> architecture via the use
856
of the new <code>-mv850e3v5</code> command-line option. It also has
857
experimental support for the e3v5 <code>LOOP</code> instruction which
858
can be enabled via the new <code>-mloop</code> command-line option.</li>
861
<h3 id="xstormy16">XStormy16</h3>
864
<li>This target now supports the <code>-fstack-usage</code>
865
command-line option.</li>
868
<h2 id="os">Operating Systems</h2>
870
<h3 id="windows">Windows (Cygwin)</h3>
872
<li>Executables are now linked against shared libgcc by default.
873
The previous default was to link statically, which can still be
874
done by explicitly specifying -static or -static-libgcc on the
875
command line. However it is strongly advised against, as it
876
will cause problems for any application that makes use of DLLs
877
compiled by GCC. It should be alright for a monolithic stand-alone
878
application that only links against the Windows OS DLLs, but
879
offers little or no benefit.</li>
883
<h2>Documentation improvements</h2>
888
<h2>Other significant improvements</h2>
895
<!-- ==================================================================== -->
897
<div class="copyright">
899
<address style="margin-top:0;">For questions related to the use of GCC,
900
please consult these web pages and the
901
<a href="http://gcc.gnu.org/onlinedocs/">GCC manuals</a>. If that fails,
902
the <a href="mailto:gcc-help@gcc.gnu.org">gcc-help@gcc.gnu.org</a>
903
mailing list might help.
904
Comments on these web pages and the development of GCC are welcome on our
905
developer list at <a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a>.
906
All of <a href="http://gcc.gnu.org/lists.html">our lists</a>
907
have public archives.
911
<a href="http://www.fsf.org">Free Software Foundation, Inc.</a>
912
Verbatim copying and distribution of this entire article is
913
permitted in any medium, provided this notice is preserved.</p>
915
<p style="margin-bottom:0;">These pages are
916
<a href="http://gcc.gnu.org/about.html">maintained by the GCC team</a>.
917
Last modified 2013-03-23<!-- IGNORE DIFF
918
--><a href="http://validator.w3.org/check/referer">.</a></p>
922
<!-- ==================================================================== -->
added
removed
.svn/pristine/f2/f2387014c5212cf69232954f4634095cfea85e3f.svn-base
