Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Tue, 3 May 2011, Gerald Pfeifer wrote:
On Wed, 27 Apr 2011, Michael Witten wrote:
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
I think we *should* make such formatting cleanups (not just trailing
whitespace removal, but other changes to match formatting conventions,
including fixing leading whitespace in C code to use tabs where it doesn't
as well as more visible changes) - as long as we are agreed on what the
convention is to follow (see
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00393.html and thread
regarding conventions for whitespace after VEC etc., for example). (But
not (a) in testcases, where I don't think there's any need to follow
consistent conventions, and (b) in code imported from other upstream
sources, where such fixes are not a good enough reason to diverge from
upstream.)
However, given the reaction when HJ checked in a trailing whitespace
removal patch, it seems this is controversial.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On May 4, 2011, at 3:08 AM, Joseph S. Myers wrote:
On Tue, 3 May 2011, Gerald Pfeifer wrote:
On Wed, 27 Apr 2011, Michael Witten wrote:
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
I think we *should* make such formatting cleanups (not just trailing
whitespace removal, but other changes to match formatting conventions,
including fixing leading whitespace in C code to use tabs where it doesn't
as well as more visible changes)
gcc had that policy for years and years. To return to that, we just need a
maintainer to approve or pre-approve these changes. :-) Then, buy some
popcorn and watch the fight (if any).
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Wed, 4 May 2011, Joseph S. Myers wrote: I believe we usually don't do whitespace changes just for the sake of cleaning up things. Unless someone else indicates otherwise, I believe this patch is rejected. I think we *should* make such formatting cleanups (not just trailing whitespace removal, but other changes to match formatting conventions, including fixing leading whitespace in C code to use tabs where it doesn't as well as more visible changes) - as long as we are agreed on what the convention is to follow Joseph, if you'd like to approave Michael's patch, I explicitly non-object. On Wed, 4 May 2011, Mike Stump wrote: gcc had that policy for years and years. To return to that, we just need a maintainer to approve or pre-approve these changes. :-) Documentation may be a bit more relaxed, and if you have one doc maintainer approve and the other abstain that may be more boring that you might hope for. :-) Unless others strongly disagree, of course, still got respective area maintainers and global reviewers. Gerald
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Wed, 4 May 2011, Gerald Pfeifer wrote: On Wed, 4 May 2011, Joseph S. Myers wrote: I believe we usually don't do whitespace changes just for the sake of cleaning up things. Unless someone else indicates otherwise, I believe this patch is rejected. I think we *should* make such formatting cleanups (not just trailing whitespace removal, but other changes to match formatting conventions, including fixing leading whitespace in C code to use tabs where it doesn't as well as more visible changes) - as long as we are agreed on what the convention is to follow Joseph, if you'd like to approave Michael's patch, I explicitly non-object. I explicitly approve trailing whitespace removal from all .texi files and other documentation not imported from upstream sources outside of GCC (subject to handling generated files properly, so any changes to tm.texi should be done by changing source files such as tm.texi.in and then regenerating tm.texi). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On May 4, 2011, at 11:46 AM, Joseph S. Myers wrote: I explicitly approve trailing whitespace removal from all .texi files and other documentation not imported from upstream sources outside of GCC (subject to handling generated files properly, so any changes to tm.texi should be done by changing source files such as tm.texi.in and then regenerating tm.texi). Checked in r173401 and r173402. These sorts of patches usually I don't post, as they tend to hit the size limitation and are exceedingly boring. The important part of it is: $ svn diff -r173400:173402 . -x -b Index: loop.texi === Index: generic.texi === Index: sourcebuild.texi === Index: plugins.texi === Index: cpp.texi === Index: extend.texi === Index: passes.texi === Index: cfg.texi === Index: objc.texi === Index: gimple.texi === Index: tm.texi === Index: libgcc.texi === Index: tree-ssa.texi === Index: tm.texi.in === Index: invoke.texi === Index: gcov.texi === Index: contrib.texi === Index: md.texi === Index: rtl.texi === Index: hostconfig.texi === Index: gty.texi === Index: install.texi === which is one of the audit steps I perform before checkin of these types of patches. One other step, is to hand audit every single character changed. The testsuite has a few lines that cannot be changed, for example. These are the doc bits I care about.
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On May 4, 2011, at 11:40 AM, Gerald Pfeifer wrote: Documentation may be a bit more relaxed, and if you have one doc maintainer approve and the other abstain that may be more boring that you might hope for. :-) Actually, I was aiming for a global person to ack gcc/*... This could be less boring that just gcc/doc. :-)
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Wed, 27 Apr 2011, Michael Witten wrote:
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
Gerald
[PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
---
trunk/gcc/doc/extend.texi | 82 ++--
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index c154958..cdbf69f 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -37,7 +37,7 @@
* Complex:: Data types for complex numbers.
* Floating Types:: Additional Floating Types.
* Half-Precision:: Half-Precision Floating Point.
-* Decimal Float:: Decimal Floating Types.
+* Decimal Float:: Decimal Floating Types.
* Hex Floats:: Hexadecimal floating-point constants.
* Fixed-Point:: Fixed-Point Types.
* Named Address Spaces::Named address spaces.
@@ -455,7 +455,7 @@
safe.
GCC implements taking the address of a nested function using a technique
-called @dfn{trampolines}. This technique was described in
+called @dfn{trampolines}. This technique was described in
@cite{Lexical Closures for C++} (Thomas M. Breuel, USENIX
C++ Conference Proceedings, October 17-21, 1988).
@@ -619,7 +619,7 @@
@}
return open (path, oflag, __builtin_va_arg_pack ());
@}
-
+
if (__builtin_va_arg_pack_len () 1)
return __open_2 (path, oflag);
@@ -942,7 +942,7 @@
@cindex @code{__fp16} data type
On ARM targets, GCC supports half-precision (16-bit) floating point via
-the @code{__fp16} type. You must enable this type explicitly
+the @code{__fp16} type. You must enable this type explicitly
with the @option{-mfp16-format} command-line option in order to use it.
ARM supports two incompatible representations for half-precision
@@ -963,7 +963,7 @@
The @code{__fp16} type is a storage format only. For purposes
of arithmetic and other operations, @code{__fp16} values in C or C++
expressions are automatically promoted to @code{float}. In addition,
-you cannot declare a function with a return value or parameters
+you cannot declare a function with a return value or parameters
of type @code{__fp16}.
Note that conversions from @code{double} to @code{__fp16}
@@ -971,14 +971,14 @@
of rounding, this can sometimes produce a different result than a
direct conversion.
-ARM provides hardware support for conversions between
+ARM provides hardware support for conversions between
@code{__fp16} and @code{float} values
as an extension to VFP and NEON (Advanced SIMD). GCC generates
code using these hardware instructions if you compile with
-options to select an FPU that provides them;
+options to select an FPU that provides them;
for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
in addition to the @option{-mfp16-format} option to select
-a half-precision format.
+a half-precision format.
Language-level support for the @code{__fp16} data type is
independent of whether GCC generates code using hardware floating-point
@@ -1995,7 +1995,7 @@
@cindex @code{alloc_size} attribute
The @code{alloc_size} attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
-one or two of the functions parameters. GCC uses this
+one or two of the functions parameters. GCC uses this
information to improve the correctness of @code{__builtin_object_size}.
The function parameter(s) denoting the allocated size are specified by
@@ -2004,7 +2004,7 @@
of the two function arguments specified. Argument numbering starts at
one.
-For instance,
+For instance,
@smallexample
void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
@@ -2213,7 +2213,7 @@
attribute also implies ``default'' visibility. It is an error to
explicitly specify any other visibility.
-In previous versions of GCC, the @code{dllexport} attribute was ignored
+In previous versions of GCC, the @code{dllexport} attribute was ignored
for inlined functions, unless the @option{-fkeep-inline-functions} flag
had been used. The default behaviour now is to emit all dllexported
inline functions; however, this can cause object file-size bloat, in
@@ -2424,10 +2424,10 @@
are @code{printf_unlocked} and @code{fprintf_unlocked}.
@xref{C Dialect Options,,Options Controlling C Dialect}.
-For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
+For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
recognized in the same context. Declarations including these format attributes
will be parsed for correct syntax, however the result of checking of such
format
-strings is not yet defined, and will not be carried out by this version of the
+strings is not yet defined, and will not be carried out by this version of the
compiler.
The target may also provide additional types of format checks.
@@ -2752,7 +2752,7 @@
synonyms, and cause the compiler to always call
the function by first loading its address into a register, and then using
the contents of that register. The @code{near}
