Patchwork [wwwdocs] gcc-4.8/porting_to.html

login
register
mail settings
Submitter Benjamin Kosnik
Date March 14, 2013, 12:28 a.m.
Message ID <20130313172850.49f4b3d7@oakwood>
Download mbox | patch
Permalink /patch/227415/
State New
Headers show

Comments

Benjamin Kosnik - March 14, 2013, 12:28 a.m.
Here is round two, as checked-in.

-benjamin
Alexander Monakov - March 14, 2013, 11:07 a.m.
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
Jakub Jelinek - March 14, 2013, 11:21 a.m.
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

Patch

2013-03-13  Benjamin Kosnik  <bkoz@redhat.com>

        * htdocs/gcc-4.8/porting_to.html: Add.
        * htdocs/gcc-4.8/changes.html: Add link.

Index: changes.html
===================================================================
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.</p>
*** 54,59 ****
--- 54,66 ----
    <code>--with-avrlibc=no</code>.  If the compiler is configured for
    RTEMS, the option is always turned off.</p>
  
+ <p>
+   More information on porting to GCC 4.8 from previous versions
+   of GCC can be found in
+   the <a href="http://gcc.gnu.org/gcc-4.8/porting_to.html">porting
+   guide</a> for this release.
+ <p>
+ 
  <h2>General Optimizer Improvements (and Changes)</h2>
  
    <ul>
Index: porting_to.html
===================================================================
RCS file: porting_to.html
diff -N porting_to.html
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- porting_to.html	14 Mar 2013 00:20:47 -0000
***************
*** 0 ****
--- 1,232 ----
+ <html>
+ 
+ <head>
+ <title>Porting to GCC 4.8</title>
+ </head>
+ 
+ <body>
+ <h1>Porting to GCC 4.8</h1>
+ 
+ <p>
+ The GCC 4.8 release series differs from previous GCC releases in more
+ than the usual list of
+ <a href="http://gcc.gnu.org/gcc-4.8/changes.html">changes</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 runtime
+ 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 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.
+ </p>
+ 
+ <h2>General issues</h2>
+ 
+ <h3>New warnings</h3>
+ 
+ <p>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
+ <code>-Wmaybe-uninitialized</code>.
+ </p>
+ 
+ <p> Although these warnings will
+ not result in compilation failure, often <code>-Wall</code> is used in
+ conjunction with <code>-Werror</code> and as a result, new warnings
+ are turned into new errors.
+ </p>
+ 
+ <p>As a workaround, remove <code>-Werror</code> until the new warnings
+ are fixed, or add <code>-Wno-maybe-uninitialized</code>.
+ </p>
+ 
+ <h3>More aggressive loop optimizations</h3>
+ 
+ <p>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.
+ </p>
+ 
+ <p>For example,</p>
+ 
+ <pre>
+ 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];
+ }
+ </pre>
+ 
+ <p>
+ When fd is 64 or above, fd * 0x02000001 overflows, which is invalid in C/C++ for signed ints.  
+ </p>
+ 
+ <p>
+ To fix, use the appropriate casts when converting between signed and
+ unsigned types to avoid overflows. Like so:
+ </p>
+ 
+ <pre>
+     data_data[fd] = (uint32_t) fd * (0x02000001U); // ok
+ </pre>
+ 
+ <h2>C language issues</h2>
+ 
+ <h3>New warnings for pointer access</h3>
+ 
+ <p>
+ The behavior of <code>-Wall</code> has changed and now includes the
+ new warning flag <code>-Wsizeof-pointer-memaccess</code>. This may
+ result in new warnings in code that compiled cleanly with previous
+ versions of GCC.
+ </p>
+ 
+ <p>For example,</p>
+ 
+ <pre>
+ #include &lt;string.h&gt;
+ 
+ struct A { };
+ 
+ int main(void) 
+ {
+   A obj;
+   A* p1 = &obj;
+   A p2[10];
+ 
+   memset(p1, 0, sizeof(p1)); // error
+   memset(p1, 0, sizeof(*p1)); // ok, dereferenced
+   memset(p2, 0, sizeof(p2)); // ok, array
+ 
+   return 0;
+ }
+ </pre>
+ 
+ <p>Gives the following diagnostic:</p>
+ <pre>
+ 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
+                        ^
+ </pre>
+ 
+ <p>Although these warnings will not result in compilation failure,
+ often <code>-Wall</code> is used in conjunction with
+ <code>-Werror</code> and as a result, new warnings are turned into
+ new errors.</p>
+  
+ <p>To fix, either re-write to use memcpy or dereference the last argument in the
+ offending memset call.</p>
+  
+ <p>As a workaround, use
+ <code>-Wno-sizeof-pointer-memaccess</code>.
+ 
+ <h3>Pre-processor pre-includes</h3>
+ 
+ <p>
+ 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.
+ </p>
+ 
+ <p>
+ On linux, &lt;stdc-predef.h&gt; is pre-included.
+ </p>
+ 
+ <p>
+ This subtle change means that some more creative uses of the
+ pre-processor may now fail, with the following diagnostic:
+ </p>
+ 
+ <pre>
+ /usr/include/stdc-predef.h:0: error: Syntax error near '3' 
+ </pre>
+ 
+ <p>As a workaround, the stdc-predef.h preinclude can be disabled with
+ the use of <code>-ffreestanding</code>. For non C/C++ code, use the pre-processor flag <code>-P</code>. 
+ 
+ 
+ <h2>C++ language issues</h2>
+ 
+ <h3>New warnings for unused local typedefs</h3>
+ 
+ <p>
+ The behavior of <code>-Wall</code> has changed and now includes the
+ new warning flag <code>-Wunused-local-typedefs</code>. This may
+ result in new warnings in code that compiled cleanly with previous
+ versions of GCC.
+ </p>
+ 
+ <p>For example,</p>
+ <pre>
+ template<typename _Tp>
+   int
+   foo(_Tp __a)
+   {
+     typedef int return_type;
+     return 5;
+   }
+ 
+ int i = foo(415);
+ </pre>
+ 
+ <p>Gives the following diagnostic:</p>
+ <pre>
+ warning: typedef ‘return_type’ locally defined but not used [-Wunused-local-typedefs]
+      typedef int return_type;
+                  ^
+ </pre>
+ 
+ <p>Although these warnings will not result in compilation failure,
+ often <code>-Wall</code> is used in conjunction with
+ <code>-Werror</code> and as a result, new warnings are turned into
+ new errors.</p>
+  
+ <p>To fix, simply remove the unused typedef.</p>
+  
+ <p>As a workaround, use
+ <code>-Wno-unused-local-typedefs</code>.
+ 
+ <h3>Stray comma at the end of declaration now rejected</h3>
+ 
+ <p>
+ GCC by default no longer accepts code such as
+ </p>
+ 
+ <pre>
+ struct A { struct B *C,; };
+ </pre>
+ 
+ <p>This example now gives the following diagnostic:</p>
+ <pre>
+ error: stray ‘,’ at end of member declaration
+  struct A { struct B *C,; };
+                        ^
+ </pre>
+ 
+ <p>To fix, simply remove the unused comma.</p>
+ 
+ <!--
+ <h3>Java issues</h3>
+ -->
+ 
+ <h3>Links</h3>
+ 
+ <p>
+ Jakub Jelinek,
+  <a href="https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html">Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19</p>
+ 
+ 
+ </body>
+ </html>