Here is round two, as checked-in.
-benjamin
2013-03-13 Benjamin Kosnik <b...@redhat.com>
* htdocs/gcc-4.8/porting_to.html: Add.
* htdocs/gcc-4.8/changes.html: Add link.
Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.106
diff -c -p -r1.106 changes.html
*** changes.html 13 Mar 2013 15:20:56 -0000 1.106
--- changes.html 14 Mar 2013 00:20:47 -0000
*************** by this change.</p>
*** 54,59 ****
--- 54,66 ----
<code>--with-avrlibc=no</code>. If the compiler is configured for
RTEMS, the option is always turned off.</p>
+ <p>
+ More information on porting to GCC 4.8 from previous versions
+ of GCC can be found in
+ the <a href="http://gcc.gnu.org/gcc-4.8/porting_to.html";>porting
+ guide</a> for this release.
+ <p>
+
<h2>General Optimizer Improvements (and Changes)</h2>
<ul>
Index: porting_to.html
===================================================================
RCS file: porting_to.html
diff -N porting_to.html
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- porting_to.html 14 Mar 2013 00:20:47 -0000
***************
*** 0 ****
--- 1,232 ----
+ <html>
+
+ <head>
+ <title>Porting to GCC 4.8</title>
+ </head>
+
+ <body>
+ <h1>Porting to GCC 4.8</h1>
+
+ <p>
+ The GCC 4.8 release series differs from previous GCC releases in more
+ than the usual list of
+ <a href="http://gcc.gnu.org/gcc-4.8/changes.html";>changes</a>. Some of
+ these are a result of bug fixing, and some old behaviors have been
+ intentionally changed in order to support new standards, or relaxed
+ in standards-conforming ways to facilitate compilation or runtime
+ performance. Some of these changes are not visible to the naked eye
+ and will not cause problems when updating from older versions.
+ </p>
+
+ <p>
+ However, some of these changes are visible, and can cause grief to
+ users porting to GCC 4.8. This document is an effort to identify major
+ issues and provide clear solutions in a quick and easily searched
+ manner. Additions and suggestions for improvement are welcome.
+ </p>
+
+ <h2>General issues</h2>
+
+ <h3>New warnings</h3>
+
+ <p>Improvements to the GCC infrastructure allow improvements in
+ the ability of several existing warnings to spot problematic code. As
+ such, new warnings may exist for previously warning-free code that
+ uses
+ <code>-Wmaybe-uninitialized</code>.
+ </p>
+
+ <p> Although these warnings will
+ not result in compilation failure, often <code>-Wall</code> is used in
+ conjunction with <code>-Werror</code> and as a result, new warnings
+ are turned into new errors.
+ </p>
+
+ <p>As a workaround, remove <code>-Werror</code> until the new warnings
+ are fixed, or add <code>-Wno-maybe-uninitialized</code>.
+ </p>
+
+ <h3>More aggressive loop optimizations</h3>
+
+ <p>Improvements to the GCC infrastructure allow improvements in
+ the ability of the optimizers to transform loops. Some loops that previously
+ invoked undefined behavior may now be turned into endless loops.
+ </p>
+
+ <p>For example,</p>
+
+ <pre>
+ unsigned int foo()
+ {
+ unsigned int data_data[128];
+
+ for (int fd = 0; fd < 128; ++fd)
+ data_data[fd] = fd * (0x02000001); // error
+
+ return data_data[0];
+ }
+ </pre>
+
+ <p>
+ When fd is 64 or above, fd * 0x02000001 overflows, which is invalid in C/C++ for signed ints.
+ </p>
+
+ <p>
+ To fix, use the appropriate casts when converting between signed and
+ unsigned types to avoid overflows. Like so:
+ </p>
+
+ <pre>
+ data_data[fd] = (uint32_t) fd * (0x02000001U); // ok
+ </pre>
+
+ <h2>C language issues</h2>
+
+ <h3>New warnings for pointer access</h3>
+
+ <p>
+ The behavior of <code>-Wall</code> has changed and now includes the
+ new warning flag <code>-Wsizeof-pointer-memaccess</code>. This may
+ result in new warnings in code that compiled cleanly with previous
+ versions of GCC.
+ </p>
+
+ <p>For example,</p>
+
+ <pre>
+ #include <string.h>
+
+ struct A { };
+
+ int main(void)
+ {
+ A obj;
+ A* p1 = &obj;
+ A p2[10];
+
+ memset(p1, 0, sizeof(p1)); // error
+ memset(p1, 0, sizeof(*p1)); // ok, dereferenced
+ memset(p2, 0, sizeof(p2)); // ok, array
+
+ return 0;
+ }
+ </pre>
+
+ <p>Gives the following diagnostic:</p>
+ <pre>
+ warning: argument to âsizeofâ in âvoid* memset(void*, int, size_t)â call is the same expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
+ memset(p1, 0, sizeof(p1)); // error
+ ^
+ </pre>
+
+ <p>Although these warnings will not result in compilation failure,
+ often <code>-Wall</code> is used in conjunction with
+ <code>-Werror</code> and as a result, new warnings are turned into
+ new errors.</p>
+
+ <p>To fix, either re-write to use memcpy or dereference the last argument in the
+ offending memset call.</p>
+
+ <p>As a workaround, use
+ <code>-Wno-sizeof-pointer-memaccess</code>.
+
+ <h3>Pre-processor pre-includes</h3>
+
+ <p>
+ The GCC pre-processor may now pre-includes a file that defines certain
+ macros for the entirety of the translation unit. This allows
+ fully conformant implementations of C99/C11 and other standards that
+ require compiler or compiler + runtime macros that describe
+ implementation availability.
+ </p>
+
+ <p>
+ On linux, <stdc-predef.h> is pre-included.
+ </p>
+
+ <p>
+ This subtle change means that some more creative uses of the
+ pre-processor may now fail, with the following diagnostic:
+ </p>
+
+ <pre>
+ /usr/include/stdc-predef.h:0: error: Syntax error near '3'
+ </pre>
+
+ <p>As a workaround, the stdc-predef.h preinclude can be disabled with
+ the use of <code>-ffreestanding</code>. For non C/C++ code, use the pre-processor flag <code>-P</code>.
+
+
+ <h2>C++ language issues</h2>
+
+ <h3>New warnings for unused local typedefs</h3>
+
+ <p>
+ The behavior of <code>-Wall</code> has changed and now includes the
+ new warning flag <code>-Wunused-local-typedefs</code>. This may
+ result in new warnings in code that compiled cleanly with previous
+ versions of GCC.
+ </p>
+
+ <p>For example,</p>
+ <pre>
+ template<typename _Tp>
+ int
+ foo(_Tp __a)
+ {
+ typedef int return_type;
+ return 5;
+ }
+
+ int i = foo(415);
+ </pre>
+
+ <p>Gives the following diagnostic:</p>
+ <pre>
+ warning: typedef âreturn_typeâ locally defined but not used [-Wunused-local-typedefs]
+ typedef int return_type;
+ ^
+ </pre>
+
+ <p>Although these warnings will not result in compilation failure,
+ often <code>-Wall</code> is used in conjunction with
+ <code>-Werror</code> and as a result, new warnings are turned into
+ new errors.</p>
+
+ <p>To fix, simply remove the unused typedef.</p>
+
+ <p>As a workaround, use
+ <code>-Wno-unused-local-typedefs</code>.
+
+ <h3>Stray comma at the end of declaration now rejected</h3>
+
+ <p>
+ GCC by default no longer accepts code such as
+ </p>
+
+ <pre>
+ struct A { struct B *C,; };
+ </pre>
+
+ <p>This example now gives the following diagnostic:</p>
+ <pre>
+ error: stray â,â at end of member declaration
+ struct A { struct B *C,; };
+ ^
+ </pre>
+
+ <p>To fix, simply remove the unused comma.</p>
+
+ <!--
+ <h3>Java issues</h3>
+ -->
+
+ <h3>Links</h3>
+
+ <p>
+ Jakub Jelinek,
+ <a href="https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html";>Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19</p>
+
+
+ </body>
+ </html>
