Patchwork [wwwdocs] Fix some nits in GCC 4.7 changes.html

login
register
mail settings
Submitter Rainer Orth
Date March 16, 2012, 2:57 p.m.
Message ID <yddbonwpp9l.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
Download mbox | patch
Permalink /patch/147211/
State New
Headers show

Comments

Rainer Orth - March 16, 2012, 2:57 p.m.
While reading through the GCC 4.7 changes.html, I noticed a couple of
nits that this patch fixes.  It's mostly wording and grammar changes (so
I may well be wrong and would appreciate a native speaker having a look ;-)

Ok to install?

Beyond what I've changed, two items could perhaps do with better
explanations, especially since the document is intended to be directed
at compiler users, not compiler developers:

* LTO improvements:

  Streaming performance (both outbound and inbound) has been improved.

  What is this and why should I care?

* IA-32/x86-64:

  Support for new Intel processor codename IvyBridge with RDRND,
  FSGSBASE and F16C

  Support for the new Intel processor codename Haswell with AVX2, FMA,
  BMI, BMI2, LZCNT
  
  Better: with the ... extensions?  Add links?

	Rainer
Gerald Pfeifer - March 16, 2012, 5:42 p.m.
On Fri, 16 Mar 2012, Rainer Orth wrote:
> While reading through the GCC 4.7 changes.html, I noticed a couple of 
> nits that this patch fixes.  It's mostly wording and grammar changes (so 
> I may well be wrong and would appreciate a native speaker having a look 

This looks good in general, thanks.

Instead of the change around pollution I would prefer 
  "Avoid polluting the global namespace and do not include..."
instead of either the old or the proposed version, though I'll admit
I do not have a strong rationale.

I am not sure about "The powerpc" vs "The PowerPC" vs "powerpc",
please pass that part by David Edelsohn.

Similarly, are you sure "<code>#pragma GCC target attribute</code>"
change is incorrect.  Isn't that a function attribute?

Gerald
Rainer Orth - March 22, 2012, 4:50 p.m.
Gerald Pfeifer <gerald@pfeifer.com> writes:

> On Fri, 16 Mar 2012, Rainer Orth wrote:
>> While reading through the GCC 4.7 changes.html, I noticed a couple of 
>> nits that this patch fixes.  It's mostly wording and grammar changes (so 
>> I may well be wrong and would appreciate a native speaker having a look 
>
> This looks good in general, thanks.

One issue I forgot: there are currently two instances of the long form
of the bugzilla URLs.  Shouldn't we better use http://gcc.gnu.org/PR<n>
here?

	Rainer

Patch

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.96
diff -u -p -r1.96 changes.html
--- changes.html	7 Mar 2012 14:15:35 -0000	1.96
+++ changes.html	16 Mar 2012 14:47:44 -0000
@@ -126,7 +126,7 @@ 
       <pre>
 void foo(int a)
 {
-  if (a&gt;10)
+  if (a &gt; 10)
     ... huge code ...
 }
 void bar (void)
@@ -166,7 +166,7 @@  void bar (void)
       GCC will now produce two copies of <code>foo</code>. One with <code>flag</code> being
       <code>true</code>, while other with <code>flag</code> being
       <code>false</code>.  This leads to performance improvements previously
-      possibly only by inlining all calls.  Cloning causes a lot less code size
+      possible only by inlining all calls.  Cloning causes a lot less code size
       growth.</li>
     </ul></li>
 
