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