From patchwork Wed Oct 22 15:29:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 402191 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id AE43914007B for ; Thu, 23 Oct 2014 02:29:50 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=fkO2LV9i4lYC8rT2Gv7fXJYlsIrv2752YxlK/cuYNlzr8x0uDbrpL XK3y40PW3jqZcqPeTd1aCNeDlpWnyVVc/0vFa9mnvO0HZMoRVQRCOLfd93nM63WH mOl1FL1AZbqcplUitIijWSEGisp8/TBXIbj3YharJ+woaz92s8hnEQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=enCt+QPmf+yzCaWUvPzZPLoCyZc=; b=UieONbT+iznD/PbDauFq Dsy/Ohuu+FD2kkDfJMUV3Z0oKMwvherHbo8Ruhv8kwSZH6nk9TOl4Hl8AwTchpQ2 47xgFT/lVY/IU/LKQ5n1fPjGoj3h2Wf1UboJn8L9R+XnhFKCNN2G/+qco4uglvCd x+V1Xo35QhInGBwpZo0kA8Q= Received: (qmail 719 invoked by alias); 22 Oct 2014 15:29:23 -0000 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 Received: (qmail 643 invoked by uid 89); 22 Oct 2014 15:29:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Oct 2014 15:29:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MFTIvY030194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 22 Oct 2014 11:29:18 -0400 Received: from redhat.com (ovpn-116-16.ams2.redhat.com [10.36.116.16]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MFTEJh028510 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Oct 2014 11:29:16 -0400 Date: Wed, 22 Oct 2014 17:29:13 +0200 From: Marek Polacek To: GCC Patches Subject: [wwwdocs] Add porting_to.html, describe gnu11 changes Message-ID: <20141022152913.GC10501@redhat.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) The following adds the porting_to.html document for GCC 5 and documents issues arising from moving the default to gnu11. Ok? Marek --- porting_to.html.mp 2014-10-22 17:25:42.122367884 +0200 +++ porting_to.html 2014-10-22 17:23:14.442645393 +0200 @@ -0,0 +1,235 @@ + + + +Porting to GCC 5 + + + +

Porting to GCC 5

+ +

+The GCC 5 release series differs from previous GCC releases in +a number of ways. 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 run-time +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 5. 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. +

+ + + + + + + +

C language issues

+ +

Default standard is now GNU11

+ +

GCC defaults to -std=gnu11 instead of -std=gnu89. +This brings several changes that the users should be aware of. The following +paragraphs describe some of these changes and suggest how to deal with them. +

+ +

Different semantincs for inline functions

While -std=gnu89 employs the GNU89 inline semantics, +-std=gnu11 uses the C99 inline semantics. The C99 inline semantics +requires that if a function with external linkage is declared with +inline function specifier, it also has to be defined in the same +translation unit. Consequently, GCC now warns if it sees a TU such as the +following:

+ +


+  inline int foo (void);
+

+ +

This example now gives the following diagnostic:

+ +

+f.c:1:12: warning: inline function 'foo' declared but never defined
+   inline int foo (void);
+              ^
+

+ +

Furthermore, there is a difference between extern inline and +inline: +

C99 inline: no externally visible function is generated; + if the function is referenced in this TU, external definition has to + exist in another TU;
C99 extern inline: externally visible function is generated; +
GNU89 inline: same as C99 extern inline;
GNU89 extern inline: same as C99 inline.

+ +In other words, ISO C99 requires that exactly one C source file has the +callable copy of the inline function. Consider the following program:

+ +


+  inline int
+  foo (void)
+  {
+    return 42;
+  }
+
+  int
+  main (void)
+  {
+    return foo ();
+  }
+

+ +

The program above will not link with the C99 inline semantics, because there +is not an out-of-line function foo generated. To fix this, add the +following declaration:

+ +


+  extern inline int foo (void);
+

+ +

This declaration ensures that an externally visible function be emitted. +To enforce the GNU89 inline semantics, you can either use the +-fgnu89-inline command-line option, or mark a function with the +gnu_inline attribute.

+ +

Some warnings are enabled by default

+ +

The C99 mode enables some warnings by default. For instance, GCC warns +about missing declarations of functions:

+ +


+  int
+  foo (void)
+  {
+    return bar ();
+  }
+

+ +

This example now gives the following diagnostic:

+ +

+w.c:4:10: warning: implicit declaration of function 'bar' [-Wimplicit-function-declaration]
+   return bar ();
+          ^
+

+ +

To suppress this warning add the proper declaration:

+ +


+  int bar (void);
+

+ +

or use -Wno-implicit-function-declaration.

+ +

Another warning that is now turned on by default is the warning about +implicit int, as in the following snippet:

+ +


+  foo (u)
+  {
+    return u;
+  }
+

+ +

This example now gives the following diagnostic:

+ +

+q.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
+   foo (u)
+   ^
+q.c: In function 'foo':
+q.c:1:1: warning: type of 'u' defaults to 'int' [-Wimplicit-int]
+

+ +

To suppress this warning just add the proper types:

+ +


+  int
+  foo (int u)
+  {
+    return u;
+  }
+

+ +

or use -Wno-implicit or -Wno-implicit-int.

+ +

Another warning that is now turned on by default is the warning about +returning no value in function returning non-void:

+ +


+  int
+  foo (void)
+  {
+    return;
+  }
+

+ +

This example now gives the following diagnostic:

+ +

+q.c:4:3: warning: 'return' with no value, in function returning non-void
+   return;
+   ^
+

+ +

The fix is either to specify a proper return value, or to declare the return +value of foo as void. + +

Initializing statics with compound literals

+ +

Previously, initializing objects with static storage duration with compound +literals was only allowed in the GNU89 mode. This restriction has been lifted +and currently it is possible to do this even in C99/C11 mode. The following +snippet is an example of such initialization:

+ +


+  struct T { int i; };
+  struct S { struct T t; };
+  static struct S s = (struct S) { .t = { 42 } };
+

+ +

We used to reject such code in C99/C11 mode:

+ +

+q.c:3:29: error: initializer element is not constant
+   static struct S s = (struct S) { .t = { 42 } };
+                               ^
+

+ +

Note that using -Wpedantic will cause a warning be emitted:

+ +

+q.c:3:29: warning: initializer element is not constant [-Wpedantic]
+   static struct S s = (struct S) { .t = { 42 } };
+                       ^
+

+ + + + + + + + +