@@ -242,20 +242,21 @@  void foo (char *a, const char *b, const 
   <li>
     <p>
       Experimental support for transactional memory has been added.
-      It includes support for the compiler, as well as a supporting
+      It includes support in the compiler, as well as a supporting
       runtime library called <code>libitm</code>.  To compile code
       with transactional memory constructs, use
       the <code>-fgnu-tm</code> option.
     </p>
 
     <p>
-      Support is currently available for the x86-32, x86-64, and Alpha
-      platforms.
+      Support is currently available for Alpha, ARM, PowerPC, SH, SPARC,
+      and 32-bit/64-bit x86 platforms.
     </p>
 
     <p>
       For more details on transactional memory
-      see <a href="http://gcc.gnu.org/wiki/TransactionalMemory">here</a>.
+      see <a href="http://gcc.gnu.org/wiki/TransactionalMemory">the GCC
+      WiKi</a>.
     </p>
   </li>
 
@@ -266,11 +267,11 @@  void foo (char *a, const char *b, const 
       existing <code>__sync</code> built-in routines.
     </p>
     <p>
-      Atomic support is also available for memory blocks.  Lock free
+      Atomic support is also available for memory blocks.  Lock-free
       instructions will be used if a memory block is the same size and 
       alignment as a supported integer type.  Atomic operations which do not
-      have lock free support are left as function calls.  A set of library 
-      functions are available on the GCC atomic wiki in the "External 
+      have lock-free support are left as function calls.  A set of library 
+      functions is available on the GCC atomic wiki in the "External 
       Atomics Library" section.
     </p>
     <p>
@@ -279,8 +280,8 @@  void foo (char *a, const char *b, const 
     </p>
   </li>
 
-  <li>When a binary operation performed on vector types and one of the operands
-      is a uniform vector it is possible to replace the vector with the
+  <li>When a binary operation is performed on vector types and one of the operands
+      is a uniform vector, it is possible to replace the vector with the
       generating element. For example:
       <pre>
 typedef int v4si __attribute__ ((vector_size (16)));
@@ -352,7 +353,7 @@  struct B {
 };
 
 struct D : B {
-  void f() const;    // error: D::f attempts to override final B::f
+  void f() const;            // error: D::f attempts to override final B::f
   void f(long) override;     // error: doesn't override anything
   void f(int) override;      // ok
 };
@@ -499,7 +500,7 @@  well.</p></li>
      </li>
      <li>Added <code>--enable-clocale=newlib</code> configure option. </li>
      <li>Debug Mode iterators for unordered associative containers. </li>
-     <li>Avoid polluting the global namespace by inclusion of <code>&lt;unistd.h&gt;</code>.  </li>
+     <li>Don't include <code>&lt;unistd.h&gt;</code> to avoid polluting the global namespace.</li>
 
 
   </ul>
@@ -509,7 +510,7 @@  well.</p></li>
     <li>The compile flag <a
       href="http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack_002darrays_007d-254"
       ><code>-fstack-arrays</code></a> has been added, which causes
-      that all local arrays are put on stack memory. For some
+      all local arrays to be put on stack memory. For some
       programs this will improve the performance significantly. If your
       program uses very large local arrays, it is possible that you will
       have to extend your runtime limits for stack memory.</li>
@@ -539,7 +540,7 @@  well.</p></li>
       >-Wreal-q-constant</a></code> has been added, which
       warns if floating-point literals have been specified using
       <code>q</code> (such as <code>1.0q0</code>); the <code>q</code>
-      marker is now supported a vendor extension to denote quad precision
+      marker is now supported as a vendor extension to denote quad precision
       (<code>REAL(16)</code> or, if not available, <code>REAL(10)</code>).
       Consider using a kind parameter (such as in <code>1.0_qp</code>)
       instead, which can be obtained via <a
@@ -554,9 +555,9 @@  well.</p></li>
       <code>GFORTRAN_ERROR_DUMPCORE</code> environment variable have
       been removed. When encountering a serious error, gfortran will
       now always abort the program. Whether a core dump is generated
-      depends on the user environment settings; see for POSIX shells
-      the <code>ulimit -c</code> and for C shells the <code>limit
-      coredumpsize</code> setting, and see the <a
+      depends on the user environment settings; see the <code>ulimit -c</code>
+      setting for POSIX shells, <code>limit coredumpsize</code> for C shells,
+      and the <a
       href="http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx"
       >WER user-mode dumps settings</a> on Windows.</li>
     <li>The <a
@@ -631,7 +632,7 @@  well.</p></li>
 
 <h3 id="avr">AVR</h3>
   <ul>
-    <li>GCC now supports XMEGA architecture.
+    <li>GCC now supports the XMEGA architecture.
       This requires GNU binutils 2.22 or later.</li>
     <li>Support for the
       <a href="http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html">named address spaces</a>
@@ -706,21 +707,20 @@  int add_values (const __flash int *p, in
       <code>-mfma</code>.</li>
     <li>A new <code>-mfsgsbase</code> command-line option is available that makes GCC
     generate new segment register read/write instructions through dedicated built-ins.</li>
-    <li>Support for new Intel <code>rdrnd</code> instruction is available via <code>-mrdrnd</code>.</li>
+    <li>Support for the new Intel <code>rdrnd</code> instruction is available via <code>-mrdrnd</code>.</li>
     <li>Two additional AVX vector conversion instructions are available via <code>-mf16c</code>.</li>
     <li>Support for new Intel processor codename IvyBridge with RDRND, FSGSBASE and F16C
       is available through <code>-march=core-avx-i</code>.</li>
     <li>Support for the new Intel processor codename Haswell with AVX2, FMA, BMI,
       BMI2, LZCNT is available through <code>-march=core-avx2</code>.</li>
-    <li>Windows mingw targets are using <code>-mms-bitfields</code> option
-      as default.</li>
+    <li>Support for new AMD family 15h processors (Piledriver core) is now available
+      through <code>-march=bdver2</code> and <code>-mtune=bdver2</code> options.</li>
+    <li>Windows mingw targets are using the <code>-mms-bitfields</code> option
+      by default.</li>
     <li>Windows x86 targets are using the <code>__thiscall</code> calling
       convention for C++ class-member functions.</li>
     <li>Support for the configure option <code>--with-threads=posix</code>
       for Windows mingw targets.</li>
-    <li>Support for new AMD family 15h processors (Piledriver core) is now available
-      through <code>-march=bdver2</code> and <code>-mtune=bdver2</code> options.</li>
-    <li>...</li>
   </ul>
 
 <h3 id="mips">MIPS</h3>
@@ -754,28 +754,28 @@  int add_values (const __flash int *p, in
 <h3>PowerPC/PowerPC64</h3>
   <ul>
     <li>Vectors of type <i>vector long long</i> or <i>vector long</i> are
-	passed and returned in the same method as other vectors with the VSX
+	passed and returned using the same method as other vectors with the VSX
 	instruction set.  Previously the GCC compiler did not adhere to the ABI
 	for 128-bit vectors with 64-bit integer base types (PR 48857).
 	This will also be fixed in the GCC 4.6.1 and 4.5.4 releases.</li>
 
-     <li>A new option (<code>-mno-pointers-to-nested-functions)</code> was
+     <li>A new option <code>-mno-pointers-to-nested-functions</code> was
 	added to allow AIX 32-bit/64-bit and GNU/Linux 64-bit PowerPC users to
 	specify that the compiler should not load up the chain register
 	(<code>r11</code>) before calling a function through a pointer.
 	If you use this option, you cannot call nested functions through a
 	pointer, or call other languages that might use the static chain.</li>
 
-     <li>A new option (<code>msave-toc-indirect</code> was added to allow AIX
+     <li>A new option <code>msave-toc-indirect</code> was added to allow AIX
 	32-bit/64-bit and GNU/Linux 64-bit PowerPC users control whether we
 	save the TOC in the prologue for indirect calls or generate the save
 	inline.  This can speed up some programs that call through a function
 	pointer a lot, but it can slow down other functions that only call
 	through a function pointer in exceptional cases.</li>
 
-      <li>The powerpc will now enable machine specific builtin functions when
+      <li>The PowerPC will now enable machine-specific builtin functions when
 	the user switches the target machine using the
-	<code>#pragma GCC target</code> or <code>GCC target attribute</code>
+	<code>#pragma GCC target</code> or <code>#pragma GCC target attribute</code>
 	code sequences.  In additon, the target macros are updated.
 	However, due to the way the <code>-save-temps</code> switch is
 	implemented, you won't see the effect of these additional macros
@@ -785,7 +785,7 @@  int add_values (const __flash int *p, in
 <h3>SH</h3>
   <ul>
     <li>A new option <code>-msoft-atomic</code> has been added.  When it is
-        specified, GCC will generate GNU/Linux compatible gUSA atomic sequences
+        specified, GCC will generate GNU/Linux-compatible gUSA atomic sequences
 	for the new <code>__atomic</code> routines.</li>
     <li>Since it is neither supported by GAS nor officially documented, code
         generation for little endian SH2A has been disabled.  Specifying
@@ -809,26 +809,26 @@  int add_values (const __flash int *p, in
     <li>Support for the options <code>-mtune=native</code> and
         <code>-mcpu=native</code> has been added on selected native platforms
         (GNU/Linux and Solaris).</li>
-    <li>Support for the Sun UltraSPARC T3 (Niagara 3) processor has been
-        added.</li>
+    <li>Support for the SPARC T3 (Niagara 3) processor has been added.</li>
     <li>VIS:
       <ul>
         <li>An intrinsics header <code>visintrin.h</code> has been added.</li>
         <li>Builtin intrinsics for the VIS 1.0 edge handling and pixel compare
-            instructions has been added.</li>
+            instructions have been added.</li>
         <li>The little-endian version of <code>alignaddr</code> is now
             supported.</li>
-        <li>When possible, VIS builtins are marked <code>const</code> which
-            should increase the compilers ability to optimize VIS
+        <li>When possible, VIS builtins are marked <code>const</code>, which
+            should increase the compiler's ability to optimize VIS
             operations.</li>
-        <li>The compiler now properly tracks the <code>%gsr</code> register,
+        <li>The compiler now properly tracks the <code>%gsr</code> register
             and how it behaves as an input for various VIS instructions.</li>
         <li>Akin to <code>fzero</code>, the compiler can now generate
             <code>fone</code> instructions in order to set all of the bits
-            of a floating-point register to one.</li>
+            of a floating-point register to <code>1</code>.</li>
         <li>The documentation for the VIS intrinsics in the GCC manual has
             been brought up to date and many inaccuracies were fixed.</li>
-        <li>Intrinsics for the VIS 2.0 bmask, bshuffle, and non-condition-code
+        <li>Intrinsics for the VIS 2.0 <code>bmask</code>,
+	    <code>bshuffle</code>, and non-condition-code 
 	    setting edge instructions have been added.  Their availability
 	    is controlled by the new <code>-mvis2</code> and
 	    <code>-mno-vis2</code> options.  They are enabled by default
@@ -837,7 +837,7 @@  int add_values (const __flash int *p, in
     </li>
     <li>Support for UltraSPARC Fused Multiply-Add floating-point
         extensions has been added.  These instructions are enabled by
-        default on UltraSPARC T3 (Niagara 3) and later CPUs.</li>
+        default on SPARC T3 (Niagara 3) and later CPUs.</li>
   </ul>
 
 <h3>TILE-Gx/TILEPro</h3>
@@ -873,7 +873,7 @@  int add_values (const __flash int *p, in
     or <a
     href="http://www.dwarfstd.org/ShowIssue.php?issue=110722.1">a
     more compact macro representation</a>.  Support for these extensions
-    will come in GDB 7.4. They can be disabled through the
+    has been added to GDB 7.4. They can be disabled through the
     <code>-gstrict-dwarf</code> command-line option.
   </li>
 </ul>