From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 09:29:00 -0000 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 Content-Type: multipart/mixed; boundary="MP_/1xU1SFwME6nt+BUFrnS9FNK" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00449.txt.bz2 --MP_/1xU1SFwME6nt+BUFrnS9FNK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 329 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 --MP_/1xU1SFwME6nt+BUFrnS9FNK Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=20130313-1.patch Content-length: 7220 2013-03-13 Benjamin Kosnik * htdocs/gcc-4.8/porting_to.html: Add. Index: htdocs/gcc-4.8/porting_to.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 ---- + +=20 + + Porting to GCC 4.8 + +=20 + +

Porting to GCC 4.8

+=20 +

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

+=20 +

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

+=20 +

General issues

+=20 +

New warnings

+=20 +

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

+=20 +

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

+=20 +

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

+=20 +

More aggressive loop optimizations

+=20 +

Improvements to the GCC infrastructure allow improvements in + the ability of the optimizers to transform loops. Some loops that previou= sly + invoked undefined behavior may now be turned into endless loops. +

+=20 +

For example,

+=20 +

+ unsigned int foo()
+ {
+   unsigned int data_data[128];
+=20=20=20
+   for (int fd =3D 0; fd < 128; ++fd)
+     data_data[fd] =3D fd * (0x02000001); // error
+=20
+   return data_data[0];
+ }
+

+=20 +

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

+=20 +

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

+=20 +

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

+=20 +

C language issues

+=20 +

New warnings for pointer access

+=20 +

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

+=20 +

For example,

+=20 +

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

+=20 +

Gives the following diagnostic:

+ warning: argument to =E2=80=98sizeof=E2=80=99 in =E2=80=98void* memset(vo=
id*, int, size_t)=E2=80=99 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
+                        ^
+

+=20 +

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.

+=20=20 +

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

+=20=20 +

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

Pre-processor pre-includes

+=20 +

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

+=20 +

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

+=20 +

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

+=20 +

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

+=20 +

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

C++ language issues

+=20 +

New warnings for unused local typedefs

+=20 +

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

+=20 +

For example,

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

+=20 +

Gives the following diagnostic:

+ warning: typedef =E2=80=98return_type=E2=80=99 locally defined but not us=
ed [-Wunused-local-typedefs]
+      typedef int return_type;
+                  ^
+

+=20 +

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.

+=20=20 +

To fix, simply remove the unused typedef.

+=20=20 +

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

Stray comma at the end of declaration now rejected

+=20 +

+ GCC by default no longer accepts code such as +

+=20 +

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

+=20 +

This example now gives the following diagnostic:

+ error: stray =E2=80=98,=E2=80=99 at end of member declaration
+  struct A { struct B *C,; };
+                        ^
+

+=20 +

To fix, simply remove the unused comma.

+=20 + +=20 +

Links

+=20 +

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

