OXIESEC PANEL
- Current Dir:
/
/
usr
/
share
/
doc
/
gcc-7-base
Server IP: 139.59.38.164
Upload:
Create Dir:
Name
Size
Modified
Perms
📁
..
-
11/10/2024 09:42:49 AM
rwxr-xr-x
📁
C++
-
01/31/2023 12:38:16 PM
rwxr-xr-x
📄
NEWS.gz
14.35 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
NEWS.html
54.73 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
README.Bugs
10.89 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
README.Debian.amd64.gz
4.29 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
README.ssp
1.14 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
TODO.Debian
1.61 KB
12/04/2019 02:25:41 PM
rw-r--r--
📄
changelog.Debian.gz
737 bytes
12/04/2019 02:25:41 PM
rw-r--r--
📄
changelog.gz
151.65 KB
11/14/2019 07:40:39 AM
rw-r--r--
📁
cilkrts
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📄
copyright
62.58 KB
12/04/2019 02:25:41 PM
rw-r--r--
📁
fortran
-
10/28/2024 06:50:10 AM
rwxr-xr-x
📁
gcc
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📄
gcc.css
3.15 KB
12/04/2019 02:25:41 PM
rw-r--r--
📁
gomp
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📁
itm
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📁
mpx
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📁
quadmath
-
01/31/2023 12:30:36 PM
rwxr-xr-x
📁
sanitizer
-
01/31/2023 12:30:36 PM
rwxr-xr-x
Editing: NEWS.html
Close
<?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>