[wwwdocs] Add porting_to.html, describe gnu11 changes

Tue Oct 28 14:52:00 GMT 2014

Ping?

On Wed, Oct 22, 2014 at 07:16:31PM +0200, Marek Polacek wrote:
> On Wed, Oct 22, 2014 at 09:56:08AM -0700, Mike Stump wrote:
> > On Oct 22, 2014, at 8:29 AM, Marek Polacek <polacek@redhat.com> wrote:
> > > The following adds the porting_to.html document for GCC 5 and
> > > documents issues arising from moving the default to gnu11.
> > 
> > So, one way for a person to port a large project, would be just to select gnu89 as the target language for the project.  Should be a one line change, if their project is structured well.  Seems like we should mention that at the top.
> 
> Good point.  I've added something like that.
>  
> > I think we should leave out headers with empty contents.  For example, Java issues.  Donâ€™t expect there to be any, so, no need to have the header.
> 
> I've dropped those, thanks.
> 
> Another suggestions are welcome!
> 
> --- porting_to.html.mp	2014-10-22 17:25:42.122367884 +0200
> +++ porting_to.html	2014-10-22 19:12:49.809720491 +0200
> @@ -0,0 +1,214 @@
> +<html>
> +
> +<head>
> +<title>Porting to GCC 5</title>
> +</head>
> +
> +<body>
> +<h1>Porting to GCC 5</h1>
> +
> +<p>
> +The GCC 5 release series differs from previous GCC releases in
> +<a href="changes.html">a number of ways</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 run-time
> +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 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.
> +</p>
> +
> +<h2>C language issues</h2>
> +
> +<h3>Default standard is now GNU11</h3>
> +
> +<p>GCC defaults to <code>-std=gnu11</code> instead of <code>-std=gnu89</code>.
> +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.
> +
> +Some users might prefer to stay with gnu89, in which case we suggest to use
> +the <code>-std=gnu89</code> command-line option, perhaps by putting it in
> +<code>override CFLAGS</code> or similarly in the Makefile.</p>
> +
> +<h4>Different semantics for inline functions</h4>
> +<p>While <code>-std=gnu89</code> employs the GNU89 inline semantics,
> +<code>-std=gnu11</code> uses the C99 inline semantics.  The C99 inline semantics
> +requires that if a function with external linkage is declared with
> +<code>inline</code> 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:</p>
> +
> +<pre><code>
> +  inline int foo (void);
> +</code></pre>
> +
> +<p>This example now gives the following diagnostic:</p>
> +
> +<pre>
> +<b>f.c:1:12:</b> <b style='color:magenta'>warning:</b> inline function <b>'foo'</b> declared but never defined
> +   inline int foo (void);
> +              <b style='color:lime'>^</b>
> +</pre>
> +
> +<p>Furthermore, there is a difference between <code>extern inline</code> and
> +<code>inline</code>:
> +<ul>
> +  <li>C99 <code>inline</code>: no externally visible function is generated;
> +      if the function is referenced in this TU, external definition has to
> +      exist in another TU;</li>
> +  <li>C99 <code>extern inline</code>: externally visible function is generated;
> +      </li>
> +  <li>GNU89 <code>inline</code>: same as C99 <code>extern inline</code>;</li>
> +  <li>GNU89 <code>extern inline</code>: same as C99 <code>inline</code>.</li>
> +</ul>
> +
> +In other words, ISO C99 requires that exactly one C source file has the
> +callable copy of the inline function.  Consider the following program:</p>
> +
> +<pre><code>
> +  inline int
> +  foo (void)
> +  {
> +    return 42;
> +  }
> +
> +  int
> +  main (void)
> +  {
> +    return foo ();
> +  }
> +</code></pre>
> +
> +<p>The program above will not link with the C99 inline semantics, because there
> +is not an out-of-line function <code>foo</code> generated.  To fix this, add the
> +following declaration:</p>
> +
> +<pre><code>
> +  extern inline int foo (void);
> +</code></pre>
> +
> +<p>This declaration ensures that an externally visible function be emitted.
> +To enforce the GNU89 inline semantics, you can either use the
> +<code>-fgnu89-inline</code> command-line option, or mark a function with the
> +<code>gnu_inline</code> attribute.</p>
> +
> +<h4>Some warnings are enabled by default</h4>
> +
> +<p>The C99 mode enables some warnings by default.  For instance, GCC warns
> +about missing declarations of functions:</p>
> +
> +<pre><code>
> +  int
> +  foo (void)
> +  {
> +    return bar ();
> +  }
> +</code></pre>
> +
> +<p>This example now gives the following diagnostic:</p>
> +
> +<pre>
> +<b>w.c:4:10:</b> <b style='color:magenta'>warning:</b> implicit declaration of function <b>'bar'</b> [-Wimplicit-function-declaration]
> +   return bar ();
> +          <b style='color:lime'>^</b>
> +</pre>
> +
> +<p>To suppress this warning add the proper declaration:</p>
> +
> +<pre><code>
> +  int bar (void);
> +</code></pre>
> +
> +<p>or use <code>-Wno-implicit-function-declaration</code>.</p>
> +
> +<p>Another warning that is now turned on by default is the warning about
> +implicit int, as in the following snippet:</p>
> +
> +<pre><code>
> +  foo (u)
> +  {
> +    return u;
> +  }
> +</code></pre>
> +
> +<p>This example now gives the following diagnostic:</p>
> +
> +<pre>
> +<b>q.c:1:1:</b> <b style='color:magenta'>warning:</b> return type defaults to <b>'int'</b> [-Wimplicit-int]
> +   foo (u)
> +   <b style='color:lime'>^</b>
> +<b>q.c:</b> In function <b>'foo'</b>:
> +<b>q.c:1:1:</b> <b style='color:magenta'>warning:</b> type of <b>'u'</b> defaults to <b>'int'</b> [-Wimplicit-int]
> +</pre>
> +
> +<p>To suppress this warning just add the proper types:</p>
> +
> +<pre><code>
> +  int
> +  foo (int u)
> +  {
> +    return u;
> +  }
> +</code></pre>
> +
> +<p>or use <code>-Wno-implicit</code> or <code>-Wno-implicit-int</code>.</p>
> +
> +<p>Another warning that is now turned on by default is the warning about
> +returning no value in function returning non-void:</p>
> +
> +<pre><code>
> +  int
> +  foo (void)
> +  {
> +    return;
> +  }
> +</code></pre>
> +
> +<p>This example now gives the following diagnostic:</p>
> +
> +<pre>
> +<b>q.c:4:3:</b> <b style='color:magenta'>warning:</b> <b>'return'</b> with no value, in function returning non-void
> +   return;
> +   <b style='color:lime'>^</b>
> +</pre>
> +
> +<p>The fix is either to specify a proper return value, or to declare the return
> +value of <code>foo</code> as <code>void</code>.
> +
> +<h4>Initializing statics with compound literals</h4>
> +
> +<p>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:</p>
> +
> +<pre><code>
> +  struct T { int i; };
> +  struct S { struct T t; };
> +  static struct S s = (struct S) { .t = { 42 } };
> +</code></pre>
> +
> +<p>We used to reject such code in C99/C11 mode:</p>
> +
> +<pre>
> +<b>q.c:3:29:</b> <b style='color:red'>error:</b> initializer element is not constant
> +   static struct S s = (struct S) { .t = { 42 } };
> +                               <b style='color:lime'>^</b>
> +</pre>
> +
> +<p>Note that using <code>-Wpedantic</code> will cause a warning be emitted:</p>
> +
> +<pre>
> +<b>q.c:3:29:</b> <b style='color:magenta'>warning:</b> initializer element is not constant [-Wpedantic]
> +   static struct S s = (struct S) { .t = { 42 } };
> +                       <b style='color:lime'>^</b>
> +</pre>
> +
> +</body>
> +</html>
> 
> 	Marek

	Marek