+=20 +=20 + + --MP_/1xU1SFwME6nt+BUFrnS9FNK-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31822 invoked by alias); 13 Mar 2013 10:01:51 -0000 Received: (qmail 31807 invoked by uid 22791); 13 Mar 2013 10:01:48 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 10:01:42 +0000 Received: from archimedes.net-b.de (port-92-195-57-206.dynamic.qsc.de [92.195.57.206]) by mx01.qsc.de (Postfix) with ESMTP id 04CF03CD93; Wed, 13 Mar 2013 11:01:40 +0100 (CET) Message-ID: <51404E84.3070903@net-b.de> Date: Wed, 13 Mar 2013 10:01:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Benjamin De Kosnik CC: gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html References: <20130313022916.0728c82e@oakwood> In-Reply-To: <20130313022916.0728c82e@oakwood> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00450.txt.bz2 Benjamin De Kosnik wrote: > 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. Could you then add a link to the porting guide from changes.html, similar to last year's version? See http://gcc.gnu.org/gcc-4.7/changes.html and search for "porting guide". Tobias From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10408 invoked by alias); 13 Mar 2013 10:27:08 -0000 Received: (qmail 10356 invoked by uid 22791); 13 Mar 2013 10:27:07 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp1.uu.se (HELO smtp1.uu.se) (130.238.7.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 10:27:02 +0000 Received: from pilspetsen.it.uu.se (pilspetsen.it.uu.se [130.238.18.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bornea.its.uu.se (Postfix) with ESMTPS id 3D9E34003B; Wed, 13 Mar 2013 11:25:29 +0100 (CET) Received: (from mikpe@localhost) by pilspetsen.it.uu.se (8.14.5+Sun/8.14.5) id r2DAPJsJ028728; Wed, 13 Mar 2013 11:25:19 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20800.21519.527393.196910@pilspetsen.it.uu.se> Date: Wed, 13 Mar 2013 10:27:00 -0000 From: Mikael Pettersson To: Benjamin De Kosnik Cc: gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html In-Reply-To: <20130313022916.0728c82e@oakwood> References: <20130313022916.0728c82e@oakwood> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00452.txt.bz2 Benjamin De Kosnik writes: > > Hey! Here is the first pass at the 4.8 porting documentation. .. > + memset(p1, 0, sizeof(p1)); // error, use memcopy s/memcopy/memcpy/ > + memset(p1, 0, sizeof(p1)); // error, use memcopy likewise > +

