From patchwork Wed Mar 13 09:29:16 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Benjamin Kosnik X-Patchwork-Id: 227208 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E1AB52C0099 for ; Wed, 13 Mar 2013 20:29:40 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1363771781; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Subject:Message-ID:Mime-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=42OqIdXzrIcCUXKRSloJ 0RzjRYM=; b=HcV5sw+rYWIv5W0rTRjtwOY9Q3iwhLgsS1dFpK1dhDHj5Eh9dJ7p tZfG3zquVe/dZrziT9kpq8cazjpBLuFuZeMDG8udNmUUlL6i9TPgaVbunfqqQ3Rv DeaxqeyJbJKpGq+EvsvKastHWpn0ER9s7Oy4MInNF9BctodOMf1Z044= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Subject:Message-ID:Mime-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=yL+4cRHUvAVdVhG8CIISGTTwE1BcG005vNbyS+Zhk3sf2W8m2SVrpEOI2HdZ5+ WSRuAI9BqHezcT5b90kVuT34q6PwrdvMgpkHeMGErkdinUBF6RKoFqJTdsHuI7TA R8WLJFLwMzW2GvjaV/2U4qpzuBJFvX+ycCUmXc882Kplw=; Received: (qmail 6553 invoked by alias); 13 Mar 2013 09:29:33 -0000 Received: (qmail 6544 invoked by uid 22791); 13 Mar 2013 09:29:32 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 09:29:20 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2D9TJpE001932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Mar 2013 05:29:19 -0400 Received: from oakwood (ovpn-113-39.phx2.redhat.com [10.3.113.39]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2D9THSm027195 for ; Wed, 13 Mar 2013 05:29:19 -0400 Date: Wed, 13 Mar 2013 02:29:16 -0700 From: Benjamin De Kosnik To: gcc-patches@gcc.gnu.org Subject: [wwwdocs] gcc-4.8/porting_to.html Message-ID: <20130313022916.0728c82e@oakwood> Mime-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hey! Here is the first pass at the 4.8 porting documentation. This seems to reflect the current trunk reality. I'm not quite sure to about the best way to talk about the more aggressive loop optimizations WRT undefined sematincs, but this seems reasonable. Of course, if anybody has better ideas, I'm all ears. best, Benjamin 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

+ + + +