* [wwwdocs] gcc-4.8/porting_to.html
@ 2013-03-13 9:29 Benjamin De Kosnik
2013-03-13 10:01 ` Tobias Burnus
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Benjamin De Kosnik @ 2013-03-13 9:29 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 20130313-1.patch --]
[-- Type: text/x-patch, Size: 7114 bytes --]
2013-03-13 Benjamin Kosnik <bkoz@redhat.com>
* 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 ----
+ <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>. Note
+ that <code>-Wall</code> subsumes this warning flag.
+ </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 flags <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 <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;
+ }
+ </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, use memcopy
+ ^
+ </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 use memcopy 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, <stdc-predef.h> 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 flags <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>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 9:29 [wwwdocs] gcc-4.8/porting_to.html Benjamin De Kosnik
@ 2013-03-13 10:01 ` Tobias Burnus
2013-03-14 0:28 ` Benjamin De Kosnik
2013-03-13 10:27 ` Mikael Pettersson
2015-04-12 11:02 ` Gerald Pfeifer
2 siblings, 1 reply; 11+ messages in thread
From: Tobias Burnus @ 2013-03-13 10:01 UTC (permalink / raw)
To: Benjamin De Kosnik; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 9:29 [wwwdocs] gcc-4.8/porting_to.html Benjamin De Kosnik
2013-03-13 10:01 ` Tobias Burnus
@ 2013-03-13 10:27 ` Mikael Pettersson
2013-03-13 10:37 ` Alexander Monakov
2015-04-12 11:02 ` Gerald Pfeifer
2 siblings, 1 reply; 11+ messages in thread
From: Mikael Pettersson @ 2013-03-13 10:27 UTC (permalink / raw)
To: Benjamin De Kosnik; +Cc: gcc-patches
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
> + <p>To fix, either use memcopy or dereference the last argument in the
likewise
/Mikael
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 10:27 ` Mikael Pettersson
@ 2013-03-13 10:37 ` Alexander Monakov
2013-03-13 10:51 ` Mikael Pettersson
2013-03-14 0:26 ` Benjamin De Kosnik
0 siblings, 2 replies; 11+ messages in thread
From: Alexander Monakov @ 2013-03-13 10:37 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: Benjamin De Kosnik, gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 10:37 ` Alexander Monakov
@ 2013-03-13 10:51 ` Mikael Pettersson
2013-03-14 0:26 ` Benjamin De Kosnik
1 sibling, 0 replies; 11+ messages in thread
From: Mikael Pettersson @ 2013-03-13 10:51 UTC (permalink / raw)
To: Alexander Monakov; +Cc: Mikael Pettersson, Benjamin De Kosnik, gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 10:37 ` Alexander Monakov
2013-03-13 10:51 ` Mikael Pettersson
@ 2013-03-14 0:26 ` Benjamin De Kosnik
1 sibling, 0 replies; 11+ messages in thread
From: Benjamin De Kosnik @ 2013-03-14 0:26 UTC (permalink / raw)
To: Alexander Monakov; +Cc: Mikael Pettersson, gcc-patches
> It doesn't make sense. memcpy from NULL src pointer?
Indeed, that doesn't make sense. Thanks.
-benjamin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 10:01 ` Tobias Burnus
@ 2013-03-14 0:28 ` Benjamin De Kosnik
2013-03-14 1:23 ` Benjamin De Kosnik
2013-03-14 11:10 ` Alexander Monakov
0 siblings, 2 replies; 11+ messages in thread
From: Benjamin De Kosnik @ 2013-03-14 0:28 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 47 bytes --]
Here is round two, as checked-in.
-benjamin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 20130313-3.wwdocs.patch --]
[-- Type: text/x-patch, Size: 7812 bytes --]
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 <string.h>
+
+ 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, <stdc-predef.h> 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>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-14 0:28 ` Benjamin De Kosnik
@ 2013-03-14 1:23 ` Benjamin De Kosnik
2013-03-14 11:10 ` Alexander Monakov
1 sibling, 0 replies; 11+ messages in thread
From: Benjamin De Kosnik @ 2013-03-14 1:23 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 89 bytes --]
> Here is round two, as checked-in.
... and here are the validation patches.
-benjamin
[-- Attachment #2: 20130313-4.www.patch --]
[-- Type: text/x-patch, Size: 3084 bytes --]
2013-03-13 Benjamin Kosnik <bkoz@redhat.com>
* 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.</p>
*** 59,65 ****
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>
--- 59,65 ----
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>
Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/porting_to.html,v
retrieving revision 1.1
diff -c -p -r1.1 porting_to.html
*** porting_to.html 14 Mar 2013 00:25:06 -0000 1.1
--- porting_to.html 14 Mar 2013 01:09:43 -0000
*************** unsigned int foo()
*** 60,66 ****
{
unsigned int data_data[128];
! for (int fd = 0; fd < 128; ++fd)
data_data[fd] = fd * (0x02000001); // error
return data_data[0];
--- 60,66 ----
{
unsigned int data_data[128];
! for (int fd = 0; fd < 128; ++fd)
data_data[fd] = fd * (0x02000001); // error
return data_data[0];
*************** struct A { };
*** 101,107 ****
int main(void)
{
A obj;
! A* p1 = &obj;
A p2[10];
memset(p1, 0, sizeof(p1)); // error
--- 101,107 ----
int main(void)
{
A obj;
! A* p1 = &obj;
A p2[10];
memset(p1, 0, sizeof(p1)); // error
*************** offending memset call.</p>
*** 129,134 ****
--- 129,135 ----
<p>As a workaround, use
<code>-Wno-sizeof-pointer-memaccess</code>.
+ </p>
<h3>Pre-processor pre-includes</h3>
*************** pre-processor may now fail, with the fol
*** 155,161 ****
<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>
--- 156,162 ----
<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>.
! </p>
<h2>C++ language issues</h2>
*************** versions of GCC.
*** 170,176 ****
<p>For example,</p>
<pre>
! template<typename _Tp>
int
foo(_Tp __a)
{
--- 171,177 ----
<p>For example,</p>
<pre>
! template<typename _Tp>
int
foo(_Tp __a)
{
*************** new errors.</p>
*** 197,202 ****
--- 198,204 ----
<p>As a workaround, use
<code>-Wno-unused-local-typedefs</code>.
+ </p>
<h3>Stray comma at the end of declaration now rejected</h3>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 20130313-5.www.patch --]
[-- Type: text/x-patch, Size: 938 bytes --]
2013-03-13 Benjamin Kosnik <bkoz@redhat.com>
* htdocs/gcc-4.8/porting_to.html: Fix markup.
Index: porting_to.html
===================================================================
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 ‘,’ at end of member de
*** 227,233 ****
<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>
--- 227,233 ----
<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</a>
</body>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-14 0:28 ` Benjamin De Kosnik
2013-03-14 1:23 ` Benjamin De Kosnik
@ 2013-03-14 11:10 ` Alexander Monakov
2013-03-14 11:21 ` Jakub Jelinek
1 sibling, 1 reply; 11+ messages in thread
From: Alexander Monakov @ 2013-03-14 11:10 UTC (permalink / raw)
To: Benjamin De Kosnik; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-14 11:10 ` Alexander Monakov
@ 2013-03-14 11:21 ` Jakub Jelinek
0 siblings, 0 replies; 11+ messages in thread
From: Jakub Jelinek @ 2013-03-14 11:21 UTC (permalink / raw)
To: Alexander Monakov; +Cc: Benjamin De Kosnik, gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [wwwdocs] gcc-4.8/porting_to.html
2013-03-13 9:29 [wwwdocs] gcc-4.8/porting_to.html Benjamin De Kosnik
2013-03-13 10:01 ` Tobias Burnus
2013-03-13 10:27 ` Mikael Pettersson
@ 2015-04-12 11:02 ` Gerald Pfeifer
2 siblings, 0 replies; 11+ messages in thread
From: Gerald Pfeifer @ 2015-04-12 11:02 UTC (permalink / raw)
To: Benjamin De Kosnik, gcc-patches
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 @@
<a href="https://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
+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>
@@ -31,9 +31,8 @@
<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>.
+such, new warnings may exist for previously warning-free code when
+using <code>-Wmaybe-uninitialized</code>.
</p>
<p> Although these warnings will
@@ -49,8 +48,8 @@
<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.
+the ability of the optimizers to transform loops. Some loops that
+invoke undefined behavior may now be turned into endless loops.
</p>
<p>For example,</p>
@@ -68,7 +67,8 @@
</pre>
<p>
-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++.
</p>
<p>
@@ -119,13 +119,13 @@
^
</pre>
-<p>Although these warnings will not result in compilation failure,
-often <code>-Wall</code> is used in conjunction with
+<p>Although these warnings will not result in compilation failure per
+se, 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>To fix, either re-write to use <code>memcpy</code> or dereference the
+last argument in the offending <code>memset</code> call.</p>
<p>As a workaround, use
<code>-Wno-sizeof-pointer-memaccess</code>.
@@ -134,7 +134,7 @@
<h3>Pre-processor pre-includes</h3>
<p>
-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 @@
</p>
<p>
-On linux, <stdc-predef.h> is pre-included.
+On GNU/Linux, <stdc-predef.h> is pre-included.
</p>
<p>
@@ -154,8 +154,9 @@
/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>.
+<p>As a workaround, the stdc-predef.h pre-include can be disabled with
+the use of <code>-ffreestanding</code>. For non C/C++ code, use the
+pre-processor flag <code>-P</code>.
</p>
<h2>C++ language issues</h2>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-04-12 11:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-13 9:29 [wwwdocs] gcc-4.8/porting_to.html Benjamin De Kosnik
2013-03-13 10:01 ` Tobias Burnus
2013-03-14 0:28 ` Benjamin De Kosnik
2013-03-14 1:23 ` Benjamin De Kosnik
2013-03-14 11:10 ` Alexander Monakov
2013-03-14 11:21 ` Jakub Jelinek
2013-03-13 10:27 ` Mikael Pettersson
2013-03-13 10:37 ` Alexander Monakov
2013-03-13 10:51 ` Mikael Pettersson
2013-03-14 0:26 ` Benjamin De Kosnik
2015-04-12 11:02 ` Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).