To fix, either use memcopy or dereference the last argument in the likewise /Mikael From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31738 invoked by alias); 13 Mar 2013 10:37:43 -0000 Received: (qmail 31707 invoked by uid 22791); 13 Mar 2013 10:37:43 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_CP X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 10:37:33 +0000 Received: from [10.10.3.121] (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id CBA3C224D9; Wed, 13 Mar 2013 14:37:31 +0400 (MSK) Date: Wed, 13 Mar 2013 10:37:00 -0000 From: Alexander Monakov To: Mikael Pettersson cc: Benjamin De Kosnik , gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html In-Reply-To: <20800.21519.527393.196910@pilspetsen.it.uu.se> Message-ID: References: <20130313022916.0728c82e@oakwood> <20800.21519.527393.196910@pilspetsen.it.uu.se> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00453.txt.bz2 On Wed, 13 Mar 2013, Mikael Pettersson wrote: > Benjamin De Kosnik writes: > > > > Hey! Here is the first pass at the 4.8 porting documentation. > .. > > + memset(p1, 0, sizeof(p1)); // error, use memcopy > > s/memcopy/memcpy/ It doesn't make sense. memcpy from NULL src pointer? Alexander From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31964 invoked by alias); 13 Mar 2013 10:51:23 -0000 Received: (qmail 31955 invoked by uid 22791); 13 Mar 2013 10:51:22 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_CP X-Spam-Check-By: sourceware.org Received: from smtp1.uu.se (HELO smtp1.uu.se) (130.238.7.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 10:51:17 +0000 X-Spam-Score: -3.835 Received: from pilspetsen.it.uu.se (pilspetsen.it.uu.se [130.238.18.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bornea.its.uu.se (Postfix) with ESMTPS id 11D2B8825E; Wed, 13 Mar 2013 11:49:46 +0100 (CET) Received: (from mikpe@localhost) by pilspetsen.it.uu.se (8.14.5+Sun/8.14.5) id r2DAnafp029928; Wed, 13 Mar 2013 11:49:36 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20800.22976.774464.607006@pilspetsen.it.uu.se> Date: Wed, 13 Mar 2013 10:51:00 -0000 From: Mikael Pettersson To: Alexander Monakov Cc: Mikael Pettersson , Benjamin De Kosnik , gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html In-Reply-To: References: <20130313022916.0728c82e@oakwood> <20800.21519.527393.196910@pilspetsen.it.uu.se> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00454.txt.bz2 Alexander Monakov writes: > > > On Wed, 13 Mar 2013, Mikael Pettersson wrote: > > > Benjamin De Kosnik writes: > > > > > > Hey! Here is the first pass at the 4.8 porting documentation. > > .. > > > + memset(p1, 0, sizeof(p1)); // error, use memcopy > > > > s/memcopy/memcpy/ > > It doesn't make sense. memcpy from NULL src pointer? I was only referring to the spelling of memcpy(), whether the examples make sense or not is another issue (I didn't read the text very carefully). /Mikael From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16753 invoked by alias); 14 Mar 2013 00:26:35 -0000 Received: (qmail 16745 invoked by uid 22791); 14 Mar 2013 00:26:34 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CP 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; Thu, 14 Mar 2013 00:26:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2E0QPPx008374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Mar 2013 20:26:26 -0400 Received: from oakwood (ovpn-113-109.phx2.redhat.com [10.3.113.109]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2E0QMPx018266; Wed, 13 Mar 2013 20:26:24 -0400 Date: Thu, 14 Mar 2013 00:26:00 -0000 From: Benjamin De Kosnik To: Alexander Monakov Cc: Mikael Pettersson , gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html Message-ID: <20130313172621.1e3642a2@oakwood> In-Reply-To: References: <20130313022916.0728c82e@oakwood> <20800.21519.527393.196910@pilspetsen.it.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00484.txt.bz2 > It doesn't make sense. memcpy from NULL src pointer? Indeed, that doesn't make sense. Thanks. -benjamin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17894 invoked by alias); 14 Mar 2013 00:28:58 -0000 Received: (qmail 17886 invoked by uid 22791); 14 Mar 2013 00:28:58 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CP 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; Thu, 14 Mar 2013 00:28:52 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2E0Spqd001265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Mar 2013 20:28:52 -0400 Received: from oakwood (ovpn-113-109.phx2.redhat.com [10.3.113.109]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r2E0SpC5018400 for ; Wed, 13 Mar 2013 20:28:51 -0400 Date: Thu, 14 Mar 2013 00:28:00 -0000 From: Benjamin De Kosnik To: gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html Message-ID: <20130313172850.49f4b3d7@oakwood> In-Reply-To: <51404E84.3070903@net-b.de> References: <20130313022916.0728c82e@oakwood> <51404E84.3070903@net-b.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/NG3Opjb87bKjL+fPvYXzbsr" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00485.txt.bz2 --MP_/NG3Opjb87bKjL+fPvYXzbsr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 47 Here is round two, as checked-in. -benjamin --MP_/NG3Opjb87bKjL+fPvYXzbsr Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=20130313-3.wwdocs.patch Content-length: 8049 2013-03-13 Benjamin Kosnik * htdocs/gcc-4.8/porting_to.html: Add. * htdocs/gcc-4.8/changes.html: Add link. Index: changes.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.

*** 54,59 **** --- 54,66 ---- --with-avrlibc=3Dno. If the compiler is configured for RTEMS, the option is always turned off.

=20=20 +

+ More information on porting to GCC 4.8 from previous versions + of GCC can be found in + the porting + guide for this release. +

+=20

General Optimizer Improvements (and Changes)

=20=20

Porting to GCC 4.8

General issues

New warnings

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

For example,

+ unsigned int foo()
+ {
+   unsigned int data_data[128];
+=20=20=20
+   for (int fd =3D 0; fd < 128; ++fd)
+     data_data[fd] =3D fd * (0x02000001); // error
+=20
+   return data_data[0];
+ }
+

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

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

+     data_data[fd] =3D (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 flag -Wsizeof-pointer-memaccess. This may + result in new warnings in code that compiled cleanly with previous + versions of GCC. +

For example,

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

Gives the following diagnostic:

+ warning: argument to =E2=80=98sizeof=E2=80=99 in =E2=80=98void* memset(vo=
id*, int, size_t)=E2=80=99 call is the same expression as the destination; =
did you mean to dereference it? [-Wsizeof-pointer-memaccess]
+   memset(p1, 0, sizeof(p1)); // error
+                        ^
+

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 re-write to use memcpy or dereference the last argument= in the + offending memset call.

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

Pre-processor pre-includes

+ 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'=20
+

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

C++ language issues

New warnings for unused local typedefs

+ The behavior of -Wall has changed and now includes the + new warning flag -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;
+   }
+=20
+ int i =3D foo(415);
+

Gives the following diagnostic:

+ warning: typedef =E2=80=98return_type=E2=80=99 locally defined but not us=
ed [-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. +=20 +

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 =E2=80=98,=E2=80=99 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

+=20 +=20 + + --MP_/NG3Opjb87bKjL+fPvYXzbsr-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2462 invoked by alias); 14 Mar 2013 01:23:24 -0000 Received: (qmail 2449 invoked by uid 22791); 14 Mar 2013 01:23:22 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,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; Thu, 14 Mar 2013 01:23:14 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2E1NDiA027244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Mar 2013 21:23:14 -0400 Received: from oakwood (ovpn-113-109.phx2.redhat.com [10.3.113.109]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r2E1N2uZ011838 for ; Wed, 13 Mar 2013 21:23:02 -0400 Date: Thu, 14 Mar 2013 01:23:00 -0000 From: Benjamin De Kosnik To: gcc-patches@gcc.gnu.org Subject: Re: [wwwdocs] gcc-4.8/porting_to.html Message-ID: <20130313182300.42fcbc3e@oakwood> In-Reply-To: <20130313172850.49f4b3d7@oakwood> References: <20130313022916.0728c82e@oakwood> <51404E84.3070903@net-b.de> <20130313172850.49f4b3d7@oakwood> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/t3hQL31=5PMi+vhdFjlpBNM" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00486.txt.bz2 --MP_/t3hQL31=5PMi+vhdFjlpBNM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 89 > Here is round two, as checked-in. ... and here are the validation patches. -benjamin --MP_/t3hQL31=5PMi+vhdFjlpBNM Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=20130313-4.www.patch Content-length: 3084 2013-03-13 Benjamin Kosnik * htdocs/gcc-4.8/porting_to.html: Fix markup. * htdocs/gcc-4.8/changes.html: Same. Index: changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.107 diff -c -p -r1.107 changes.html *** changes.html 14 Mar 2013 00:25:06 -0000 1.107 --- changes.html 14 Mar 2013 01:09:43 -0000 *************** by this change.

*** 59,65 **** of GCC can be found in the

porting guide

General Optimizer Improvements (and Changes)

porting guide

General Optimizer Improvements (and Changes)

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

Pre-processor pre-includes

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

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

For example,

! template
    int
    foo(_Tp __a)
    {
--- 171,177 ----
  
  For example,
  ! template<typename _Tp>
    int
    foo(_Tp __a)
    {
*************** new errors.
*** 197,202 ****
--- 198,204 ----
   
  As a workaround, use
  -Wno-unused-local-typedefs.
+ 
  
  Stray comma at the end of declaration now rejected
  

--MP_/t3hQL31=5PMi+vhdFjlpBNM
Content-Type: text/x-patch
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=20130313-5.www.patch
Content-length: 1096

2013-03-13  Benjamin Kosnik  

        * htdocs/gcc-4.8/porting_to.html: Fix markup.

Index: porting_to.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/porting_to.html,v
retrieving revision 1.2
diff -c -p -r1.2 porting_to.html
*** porting_to.html	14 Mar 2013 01:13:56 -0000	1.2
--- porting_to.html	14 Mar 2013 01:17:37 -0000
*************** error: stray =E2=80=98,=E2=80=99 at end of member de
*** 227,233 ****
=20=20
  
  Jakub Jelinek,
!  Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.=
0-0.1.fc19

=20=20
=20=20
  
--- 227,233 ----
=20=20
  
  Jakub Jelinek,
!  Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.=
0-0.1.fc19
=20=20
=20=20
  

--MP_/t3hQL31=5PMi+vhdFjlpBNM--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: 
Received: (qmail 28139 invoked by alias); 14 Mar 2013 11:10:58 -0000
Received: (qmail 28128 invoked by uid 22791); 14 Mar 2013 11:10:57 -0000
X-SWARE-Spam-Status: No, hits=-3.9 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_CP
X-Spam-Check-By: sourceware.org
Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Mar 2013 11:10:47 +0000
Received: from [10.10.3.121] (unknown [83.149.199.91])	by smtp.ispras.ru (Postfix) with ESMTP id 4301B22BBC;	Thu, 14 Mar 2013 15:10:45 +0400 (MSK)
Date: Thu, 14 Mar 2013 11:10:00 -0000
From: Alexander Monakov 
To: Benjamin De Kosnik 
cc: gcc-patches@gcc.gnu.org
Subject: Re: [wwwdocs] gcc-4.8/porting_to.html
In-Reply-To: <20130313172850.49f4b3d7@oakwood>
Message-ID: 
References: <20130313022916.0728c82e@oakwood> <51404E84.3070903@net-b.de> <20130313172850.49f4b3d7@oakwood>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: 
List-Archive: 
List-Post: 
List-Help: 
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2013-03/txt/msg00497.txt.bz2


It still references memcpy in -Wsizeof-pointer-memaccess section.  Let me
suggest instead:

    To fix, properly pass the size of cleared memory as the last argument:
    either dereference the pointer argument to sizeof when clearing *one
    pointed-to element*, or in addition to that multiply sizeof(*p) by the
    number of elements to clear in the pointed-to array (which may not be
    known at the point of memset call without additional code changes).



I suppose a good chunk of problematic code hitting this warning would be doing
something like:

    void foo(int a[])
    {
      memset(a, 0, sizeof(a));
    }

... in which case dereferencing a in sizeof is probably the wrong thing to do.


Alexander

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: 
Received: (qmail 2076 invoked by alias); 14 Mar 2013 11:21:45 -0000
Received: (qmail 2068 invoked by uid 22791); 14 Mar 2013 11:21:44 -0000
X-SWARE-Spam-Status: No, hits=-7.5 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,TW_CP
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; Thu, 14 Mar 2013 11:21:37 +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 r2EBLag8029311	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Thu, 14 Mar 2013 07:21:37 -0400
Received: from zalov.cz (vpn1-4-156.ams2.redhat.com [10.36.4.156])	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2EBLYfq027033	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);	Thu, 14 Mar 2013 07:21:36 -0400
Received: from zalov.cz (localhost [127.0.0.1])	by zalov.cz (8.14.5/8.14.5) with ESMTP id r2EBLXDE000498;	Thu, 14 Mar 2013 12:21:33 +0100
Received: (from jakub@localhost)	by zalov.cz (8.14.5/8.14.5/Submit) id r2EBLW7G000497;	Thu, 14 Mar 2013 12:21:32 +0100
Date: Thu, 14 Mar 2013 11:21:00 -0000
From: Jakub Jelinek 
To: Alexander Monakov 
Cc: Benjamin De Kosnik , gcc-patches@gcc.gnu.org
Subject: Re: [wwwdocs] gcc-4.8/porting_to.html
Message-ID: <20130314112132.GC12913@tucnak.redhat.com>
Reply-To: Jakub Jelinek 
References: <20130313022916.0728c82e@oakwood> <51404E84.3070903@net-b.de> <20130313172850.49f4b3d7@oakwood> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: 
List-Archive: 
List-Post: 
List-Help: 
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2013-03/txt/msg00499.txt.bz2

On Thu, Mar 14, 2013 at 03:07:36PM +0400, Alexander Monakov wrote:
> 
> It still references memcpy in -Wsizeof-pointer-memaccess section.  Let me
> suggest instead:
> 
>     To fix, properly pass the size of cleared memory as the last argument:
>     either dereference the pointer argument to sizeof when clearing *one
>     pointed-to element*, or in addition to that multiply sizeof(*p) by the
>     number of elements to clear in the pointed-to array (which may not be
>     known at the point of memset call without additional code changes).
> 
> 
> 
> I suppose a good chunk of problematic code hitting this warning would be doing
> something like:
> 
>     void foo(int a[])
>     {
>       memset(a, 0, sizeof(a));
>     }
> 
> ... in which case dereferencing a in sizeof is probably the wrong thing to do.

The has different wording for the different cases, can suggest you to
1) remove addressof
2) provide an explicit length
3) dereference it

