Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
On Thu, 22 Mar 2012, Rainer Orth wrote: Indeed: neither the original nor my patch were right here. I've updated my patch to include the correct syntax. Ok now? Oh, yes. You just could have gone ahead. :-) Gerald
Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
On Thu, 22 Mar 2012, Rainer Orth wrote: 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/PRn here? Good idea, yes. Changed thusly. Gerald Index: gcc-4.7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.102 diff -u -3 -p -r1.102 changes.html --- gcc-4.7/changes.html22 Mar 2012 09:40:43 - 1.102 +++ gcc-4.7/changes.html24 Mar 2012 21:47:03 - @@ -469,14 +469,12 @@ well./p/li some efforts have been made to improve the support of class scope using-declarations. In particular, using-declarations referring to a dependent type now work as expected - (a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258;bug - c++/14258/a). + (a href=http://gcc.gnu.org/PR14258;bug c++/14258/a). /li liThe ELF symbol visibility of a template instantiation is now properly constrained by the visibility of its template arguments -(a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688;bug -c++/35688/a)./li +(a href=http://gcc.gnu.org/PR35688;bug c++/35688/a)./li /ul
Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
Gerald Pfeifer ger...@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.
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 think you're right: it correctly emphasizes the avoidance.
I am not sure about The powerpc vs The PowerPC vs powerpc,
please pass that part by David Edelsohn.
Already dealt with, thanks David.
Similarly, are you sure code#pragma GCC target attribute/code
change is incorrect. Isn't that a function attribute?
Indeed: neither the original nor my patch were right here. I've updated
my patch to include the correct syntax.
Ok now?
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.102
diff -u -p -r1.102 changes.html
--- changes.html 22 Mar 2012 09:40:43 - 1.102
+++ changes.html 22 Mar 2012 16:40:14 -
@@ -126,7 +126,7 @@
pre
void foo(int a)
{
- if (agt;10)
+ if (a gt; 10)
... huge code ...
}
void bar (void)
@@ -166,7 +166,7 @@ void bar (void)
GCC will now produce two copies of codefoo/code. One with codeflag/code being
codetrue/code, while other with codeflag/code being
codefalse/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 codelibitm/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
- liWhen 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
+ liWhen 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,8 @@ well./p/li
/li
liAdded code--enable-clocale=newlib/code configure option. /li
liDebug Mode iterators for unordered associative containers. /li
- liAvoid polluting the global namespace by inclusion of codelt;unistd.hgt;/code. /li
+ liAvoid polluting the global namespace and do not include
+ codelt;unistd.hgt;/code./li
/ul
@@ -509,7 +511,7 @@ well./p/li
liThe compile flag a
Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
Gerald Pfeifer ger...@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/PRn here? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[wwwdocs] Fix some nits in GCC 4.7 changes.html
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
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 - 1.96
+++ changes.html 16 Mar 2012 14:47:44 -
@@ -126,7 +126,7 @@
pre
void foo(int a)
{
- if (agt;10)
+ if (a gt; 10)
... huge code ...
}
void bar (void)
@@ -166,7 +166,7 @@ void bar (void)
GCC will now produce two copies of codefoo/code. One with codeflag/code being
codetrue/code, while other with codeflag/code being
codefalse/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 codelibitm/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
- liWhen 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
+ liWhen 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
liAdded code--enable-clocale=newlib/code configure option. /li
liDebug Mode iterators for unordered associative containers. /li
- liAvoid polluting the global namespace by inclusion of codelt;unistd.hgt;/code. /li
+ liDon't include codelt;unistd.hgt;/code to avoid polluting the global namespace./li
/ul
@@ -509,7 +510,7 @@ well./p/li
liThe 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
Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
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
