From: Gerald Pfeifer <gerald@pfeifer.com>
To: Benjamin De Kosnik <bkoz@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [wwwdocs] gcc-4.8/porting_to.html
Date: Sun, 12 Apr 2015 11:02:00 -0000 [thread overview]
Message-ID: <alpine.LSU.2.20.1504120214390.9357@tuna.site> (raw)
In-Reply-To: <20130313022916.0728c82e@oakwood>
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>
prev parent reply other threads:[~2015-04-12 11:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 9:29 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.1504120214390.9357@tuna.site \
--to=gerald@pfeifer.com \
--cc=bkoz@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).