summaryrefslogtreecommitdiff
path: root/debian/NEWS.html
blob: 04793d3fb29bada01c86be1f8acd94cb4a8dd140 (plain)
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 &mdash; 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 &lt; (have ‘struct mystruct’ and ‘float’)
 #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a &lt; __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 (&amp;foo, ptr, sizeof (&amp;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>&lt;random&gt;</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>&lt;ext/random&gt;</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 &ndash; or a file using it via use
	association &ndash; 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&minus;b) &lt; 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 &ndash; in Fortran
    source code &ndash; 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&amp;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 &quot;Embedded&nbsp;C&quot; 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&nbsp;'<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>&hellip;<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 = &amp;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) = &amp;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>