/usr/share/doc/gcc-7-i686-linux-gnu-base/NEWS.html is in gcc-7-i686-linux-gnu 7.3.0-16ubuntu3cross1.
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 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 | <?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="stylesheet" type="text/css" href="gcc.css" />
<title>
GCC 7 Release Series — Changes, New Features, and Fixes
- GNU Project - Free Software Foundation (FSF)</title>
</head>
<!-- GCC maintainers, please do not hesitate to update/contribute entries
concerning those part of GCC you maintain! 2002-03-23, Gerald.
-->
<body>
<h1>GCC 7 Release Series<br />Changes, New Features, and Fixes</h1>
<p>
This page is a brief summary of some of the huge number of improvements in GCC 7.
For more information, see the
<a href="porting_to.html">Porting to GCC 7</a> page and the
<a href="../onlinedocs/index.html#current">full GCC documentation</a>.
</p>
<!-- .................................................................. -->
<h2>Disclaimer: GCC 7 has not been released yet, so this document is
a work-in-progress.</h2>
<!-- .................................................................. -->
<h2>Caveats</h2>
<ul>
<li>GCC now uses <a href="https://gcc.gnu.org/wiki/LRAIsDefault">LRA (a
new local register allocator) by default</a> for new targets.</li>
<li>The non-standard C++0x type traits
<code>has_trivial_default_constructor</code>,
<code>has_trivial_copy_constructor</code> and
<code>has_trivial_copy_assign</code> have been removed.</li>
<li>The libstdc++
<a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html">Profile
Mode</a> has been deprecated and will be removed in a future version.
</li>
<li>The Cilk+ extensions to the C and C++ languages have been deprecated.</li>
</ul>
<!-- .................................................................. -->
<h2 id="general">General Optimizer Improvements</h2>
<ul>
<li>GCC 7 can determine the return value or range of return values of
some calls to the <code>sprintf</code> family of functions and make
it available to other optimization passes. Some calls to the
<code>snprintf</code> function with a zero size argument can be folded
into constants. This optimization is included in <code>-O1</code>
and can be selectively controlled by the
<code>-fprintf-return-value</code> option.</li>
<li>A new store merging pass has been added. It merges constant stores to
adjacent memory locations into fewer, wider, stores.
It is enabled by the <code>-fstore-merging</code> option and at the
<code>-O2</code> optimization level or higher (and <code>-Os</code>).</li>
<li>A new code hoisting optimization has been added to the partial
redundancy elimination pass. It attempts to move evaluation of
expressions executed on all paths to the function exit as early as
possible, which helps primarily for code size, but can be useful for
speed of generated code as well. It is enabled by the
<code>-fcode-hoisting</code> option and at the <code>-O2</code>
optimization level or higher (and <code>-Os</code>).</li>
<li>A new interprocedural bitwise constant propagation optimization
has been added, which propagates knowledge about which bits of variables
are known to be zero (including pointer alignment information) across
the call graph. It is enabled by the <code>-fipa-bit-cp</code>
option if <code>-fipa-cp</code> is enabled as well, and is enabled
at the <code>-O2</code> optimization level and higher (and
<code>-Os</code>). This optimization supersedes interprocedural
alignment propagation of GCC 6, and therefore the
option <code>-fipa-cp-alignment</code> is now deprecated and
ignored.</li>
<li>A new interprocedural value range propagation optimization has been
added, which propagates integral ranges that variable values can be proven
to be within across the call graph. It is enabled by the
<code>-fipa-vrp</code> option and at the <code>-O2</code> optimization
level and higher (and <code>-Os</code>).</li>
<li>A new loop splitting optimization pass has been added. It splits
certain loops if they contain a condition that is always true on one
side of the iteration space and always false on the other into two
loops where each of the new two loops iterates just on one of the sides
of the iteration space and the condition does not need to be checked
inside of the loop. It is enabled by the <code>-fsplit-loops</code>
option and at the <code>-O3</code> optimization level or higher.</li>
<li>The shrink-wrapping optimization can now separate portions of
prologues and epilogues to improve performance if some of the
work done traditionally by prologues and epilogues is not needed
on certain paths. This is controlled by the
<code>-fshrink-wrap-separate</code> option, enabled by default.
It requires target support, which is currently only implemented in the
PowerPC and AArch64 ports.</li>
<li>AddressSanitizer gained a new sanitization option, <code>-fsanitize-address-use-after-scope</code>,
which enables sanitization of variables whose address is taken and used after a scope where the
variable is defined:
<blockquote><pre>
int
main (int argc, char **argv)
{
char *ptr;
{
char my_char;
ptr = &my_char;
}
*ptr = 123;
return *ptr;
}
<span class="boldred">==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958</span>
<span class="boldblue">WRITE of size 1 at 0x7fffb8dba990 thread T0</span>
#0 0x4006d4 in main /tmp/use-after-scope-1.c:10
#1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290)
#2 0x400739 in _start (/tmp/a.out+0x400739)
<span class="boldlime">Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame</span>
#0 0x40067f in main /tmp/use-after-scope-1.c:3
This frame has 1 object(s):
[32, 33) 'my_char' <span class="boldlime"><== Memory access at offset 32 is inside this variable</span>
</pre></blockquote>
The option is enabled by default with <code>-fsanitize=address</code> and disabled
by default with <code>-fsanitize=kernel-address</code>.
Compared to the LLVM compiler, where the option already exists,
the implementation in the GCC compiler has couple of improvements and advantages:
<ul>
<li>A complex usage of gotos and case labels are properly handled and should not
report any false positive or false negatives.
</li>
<li>C++ temporaries are sanitized.</li>
<li>Sanitization can handle invalid memory stores that are optimized out
by the LLVM compiler when using an optimization level.</li>
</ul>
</li>
<li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
UndefinedBehavior Sanitizer now diagnoses arithmetic overflows even on
arithmetic operations with generic vectors.</li>
<li>Version 5 of the <a
href="http://www.dwarfstd.org/Download.php">DWARF</a> debugging
information standard is supported through the <code>-gdwarf-5</code>
option. The DWARF version 4 debugging information remains the
default until debugging information consumers are adjusted.</li>
</ul>
<!-- .................................................................. -->
<h2 id="languages">New Languages and Language specific improvements</h2>
<!--
<ul>
<li> -->
OpenACC support in C, C++, and Fortran continues to be maintained and
improved.
See the <a href="https://gcc.gnu.org/wiki/OpenACC">OpenACC</a>
and <a href="https://gcc.gnu.org/wiki/Offloading">Offloading</a> wiki pages
for further information.
<!-- </li>
</ul>
-->
<h3 id="ada">Ada</h3>
<ul>
<li>On mainstream native platforms, Ada programs no longer require the stack
to be made executable in order to run properly.</li>
</ul>
<h3 id="brig">BRIG (HSAIL)</h3>
<p>Support for processing BRIG 1.0 files was added in this release.
BRIG is a binary format for HSAIL (Heterogeneous System Architecture
Intermediate Language). The BRIG frontend can be used for implementing
HSAIL "finalizers" (compilation of HSAIL to a native ISA) for gcc-supported
targets. An implementation of an HSAIL runtime library, libhsail-rt is
also included.</p>
<h3 id="c-family">C family</h3>
<ul>
<li>New command-line options have been added for the C and C++ compilers:
<ul>
<li><code>-Wimplicit-fallthrough</code> warns when a switch case falls
through. This warning has five different levels. The compiler is
able to parse a wide range of fallthrough comments, depending on
the level. It also handles control-flow statements, such as ifs.
It's possible to suppres the warning by either adding a fallthrough
comment, or by using a null statement: <code>__attribute__
((fallthrough));</code> (C, C++), or <code>[[fallthrough]];</code>
(C++17), or <code>[[gnu::fallthrough]];</code> (C++11/C++14).
This warning is enabled by <code>-Wextra</code>.</li>
<li><code>-Wpointer-compare</code> warns when a pointer is compared with
a zero character constant. Such code is now invalid in C++11 and
GCC rejects it. This warning is enabled by default.</li>
<li><code>-Wduplicated-branches</code> warns when an if-else has identical
branches.</li>
<li><code>-Wrestrict</code> warns when an argument passed to a
<code>restrict</code>-qualified parameter aliases with another
argument.</li>
<li><code>-Wmemset-elt-size</code> warns for <code>memset</code> calls,
when the first argument references an array, and the third argument is
a number equal to the number of elements of the array, but not the size
of the array. This warning is enabled by <code>-Wall</code>.</li>
<li><code>-Wint-in-bool-context</code> warns about suspicious uses of
integer values where boolean values are expected. This warning is
enabled by <code>-Wall</code>.</li>
<li><code>-Wswitch-unreachable</code> warns when a <code>switch</code>
statement has statements between the controlling expression and the
first case label which will never be executed. This warning is enabled
by default.</li>
<li><code>-Wexpansion-to-defined</code> warns when <code>defined</code> is
used outside <code>#if</code>. This warning is enabled by
<code>-Wextra</code> or <code>-Wpedantic</code>.</li>
<li><code>-Wregister</code> warns about uses of the <code>register</code>
storage specifier. In C++17 this keyword has been removed and for C++17
this is a pedantic warning enabled by default. The warning is not
emitted for the GNU Explicit Register Variables extension.</li>
<li><code>-Wvla-larger-than=N</code> warns about unbounded uses of
variable-length arrays, and about bounded uses of variable-length
arrays whose bound can be larger than <code>N</code> bytes.</li>
<li><code>-Wduplicate-decl-specifier</code> warns when a declaration
has duplicate <code>const</code>, <code>volatile</code>,
<code>restrict</code> or <code>_Atomic</code> specifier. This warning
is enabled by <code>-Wall</code>.</li>
</ul>
</li>
<li>GCC 6's C and C++ frontends were able to offer suggestions for
misspelled field names:
<blockquote><pre>
<b>spellcheck-fields.cc:52:13:</b> <span class="boldred">error:</span> <b>'struct s'</b> has no member named <b>'colour'</b>; did you mean <b>'color'</b>?
return ptr-><span class="boldred">colour</span>;
<span class="boldred">^~~~~~</span>
</pre></blockquote>
GCC 7 greatly expands the scope of these suggestions. Firstly, it
adds fix-it hints to such suggestions:
<blockquote><pre>
<b>spellcheck-fields.cc:52:13:</b> <span class="boldred">error:</span> <b>'struct s'</b> has no member named <b>'colour'</b>; did you mean <b>'color'</b>?
return ptr-><span class="boldred">colour</span>;
<span class="boldred">^~~~~~</span>
<span class="green">color</span>
</pre></blockquote>
The suggestions now cover many other things, such as misspelled
function names:
<blockquote><pre>
<b>spellcheck-identifiers.c:11:3:</b> <span class="boldmagenta">warning:</span> implicit declaration of function <b>'gtk_widget_showall'</b>; did you mean <b>'gtk_widget_show_all'</b>? [<span class="boldmagenta">-Wimplicit-function-declaration</span>]
<span class="boldmagenta">gtk_widget_showall</span> (w);
<span class="boldmagenta">^~~~~~~~~~~~~~~~~~</span>
<span class="green">gtk_widget_show_all</span>
</pre></blockquote>
misspelled macro names and enum values:
<blockquote><pre>
<b>spellcheck-identifiers.cc:85:11:</b> <span class="boldred">error:</span> <b>'MAX_ITEM'</b> undeclared here (not in a function); did you mean <b>'MAX_ITEMS'</b>?
int array[<span class="boldred">MAX_ITEM</span>];
<span class="boldred">^~~~~~~~</span>
<span class="green">MAX_ITEMS</span>
</pre></blockquote>
misspelled type names:
<blockquote><pre>
<b>spellcheck-typenames.c:7:14:</b> <span class="boldred">error:</span> unknown type name <b>'singed'</b>; did you mean <b>'signed'</b>?
void test (<span class="boldred">singed</span> char e);
<span class="boldred">^~~~~~</span>
<span class="green">signed</span>
</pre></blockquote>
and, in the C frontend, named initializers:
<blockquote><pre>
<b>test.c:7:20:</b> <span class="boldred">error:</span> <b>'struct s'</b> has no member named <b>'colour'</b>; did you mean <b>'color'</b>?
struct s test = { .<span class="boldred">colour</span> = 3 };
<span class="boldred">^~~~~~</span>
<span class="green">color</span>
</pre></blockquote></li>
<li>The preprocessor can now offer suggestions for misspelled
directives, e.g.:
<blockquote><pre>
<b>test.c:5:2:</b> <span class="boldred">error:</span>invalid preprocessing directive #endfi; did you mean #endif?
#<span class="boldred">endfi</span>
<span class="boldred">^~~~~</span>
<span class="green">endif</span>
</pre></blockquote></li>
<li>Warnings about format strings now underline the pertinent part of
the string, and can offer suggested fixes. In some cases, the
pertinent argument is underlined.
<blockquote><pre>
<b>test.c:51:29:</b> <span class="boldmagenta">warning:</span> format <b>'%s'</b> expects argument of type <b>'char *'</b>, but argument 3 has type <b>'int'</b> [<span class="boldmagenta">-Wformat=</span>]
printf ("foo: %d bar: <span class="boldmagenta">%s</span> baz: %d", 100, <span class="boldmagenta">i + j</span>, 102);
<span class="boldmagenta">~^</span> <span class="boldmagenta">~~~~~</span>
<span class="green">%d</span>
</pre></blockquote></li>
<li>The new <code>-Wdangling-else</code> command-line option has been split
out of <code>-Wparentheses</code> and warns about dangling <code>else</code>.</li>
<li><p>The <code>-Wshadow</code> warning has been split into three
variants. <code>-Wshadow=global</code> warns for any shadowing. This
is the default when using <code>-Wshadow</code> without any
argument. <code>-Wshadow=local</code> only warns for a local variable
shadowing another local variable or
parameter. <code>-Wshadow=compatible-local</code> only warns for a
local variable shadowing another local variable or parameter whose
type is compatible (in C++ compatible means that the type of the
shadowing variable can be converted to that of the shadowed variable).</p>
<p>The following example shows the different kinds of shadow
warnings:</p>
<blockquote><pre>
enum operation { add, count };
struct container { int nr; };
int
container_count (struct container c, int count)
{
int r = 0;
for (int count = 0; count > 0; count--)
{
struct container count = c;
r += count.nr;
}
return r;
}</pre></blockquote>
<p><code>-Wshadow=compatible-local</code> will warn for the parameter being
shadowed with the same type:</p>
<blockquote><pre>
<b>warn-test.c:8:12:</b> <span class="boldmagenta">warning:</span> declaration of '<b>count</b>' shadows a parameter [<span class="boldmagenta">-Wshadow=compatible-local</span>]
for (int <span class="boldmagenta">count</span> = 0; count > 0; count--)
<span class="boldmagenta">^~~~~</span>
<b>warn-test.c:5:42:</b> <span class="boldcyan">note:</span> shadowed declaration is here
container_count (struct container c, int <span class="boldcyan">count</span>)
<span class="boldcyan">^~~~~</span></pre></blockquote>
<p><code>-Wshadow=local</code> will warn for the above and for the shadowed
declaration with incompatible type:</p>
<blockquote><pre>
<b>warn-test.c:10:24:</b> <span class="boldmagenta">warning:</span> declaration of '<b>count</b>' shadows a previous local [<span class="boldmagenta">-Wshadow=local</span>]
struct container <span class="boldmagenta">count</span> = c;
<span class="boldmagenta">^~~~~</span>
<b>warn-test.c:8:12:</b> <span class="boldcyan">note:</span> shadowed declaration is here
for (int <span class="boldcyan">count</span> = 0; count > 0; count--)
<span class="boldcyan">^~~~~</span></pre></blockquote>
<p><code>-Wshadow=global</code> will warn for all of the above and the shadowing
of the global declaration:</p>
<blockquote><pre>
<b>warn-test.c:5:42:</b> <span class="boldmagenta">warning:</span> declaration of '<b>count</b>' shadows a global declaration [<span class="boldmagenta">-Wshadow</span>]
container_count (struct container c, int <span class="boldmagenta">count</span>)
<span class="boldmagenta">^~~~~</span>
<b>warn-test.c:1:23:</b> <span class="boldcyan">note:</span> shadowed declaration is here
enum operation { add, <span class="boldcyan">count</span> };
<span class="boldcyan">^~~~~</span></pre></blockquote>
</li>
<li>GCC 7 contains a number of enhancements that help detect buffer overflow
and other forms of invalid memory accesses.
<ul>
<li><p>The <code>-Walloc-size-larger-than=<i>size</i></code> option
detects calls to standard and user-defined memory allocation
functions decorated with attribute <code>alloc_size</code> whose
argument exceeds the specified <code><i>size</i></code>
(<code>PTRDIFF_MAX</code> by default). The option also detects
arithmetic overflow in the computation of the size in two-argument
allocation functions like <code>calloc</code> where the total size
is the product of the two arguments. Since calls with an excessive
size cannot succeed they are typically the result of programming
errors. Such bugs have been known to be the source of
security vulnerabilities and a target of exploits.
<code>-Walloc-size-larger-than=PTRDIFF_MAX</code> is included
in <code>-Wall</code>.</p>
<p>For example, the following call to <code>malloc</code> incorrectly
tries to avoid passing a negative argument to the function and
instead ends up unconditionally invoking it with an argument less
than or equal to zero. Since after conversion to the type of
the argument of the function (<code>size_t</code>) a negative
argument results in a value in excess of the maximum
<code>PTRDIFF_MAX</code> the call is diagnosed.</p>
<blockquote><pre>
void* f (int n)
{
return malloc (n > 0 ? 0 : n);
}
<span class="boldmagenta">warning: </span>argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [<span class="boldmagenta">-Walloc-size-larger-than=</span>]</pre></blockquote></li>
<li>The <code>-Walloc-zero</code> option detects calls to standard
and user-defined memory allocation functions decorated with attribute
<code>alloc_size</code> with a zero argument. <code>-Walloc-zero</code>
is not included in either <code>-Wall</code> or <code>-Wextra</code>
and must be explicitly enabled.</li>
<li>The <code>-Walloca</code> option detects all calls to the
<code>alloca</code> function in the program. <code>-Walloca</code>
is not included in either <code>-Wall</code> or <code>-Wextra</code>
and must be explicitly enabled.</li>
<li><p>The <code>-Walloca-larger-than=<i>size</i></code> option detects
calls to the <code>alloca</code> function whose argument either may
exceed the specified <code><i>size</i></code>, or that is not known
to be sufficiently constrained to avoid exceeding it.
<code>-Walloca-larger-than</code> is not included in either
<code>-Wall</code> or <code>-Wextra</code> and must be explicitly
enabled.</p>
<p>For example, compiling the following snippet with
<code>-Walloca-larger-than=1024</code> results in a warning because
even though the code appears to call <code>alloca</code> only with
sizes of 1kb and less, since <code>n</code> is signed, a negative
value would result in a call to the function well in excess of
the limit.</p>
<blockquote><pre>
void f (int n)
{
char *d;
if (n < 1025)
d = alloca (n);
else
d = malloc (n);
…
}
<span class="boldmagenta">warning: </span>argument to '<b>alloca</b> may be too large due to conversion from '<b>int</b>' to '<b>long unsigned int</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote>
<p>In contrast, a call to <code>alloca</code> that isn't bounded at all
such as in the following function will elicit the warning below
regardless of the <code><i>size</i></code> argument to the option.</p>
<blockquote><pre>
void f (size_t n)
{
char *d = alloca (n);
…
}
<span class="boldmagenta">warning: </span>unbounded use of '<b>alloca</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote></li>
<li><p>The <code>-Wformat-overflow=<i>level</i></code> option detects
certain and likely buffer overflow in calls to the <code>sprintf</code>
family of formatted output functions. Although the option is enabled
even without optimization it works best with <code>-O2</code> and
higher.</p>
<p>For example, in the following snippet the call to
<code>sprintf</code> is diagnosed because even though its
output has been constrained using the modulo operation it could
result in as many as three bytes if <code>mday</code> were negative.
The solution is to either allocate a larger buffer or make sure
the argument is not negative, for example by changing
<code>mday</code>'s type to <code>unsigned</code> or by making
the type of the second operand of the modulo expression
<code>unsigned</code>: <code>100U</code>.</p>
<blockquote><pre>
void* f (int mday)
{
char *buf = malloc (3);
sprintf (buf, "%02i", mday % 100);
return buf;
}
<span class="boldmagenta">warning: </span>'<b>sprintf</b> may write a terminating nul past the end of the destination [<span class="boldmagenta">-Wformat-overflow=</span>]
<span class="boldcyan">note: </span>'<b>sprintf</b>' output between 3 and 4 bytes into a destination of size 3</pre></blockquote></li>
<li><p>The <code>-Wformat-truncation=<i>level</i></code> option detects
certain and likely output truncation in calls to the
<code>snprintf</code> family of formatted output functions.
<code>-Wformat-truncation=1</code> is included in <code>-Wall</code>
and enabled without optimization but works best with <code>-O2</code>
and higher.</p>
<p>For example, the following function attempts to format an integer
between 0 and 255 in hexadecimal, including the <code>0x</code>
prefix, into a buffer of four charactars. But since the function
must always terminate output by the null character (<code>'\0'</code>)
such a buffer is only big enough to fit just one digit plus the prefix.
Therefore the <code>snprintf</code> call is diagnosed. To avoid
the warning either use a bigger buffer or handle the function's
return value which indicates whether or not its output has
been truncated.</p>
<blockquote><pre>
void f (unsigned x)
{
char d[4];
snprintf (d, sizeof d, "%#02x", x & 0xff);
…
}
<span class="boldmagenta">warning: </span>'<b>snprintf</b>' output may be truncated before the last format character [<span class="boldmagenta">-Wformat-truncation=</span>]
<span class="boldcyan">note: </span>'<b>snprintf</b>' output between 3 and 5 bytes into a destination of size 4</pre></blockquote></li>
<li>The <code>-Wnonnull</code> option has been enhanced to detect
a broader set of cases of passing null pointers to functions that
expect a non-null argument (those decorated with attribute
<code>nonnull</code>). By taking advantage of optimizations the
option can detect many more cases of the problem than in prior GCC
versions.</li>
<li><p>The <code>-Wstringop-overflow=<i>type</i></code> option detects
buffer overflow in calls to string handling functions like
<code>memcpy</code> and <code>strcpy</code>. The option relies on
<a href="https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html">
Object Size Checking</a> and has an effect similar to defining
the <code>_FORTIFY_SOURCE</code> macro.
<code>-Wstringop-overflow=2</code> is enabled by default.</p>
<p>For example, in the following snippet, because the call to
<code>strncat</code> specifies a maximum that allows the function to
write past the end of the destination, it is diagnosed. To correct
the problem and avoid the overflow the function should be called
with a size of at most <code>sizeof d - strlen(d) - 1</code>.</p>
<blockquote><pre>
void f (const char *fname)
{
char d[8];
strncpy (d, "/tmp/", sizeof d);
strncat (d, fname, sizeof d);
…
}
<span class="boldmagenta">warning: </span>specified bound 8 equals the size of the destination [<span class="boldmagenta">-Wstringop-overflow=</span>]</pre>
</blockquote></li>
</ul>
</li>
<li>The <code><limits.h></code> header provided by GCC defines
macros such as <code>INT_WIDTH</code> for the width in bits of
integer types, if <code>__STDC_WANT_IEC_60559_BFP_EXT__</code> is
defined before the header is included.
The <code><stdint.h></code> header defines such macros
as <code>SIZE_WIDTH</code> and <code>INTMAX_WIDTH</code> for the
width of some standard <code>typedef</code> names for integer types,
again if <code>__STDC_WANT_IEC_60559_BFP_EXT__</code> is defined
before the header is included; note that GCC's implementation of
this header is only used for freestanding compilations, not hosted
compilations, on most systems. These macros come from ISO/IEC TS
18661-1:2014.</li>
<li>The <code><float.h></code> header provided by GCC defines
the macro <code>CR_DECIMAL_DIG</code>, from ISO/IEC TS 18661-1:2014,
if <code>__STDC_WANT_IEC_60559_BFP_EXT__</code> is defined before
the header is included. This represents the number of decimal
digits for which conversions between decimal character strings and
binary formats, in both directions, are correctly rounded, and
currently has the value of <code>UINTMAX_MAX</code> on all systems,
reflecting that GCC's compile-time conversions are correctly rounded
for any number of digits.</li>
<li><p>New <code>__builtin_add_overflow_p</code>,
<code>__builtin_sub_overflow_p</code>,
<code>__builtin_mul_overflow_p</code> built-in functions have been added.
These work similarly to their siblings without the
<code>_p</code> suffix, but do not actually store the result of the
arithmetics anywhere, just return whether the operation would overflow.
Calls to these built-ins with integer constant arguments evaluate to
integer constants expressions.</p>
<p>For example, in the following, <code>c</code> is assigned the result
of <code>a * b</code> only if the multiplication does not overflow,
otherwise it is assigned the value zero. The multiplication is
performed at compile-time and without triggering
a <code>-Woverflow</code> warning.</p>
<blockquote><pre>enum {
a = 12345678,
b = 87654321,
c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
};</pre></blockquote></li>
</ul>
<h3 id="c">C</h3>
<ul>
<li><p>The C front end now supports type
names <code>_Float<i>N</i></code> for floating-point types with IEEE
interchange formats and <code>_Float<i>N</i>x</code> for
floating-point types with IEEE extended formats. These type names
come from ISO/IEC TS 18661-3:2015.</p>
<p>The set of types supported depends on the target for which GCC is
configured. Most targets
support <code>_Float32</code>, <code>_Float32x</code>
and <code>_Float64</code>. <code>_Float128</code> is supported on
targets where IEEE binary128 encoding was already supported
as <code>long double</code>
or <code>__float128</code>. <code>_Float64x</code> is supported on
targets where a type with either binary128 or Intel extended
precision format is available.</p>
<p>Constants with these types are supported using
suffixes <code>f<i>N</i></code>, <code>F<i>N</i></code>,
<code>f<i>N</i>x</code> and <code>F<i>N</i>x</code>
(e.g., <code>1.2f128</code> or <code>2.3F64x</code>). Macros such
as <code>FLT128_MAX</code> are defined
in <code><float.h></code>
if <code>__STDC_WANT_IEC_60559_TYPES_EXT__</code> is defined before
it is included.</p>
<p>These new types are always distinct from each other and
from <code>float</code>, <code>double</code> and <code>long
double</code>, even if they have the same encoding. Complex types
such as <code>_Complex _Float128</code> are also supported.</p>
<p>Type-generic built-in functions such
as <code>__builtin_isinf</code> support the new types, and the
following type-specific built-in functions have versions
(suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
new
types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
<li>Compilation with <code>-fopenmp</code> is now compatible with the
C11 <code>_Atomic</code> keyword.</li>
</ul>
<h3 id="cxx">C++</h3>
<ul>
<li>The C++ front end has experimental support for all of the current C++17
draft with the <code>-std=c++1z</code> or <code>-std=gnu++1z</code> flags,
including <tt>if constexpr</tt>, class template argument
deduction, <code>auto</code> template parameters, and structured bindings.
For a full list of new features,
see <a href="https://gcc.gnu.org/projects/cxx-status.html#cxx1z">the C++
status page</a>.</li>
<li>C++17 support for <code>new</code> of over-aligned types can be enabled
in other modes with the <code>-faligned-new</code> flag.</li>
<li>The C++17 evaluation order requirements can be selected in other modes
with the <code>-fstrong-eval-order</code> flag, or disabled in C++17 mode
with <code>-fno-strong-eval-order</code>.</li>
<li>The default semantics of inherited constructors has changed in all modes,
following <a href="http://wg21.link/p0136">P0136</a>. Essentially,
overload resolution happens as if calling the inherited constructor
directly, and the compiler fills in construction of the other bases and
members as needed. Most uses should not need any changes. The old
behavior can be restored with <code>-fno-new-inheriting-ctors</code>,
or <code>-fabi-version</code> less than 11.</li>
<li>The resolution of DR 150 on matching of template template parameters,
allowing default template arguments to make a template match a parameter,
is currently enabled by default in C++17 mode only. The default can be
overridden with <code>-f{no-,}new-ttp-matching</code>.</li>
<li>The C++ front end will now provide fix-it hints for some missing
semicolons, allowing for automatic fixes by IDEs:
<blockquote><pre>
<b>test.cc:4:11:</b> <span class="boldred">error:</span> expected <b>';'</b> after class definition
class a {}
<span class="boldred">^</span>
<span class="green">;</span>
</pre></blockquote></li>
<li><code>-Waligned-new</code> has been added to the C++ front end. It warns
about <code>new</code> of type with extended alignment without
<code>-faligned-new</code>.</li>
</ul>
<h4 id="libstdcxx">Runtime Library (libstdc++)</h4>
<ul>
<li>
The type of exception thrown by iostreams,
<code>std::ios_base::failure</code>, now uses the
<a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html"><code>cxx11</code>
ABI</a>.
</li>
<li>Experimental support for C++17, including the following new features:
<ul>
<li>
<code>std::string_view</code>;
</li>
<li>
<code>std::any</code>, <code>std::optional</code>,
and <code>std::variant</code>;
</li>
<li>
<code>std::invoke</code>, <code>std::is_invocable</code>,
<code>std::is_nothrow_invocable</code>, and <code>invoke_result</code>;
</li>
<li>
<code>std::is_swappable</code>,
and <code>std::is_nothrow_swappable</code>;
</li>
<li>
<code>std::apply</code>,
and <code>std::make_from_tuple</code>;
</li>
<li>
<code>std::void_t</code>, <code>std::bool_constant</code>,
<code>std::conjunction</code>, <code>std::disjunction</code>,
and <code>std::negation</code>;
</li>
<li>Variable templates for type traits;</li>
<li>Mathematical Special Functions;</li>
<li>
<code>std::chrono::floor</code>, <code>std::chrono::ceil</code>,
<code>std::chrono::round</code>, and <code>std::chrono::abs</code>;
</li>
<li>
<code>std::clamp</code>, <code>std::gcd</code>, <code>std::lcm</code>,
3-dimensional <code>std::hypot</code>;
</li>
<li>
<code>std::scoped_lock</code>, <code>std::shared_mutex</code>,
<code>std::atomic<T>::is_always_lock_free</code>;
</li>
<li>
<code>std::sample</code>, <code>std::default_searcher</code>,
<code>std::boyer_moore_searcher</code> and
<code>std::boyer_moore_horspool_searcher</code>;
</li>
<li>
Extraction and re-insertion of map and set nodes, <code>try_emplace</code>
members for maps, and functions for accessing containers
<code>std::size</code>, <code>std::empty</code>, and
<code>std::data</code>;
</li>
<li>
<code>std::shared_ptr</code> support for arrays,
<code>std::shared_ptr<T>::weak_type</code>,
<code>std::enable_shared_from_this<T>::weak_from_this()</code>,
and <code>std::owner_less<void></code>;
</li>
<li><code>std::byte</code>;</li>
<li><code>std::as_const</code>, <code>std::not_fn</code>,
<code>std::has_unique_object_representations</code>,
constexpr <code>std::addressof</code>.
</li>
</ul>
Thanks to Daniel Krügler, Tim Shen, Edward Smith-Rowland, and Ville Voutilainen for
work on the C++17 support.
</li>
<li>
A new power-of-two rehashing policy for use with the
<code>_Hashtable</code> internals, thanks to François Dumont.
</li>
</ul>
<h3 id="fortran">Fortran</h3>
<ul>
<li>
Support for a number of extensions for compatibility with legacy code
with new flags:
<ul>
<li>
<code>-fdec-structure</code>
Support for DEC <code>STRUCTURE</code> and <code>UNION</code>
</li>
<li>
<code>-fdec-intrinsic-ints</code>
Support for new integer intrinsics with B/I/J/K prefixes such as
<code>BABS</code>, <code>JIAND</code>...
</li>
<li>
<code>-fdec-math</code>
Support for additional math intrinsics, including <code>COTAN</code> and
degree-valued trigonometric functions such as <code>TAND</code>,
<code>ASIND</code>...
</li>
<li>
<code>-fdec</code>
Enable the <code>-fdec-*</code> family of extensions.
</li>
</ul>
</li>
<li>
New flag <code>-finit-derived</code> to allow default initialization of
derived-type variables.
</li>
<li>
Improved <code>DO</code> loops with step equal to 1 or -1, generates faster
code without a loop preheader. A new warning, <code>-Wundefined-do-loop</code>,
warns when a loop iterates either to <code>HUGE(i)</code> (with step equal
to 1), or to <code>-HUGE(i)</code> (with step equal to -1). Invalid behavior
can be caught at run time with <code>-fcheck=do</code> enabled:
<blockquote><pre>
program test
implicit none
integer(1) :: i
do i = -HUGE(i)+10, -HUGE(i)-1, -1
print *, i
end do
end program test
At line 8 of file do_check_12.f90
Fortran runtime error: Loop iterates infinitely</pre></blockquote>
</li>
<li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
>OpenMP specification</a> is now partially supported also in the
Fortran compiler; the largest missing item is structure element
mapping.</li>
<li>User-defined derived-type input/output (UDTIO) is added.</li>
<li>Derived type coarrays with allocable and pointer components
is partially supported.</li>
<li>Non-constant stop codes and error stop codes (Fortran 2015 feature).</li>
<li>Derived types with allocatable components of recursive type.</li>
<li>Intrinsic assignment to polymorphic variables.</li>
<li>Improved submodule support.</li>
<li>Improved diagnostics (polymorphic results in pure functions).</li>
</ul>
<h3 id="go">Go</h3>
<ul>
<li>GCC 7 provides a complete implementation of the Go 1.8.1
user packages.</li>
<li>Compared to the Go 1.8.1 toolchain, the garbage collector is more
conservative and less concurrent.</li>
<li>Escape analysis is available for experimental use via
the <code>-fgo-optimize-allocs</code> option.
The <code>-fgo-debug-escape</code> prints information useful for
debugging escape analysis choices.</li>
</ul>
<h3 id="java">Java (GCJ)</h3>
<p>The GCC Java frontend and associated libjava runtime library have been
removed from GCC.</p>
<!-- .................................................................. -->
<h2 id="jit">libgccjit</h2>
<p>The libgccjit API gained support for marking calls as requiring
tail-call optimization via a new entrypoint:
<a href="https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#gcc_jit_rvalue_set_bool_require_tail_call">gcc_jit_rvalue_set_bool_require_tail_call</a>.</p>
<p>libgccjit performs numerous checks at the API boundary, but
if these succeed, it previously ignored errors and other diagnostics emitted
within the core of GCC, and treated the compile of a gcc_jit_context
as having succeeded. As of GCC 7 it now ensures that if any diagnostics are
emitted, they are visible from the libgccjit API, and that the the context is
flagged as having failed.</p>
<!-- .................................................................. -->
<h2 id="targets">New Targets and Target Specific Improvements</h2>
<h3 id="aarch64">AArch64</h3>
<ul>
<li>
The ARMv8.3-A architecture is now supported. It can be used by
specifying the <code>-march=armv8.3-a</code> option.
</li>
<li>
The option <code>-msign-return-address=</code> is supported to enable
return address protection using ARMv8.3-A Pointer Authentication
Extensions. For more information on the arguments accepted by this
option, please refer to
<a href="https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options">
AArch64-Options</a>.
</li>
<li>
The ARMv8.2-A architecture and the ARMv8.2-A 16-bit Floating-Point
Extensions are now supported. They can be used by specifying the
<code>-march=armv8.2-a</code> or <code>-march=armv8.2-a+fp16</code>
options.
The 16-bit Floating-Point Extensions introduce new half-precision data
processing floating-point instructions.
</li>
<li>
Support has been added for the following processors
(GCC identifiers in parentheses):
ARM Cortex-A73 (<code>cortex-a73</code>),
Broadcom Vulcan (<code>vulcan</code>),
Cavium ThunderX CN81xx (<code>thunderxt81</code>),
Cavium ThunderX CN83xx (<code>thunderxt83</code>),
Cavium ThunderX CN88xx (<code>thunderxt88</code>),
Cavium ThunderX CN88xx pass 1.x (<code>thunderxt88p1</code>),
Cavium ThunderX 2 CN99xx (<code>thunderx2t99</code>),
Qualcomm Falkor (<code>falkor</code>).
The GCC identifiers can be used
as arguments to the <code>-mcpu</code> or <code>-mtune</code> options,
for example: <code>-mcpu=cortex-a73</code> or
<code>-mtune=vulcan</code> or as arguments to the equivalent target
attributes and pragmas.
</li>
</ul>
<h3 id="arc">ARC</h3>
<ul>
<li>
Add support for ARC HS and ARC EM processors.
</li>
<li>
Add support for ARC EM variation found in Intel QuarkSE SoCs.
</li>
<li>
Add support for NPS400 ARC700 based CPUs.
</li>
<li>
Thread Local Storage is now supported by ARC CPUs.
</li>
<li>
Fix errors for ARC600 when using 32x16 multiplier option.
</li>
<li>
Fix PIE for ARC CPUs.
</li>
<li>
New CPU templates are supported via multilib.
</li>
</ul>
<h3 id="arm">ARM</h3>
<ul>
<li>
Support for the ARMv5 and ARMv5E architectures has been deprecated
(which have no known implementations) and will be removed in a future
GCC release. Note that ARMv5T, ARMv5TE and ARMv5TEJ architectures
remain supported.
The values <code>armv5</code> and <code>armv5e</code> of
<code>-march</code> are thus deprecated.
</li>
<li>
The ARMv8.2-A architecture and the ARMv8.2-A 16-bit Floating-Point
Extensions are now supported. They can be used by specifying the
<code>-march=armv8.2-a</code> or <code>-march=armv8.2-a+fp16</code>
options.
The 16-bit Floating-Point Extensions introduce new half-precision data
processing floating-point instructions.
</li>
<li>
The ARMv8-M architecture is now supported in its two architecture
profiles: ARMv8-M Baseline and ARMv8-M Mainline with its DSP and
Floating-Point Extensions. They can be used by specifying the
<code>-march=armv8-m.base</code>, <code>armv8-m.main</code> or
<code>armv8-m.main+dsp</code> options.
</li>
<li>
Support has been added for the following processors
(GCC identifiers in parentheses): ARM Cortex-A73
(<code>cortex-a73</code>), ARM Cortex-M23 (<code>cortex-m23</code>) and
ARM Cortex-M33 (<code>cortex-m33</code>).
The GCC identifiers can be used
as arguments to the <code>-mcpu</code> or <code>-mtune</code> options,
for example: <code>-mcpu=cortex-a73</code> or
<code>-mtune=cortex-m33</code>.
</li>
<li>
A new command-line option <code>-mpure-code</code> has been added.
It does not allow constant data to be placed in code sections.
This option is only available when generating non-pic code for ARMv7-M
targets.
</li>
<li>
Support for the ACLE Coprocessor Intrinsics has been added. This enables
the generation of coprocessor instructions through the use of intrinsics
such as <code>cdp</code>, <code>ldc</code>, and others.
</li>
<li>
The configure option <code>--with-multilib-list</code> now accepts the
value <code>rmprofile</code> to build multilib libraries for a range of
embedded targets. See our
<a href="https://gcc.gnu.org/install/configure.html">installation
instructions</a> for details.
</li>
</ul>
<h3 id="avr">AVR</h3>
<ul>
<li>On the reduced Tiny cores, the <code>progmem</code>
<a href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html">variable
attribute</a>
is now properly supported. Respective read-only variables are located
in flash memory in section <code>.progmem.data</code>. No special
code is needed to access such variables; the compiler automatically
adds an offset of <code>0x4000</code> to all addresses, which is needed
to access variables in flash memory. As opposed to ordinary cores
where it is sufficient to specify the <code>progmem</code> attribute
with definitions, on the reduced Tiny cores the attribute also has to
be specified with (external) declarations:
<blockquote><pre>
extern const int array[] __attribute__((__progmem__));
int get_value2 (void)
{
/* Access via addresses array + 0x4004 and array + 0x4005. */
return array[2];
}
const int* get_address (unsigned idx)
{
/* Returns array + 0x4000 + 2 * idx. */
return &array[idx];
}</pre></blockquote></li>
<li>A new command-line option <code>-Wmisspelled-isr</code> has been added.
It turns off — or turns into errors —
warnings that are reported for interrupt service routines (ISRs)
which don't follow AVR-LibC's naming convention of prefixing
ISR names with <code>__vector</code>.</li>
<li><code>__builtin_avr_nops(<i>n</i>)</code> is a new
<a href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html">built-in
function</a>
that inserts <i>n</i> <code>NOP</code> instructions into
the instruction stream. <i>n</i> must be a value known at
compile time.</li>
</ul>
<!-- <h3 id="hsa">Heterogeneous Systems Architecture</h3> -->
<h3 id="x86">IA-32/x86-64</h3>
<ul>
<li>Support for the AVX-512 Fused Multiply Accumulation Packed Single precision
(4FMAPS), AVX-512 Vector Neural Network Instructions Word variable precision
(4VNNIW), AVX-512 Vector Population Count (VPOPCNTDQ) and Software
Guard Extensions (SGX) ISA extensions has been added.</li>
</ul>
<!-- <h3 id="mips">MIPS</h3> -->
<!-- <h3 id="mep">MeP</h3> -->
<!-- <h3 id="msp430">MSP430</h3> -->
<!-- <h3 id="nds32">NDS32</h3> -->
<h3 id="nvptx">NVPTX</h3>
<ul>
<li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
See the <a href="https://gcc.gnu.org/wiki/Offloading">Offloading Wiki</a>
on how to configure it.</li>
</ul>
<h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
<ul>
<li>The PowerPC port now uses LRA by default.</li>
<li>GCC now diagnoses inline assembly that clobbers register r2.
This has always been invalid code, and is no longer quietly
tolerated.</li>
<li>The PowerPC port's support for ISA 3.0 (<code>-mcpu=power9</code>)
has been enhanced to generate more of the new instructions by default, and
to provide more built-in functions to generate code for other new
instructions.</li>
<li>The configuration option <code>--enable-gnu-indirect-function</code>
is now enabled by default on PowerPC GNU/Linux builds.</li>
<li>The PowerPC port will now allow 64-bit and 32-bit integer types to be
allocated to the VSX vector registers (ISA 2.06 and above). In addition,
on ISA 3.0, 16-bit and 8-bit integer types can be allocated in the vector
registers. Previously, only 64-bit integer types were allowed in the
traditional floating point registers.</li>
<li>New options <code>-mstack-protector-guard=global</code>,
<code>-mstack-protector-guard=tls</code>,
<code>-mstack-protector-guard-reg=</code>, and
<code>-mstack-protector-guard-offset=</code> change how the stack
protector gets the value to use as canary.</li>
</ul>
<!-- <h3 id="s390">S/390, System z, IBM z Systems</h3> -->
<h3 id="riscv">RISC-V</h3>
<ul>
<li>Support for the RISC-V instruction set has been added.</li>
</ul>
<!-- <h3 id="rx">RX</h3> -->
<!-- <h3 id="sh">SH</h3> -->
<h3 id="sparc">SPARC</h3>
<ul>
<li>The SPARC port now uses LRA by default.</li>
<li>Support for the new Subtract-Extended-with-Carry instruction
available in SPARC M7 (Niagara 7) has been added.</li>
</ul>
<!-- .................................................................. -->
<h2 id="os">Operating Systems</h2>
<h3 id="aix">AIX</h3>
<ul>
<li>Visibility support has been enabled for AIX 7.1 and above.</li>
</ul>
<h3 id="fuchsia">Fuchsia</h3>
<ul>
<li>Support has been added for the
<a href="https://fuchsia.googlesource.com/">Fuchsia OS</a>.</li>
</ul>
<!-- <h3 id="dragonfly">DragonFly BSD</h3> -->
<!-- <h3 id="freebsd">FreeBSD</h3> -->
<!-- <h3 id="linux">Linux</h3> -->
<h3 id="rtems">RTEMS</h3>
<ul>
<li>The ABI changes on ARM so that no short enums are used by default.</li>
</ul>
<!-- <h3 id="solaris">Solaris</h3> -->
<!-- <h3 id="vxmils">VxWorks MILS</h3> -->
<!-- <h3 id="windows">Windows</h3> -->
<!-- .................................................................. -->
<!-- <h2>Documentation improvements</h2> -->
<!-- .................................................................. -->
<h2>Other significant improvements</h2>
<ul>
<li><code>-fverbose-asm</code> previously emitted information on the
meanings of assembly expressions. This has been extended so that
it now also prints comments showing the source lines that correspond
to the assembly, making it easier to read the generated assembly
(especially with larger functions).
For example, given this C source file:
<blockquote><pre>
int test (int n)
{
int i;
int total = 0;
for (i = 0; i < n; i++)
total += i * i;
return total;
}
</pre></blockquote>
<code>-fverbose-asm</code> now gives output similar to this for
the function body (when compiling for x86_64, with
<code>-Os</code>):
<blockquote><pre>
.text
.globl test
.type test, @@function
test:
.LFB0:
.cfi_startproc
# example.c:4: int total = 0;
xorl %eax, %eax # <retval>
# example.c:6: for (i = 0; i < n; i++)
xorl %edx, %edx # i
.L2:
# example.c:6: for (i = 0; i < n; i++)
cmpl %edi, %edx # n, i
jge .L5 #,
# example.c:7: total += i * i;
movl %edx, %ecx # i, tmp92
imull %edx, %ecx # i, tmp92
# example.c:6: for (i = 0; i < n; i++)
incl %edx # i
# example.c:7: total += i * i;
addl %ecx, %eax # tmp92, <retval>
jmp .L2 #
.L5:
# example.c:10: }
ret
.cfi_endproc
</pre></blockquote></li>
<li id="printing-fix-it-hints">Two new options have been added for
printing fix-it hints:
<ul>
<li><code>-fdiagnostics-parseable-fixits</code>
allows for fix-it hints to be emitted in a machine-readable
form, suitable for consumption by IDEs. For example, given:
<blockquote><pre>
<b>spellcheck-fields.cc:52:13:</b> <span class="boldred">error:</span> <b>'struct s'</b> has no member named <b>'colour'</b>; did you mean <b>'color'</b>?
return ptr-><span class="boldred">colour</span>;
<span class="boldred">^~~~~~</span>
<span class="green">color</span>
</pre></blockquote>
it will emit:
<blockquote><pre>
fix-it:"spellcheck-fields.cc":{52:13-52:19}:"color"
</pre></blockquote></li>
<li><code>-fdiagnostics-generate-patch</code> will print
a patch in "unified" format after any diagnostics are printed,
showing the result of applying all fix-it hints. For the above
example it would emit:
<blockquote><pre>
<b>--- spellcheck-fields.cc</b>
<b>+++ spellcheck-fields.cc</b>
<span class="boldmagenta">@@ -49,5 +49,5 @@</span>
color get_color(struct s *ptr)
{
<span class="boldred">- return ptr->colour;</span>
<span class="green">+ return ptr->color;</span>
}
</pre></blockquote></li></ul></li>
<li>The <code>gcc</code> and <code>g++</code> driver programs will now
provide suggestions for misspelled arguments to command-line options.
<blockquote><pre>
$ gcc -c test.c -ftls-model=global-dinamic
gcc: <span class="boldred">error:</span> unknown TLS model <b>'global-dinamic'</b>
gcc: <span class="boldcyan">note:</span> valid arguments to <b>'-ftls-model='</b> are: global-dynamic initial-exec local-dynamic local-exec; did you mean <b>'global-dynamic'</b>?
</pre></blockquote></li>
<li>The compiler will now provide suggestions for misspelled parameters.
<blockquote><pre>
$ gcc -c test.c --param max-early-inliner-iteration=3
cc1: <span class="boldred">error:</span> invalid --param name <b>'max-early-inliner-iteration'</b>; did you mean <b>'max-early-inliner-iterations'</b>?
</pre></blockquote></li>
<li>Profile-guided optimization (PGO) instrumentation, as well as test coverage (GCOV),
can newly instrument constructors (functions marks with <code>__attribute__((constructor)))</code>,
destructors and C++ constructors (and destructors) of classes that are used
as a type of a global variable.
</li>
<li>A new option <code>-fprofile-update=atomic</code> prevents creation of corrupted
profiles created during instrumentation run (<code>-fprofile=generate</code>)
of an application. Downside of the option is a speed penalty. Providing
<code>-pthread</code> on command line would result in selection of atomic
profile updating (when supports by a target).
</li>
<li>
<p>GCC's already extensive testsuite has gained some new
capabilities, to further improve the reliability of the compiler:</p>
<ul>
<li>GCC now has has an internal unit testing API and a suite of tests
for programmatic self-testing of subsystems.</li>
<li>GCC's C frontend has been extended so that it can parse dumps of
GCC's internal representations, allowing for DejaGnu tests
that more directly exercise specific optimization passes. This
covers both the
<a href="https://gcc.gnu.org/onlinedocs/gccint/GIMPLE-Tests.html">
GIMPLE representation</a> (for testing higher-level
optimizations) and the
<a href="https://gcc.gnu.org/onlinedocs/gccint/RTL-Tests.html">
RTL representation</a>, allowing for more direct testing of
lower-level details, such as register allocation and instruction
selection.</li>
</ul>
</li>
</ul>
<!-- <h2><a name="7.1">GCC 7.1</a></h2>
<p>This is the <a href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.1">list
of problem reports (PRs)</a> from GCC's bug tracking system that are
known to be fixed in the 7.1 release. This list might not be
complete (that is, it is possible that some PRs that have been fixed
are not listed here).</p>
-->
<!-- ==================================================================== -->
<div class="copyright">
<address>For questions related to the use of GCC,
please consult these web pages and the
<a href="https://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="https://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>These pages are
<a href="https://gcc.gnu.org/about.html">maintained by the GCC team</a>.
Last modified 2017-05-01<!-- IGNORE DIFF
--><a href="http://validator.w3.org/check/referer">.</a></p>
</div>
<!-- ==================================================================== -->
</body>
</html>
|