2013-03-13 Benjamin Kosnik * htdocs/gcc-4.8/porting_to.html: Add. Index: htdocs/gcc-4.8/porting_to.html =================================================================== RCS file: htdocs/gcc-4.8/porting_to.html diff -N htdocs/gcc-4.8/porting_to.html *** /dev/null 1 Jan 1970 00:00:00 -0000 --- htdocs/gcc-4.8/porting_to.html 13 Mar 2013 09:23:12 -0000 *************** *** 0 **** --- 1,233 ---- + + + + Porting to GCC 4.8 + + + +

Porting to GCC 4.8

+ +

+ The GCC 4.8 release series differs from previous GCC releases in more + than the usual list of + changes. 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. +

+ +

+ 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. +

+ +

General issues

+ +

New warnings

+ +

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 + -Wmaybe-uninitialized. Note + that -Wall subsumes this warning flag. +

+ +

Although these warnings will + not result in compilation failure, often -Wall is used in + conjunction with -Werror and as a result, new warnings + are turned into new errors. +

+ +

As a workaround, remove -Werror until the new warnings + are fixed, or add -Wno-maybe-uninitialized. +

+ +

More aggressive loop optimizations

+ +

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. +

+ +

For example,

+ + 
+ 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];
+ }
+
+ +

+ When fd is 64 or above, fd * 0x02000001 overflows, which is invalid in C/C++ for signed ints. +

+ +

+ To fix, use the appropriate casts when converting between signed and + unsigned types to avoid overflows. Like so: +

+ + 
+     data_data[fd] = (uint32_t) fd * (0x02000001U); // ok
+
+ +

C language issues

+ +

New warnings for pointer access

+ +

+ The behavior of -Wall has changed and now includes the + new warning flags -Wsizeof-pointer-memaccess. This may + result in new warnings in code that compiled cleanly with previous + versions of GCC. +

+ +

For example,

+ + 
+ #include <string.h>
+ 
+ struct A { };
+ 
+ int main(void) 
+ {
+   A obj;
+   A* p1 = &obj;
+   A p2[10];
+ 
+   memset(p1, 0, sizeof(p1)); // error, use memcopy
+   memset(p1, 0, sizeof(*p1)); // ok, dereferenced
+   memset(p2, 0, sizeof(p2)); // ok, array
+ 
+   return 0;
+ }
+
+ +

Gives the following diagnostic:

+ 
+ 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, use memcopy
+                        ^
+
+ +

Although these warnings will not result in compilation failure, + often -Wall is used in conjunction with + -Werror and as a result, new warnings are turned into + new errors.

+ +

To fix, either use memcopy or dereference the last argument in the + offending memset call.

+ +

As a workaround, use + -Wno-sizeof-pointer-memaccess. + +

Pre-processor pre-includes

+ +

+ 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. +

+ +

+ On linux, <stdc-predef.h> is pre-included. +

+ +

+ This subtle change means that some more creative uses of the + pre-processor may now fail, with the following diagnostic: +

+ + 
+ /usr/include/stdc-predef.h:0: error: Syntax error near '3' 
+
+ +

As a workaround, the stdc-predef.h preinclude can be disabled with + the use of -ffreestanding. For non C/C++ code, use the pre-processor flag -P. + + +

C++ language issues

+ +

New warnings for unused local typedefs

+ +

+ The behavior of -Wall has changed and now includes the + new warning flags -Wunused-local-typedefs. This may + result in new warnings in code that compiled cleanly with previous + versions of GCC. +

+ +

For example,

+ 
+ template
+   int
+   foo(_Tp __a)
+   {
+     typedef int return_type;
+     return 5;
+   }
+ 
+ int i = foo(415);
+
+ +

Gives the following diagnostic:

+ 
+ warning: typedef ‘return_type’ locally defined but not used [-Wunused-local-typedefs]
+      typedef int return_type;
+                  ^
+
+ +

Although these warnings will not result in compilation failure, + often -Wall is used in conjunction with + -Werror and as a result, new warnings are turned into + new errors.

+ +

To fix, simply remove the unused typedef.

+ +

As a workaround, use + -Wno-unused-local-typedefs. + +

Stray comma at the end of declaration now rejected

+ +

+ GCC by default no longer accepts code such as +

+ + 
+ struct A { struct B *C,; };
+
+ +

This example now gives the following diagnostic:

+ 
+ error: stray ‘,’ at end of member declaration
+  struct A { struct B *C,; };
+                        ^
+
+ +

To fix, simply remove the unused comma.

+ + + +

Links

+ +

+ Jakub Jelinek, + Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19

+ + + +