E.g. 1) is for cases like memset (&a, 0, sizeof (&a)); where removing the &
is usually the right thing to do.

	Jakub

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: 
Received: (qmail 96734 invoked by alias); 12 Apr 2015 11:02:20 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: 
List-Archive: 
List-Post: 
List-Help: 
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 96719 invoked by uid 89); 12 Apr 2015 11:02:20 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2
X-HELO: ainaz.pair.com
Received: from ainaz.pair.com (HELO ainaz.pair.com) (209.68.2.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 12 Apr 2015 11:02:18 +0000
Received: from tuna (ip-109-43-0-170.web.vodafone.de [109.43.0.170])	by ainaz.pair.com (Postfix) with ESMTPSA id 8E6B13F419;	Sun, 12 Apr 2015 07:02:14 -0400 (EDT)
Date: Sun, 12 Apr 2015 11:02:00 -0000
From: Gerald Pfeifer 
To: Benjamin De Kosnik , gcc-patches@gcc.gnu.org
Subject: Re: [wwwdocs] gcc-4.8/porting_to.html
In-Reply-To: <20130313022916.0728c82e@oakwood>
Message-ID: 
References: <20130313022916.0728c82e@oakwood>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-IsSubscribed: yes
X-SW-Source: 2015-04/txt/msg00523.txt.bz2

On Wed, 13 Mar 2013, Benjamin De Kosnik wrote:
> Hey! Here is the first pass at the 4.8 porting documentation. 

Lovely, thank you, I know this really has proven useful.

And with some unfortunate of delay, some updates from my side:

- Use run-time performance (instead of runtime performance which 
  Sandra established as the performance of the runtime, I think).
- Code does not use warning options per se.
- Undefined behavior is undefined regardless of how involved
  optimizers are.
- Improve markup, fix grammar, break long lines.
- Refer to GNU/Linux.

Applied.

Gerald
 
Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/porting_to.html,v
retrieving revision 1.5
diff -u -r1.5 porting_to.html
--- porting_to.html	11 Jun 2014 18:49:26 -0000	1.5
+++ porting_to.html	12 Apr 2015 00:14:41 -0000
@@ -13,7 +13,7 @@
 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
+in standards-conforming ways to facilitate compilation or run-time
 performance.  Some of these changes are not visible to the naked eye
 and will not cause problems when updating from older versions.
 
@@ -31,9 +31,8 @@
 
 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.
+such, new warnings may exist for previously warning-free code when
+using -Wmaybe-uninitialized.
 
 
  Although these warnings will
@@ -49,8 +48,8 @@
 
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.
+the ability of the optimizers to transform loops. Some loops that
+invoke undefined behavior may now be turned into endless loops.
 
 
 For example,
@@ -68,7 +67,8 @@
 
 
 
-When fd is 64 or above, fd * 0x02000001 overflows, which is invalid in C/C++ for signed ints.  
+When fd is 64 or above, fd * 0x02000001 overflows, which is invalid for
+signed ints in C/C++.
 
 
 
@@ -119,13 +119,13 @@
                        ^

Although these warnings will not result in compilation failure, -often -Wall is used in conjunction with +

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

To fix, either re-write to use memcpy or dereference the last argument in the -offending memset call.

To fix, either re-write to use memcpy or dereference the +last argument in the offending memset call.

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

Pre-processor pre-includes

-The GCC pre-processor may now pre-includes a file that defines certain +The GCC pre-processor may now pre-include 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 @@ -142,7 +142,7 @@

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

@@ -154,8 +154,9 @@ /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. +

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