Re: Move -Wmaybe-uninitialized to -Wextra
The problem with false positives is correlated with the degree of optimization; a lot of people have reported problems at only the `-Og' optimization level (even when the code in question is embarrassingly correct). Therefore, the general solution is probably that the implem- entation of `-Wmaybe-uninitialized' be customized for the given level of optimization. However, I get the impression that this is easier said than done. >From what I've read, `-Wmaybe-uninitialized' is essentially customized for `-O2', which means that it will work pretty darn well at that optimization level. So, in the interim, I propose a simple approximation of the general solution: At an optimization level below `-O2' (or other than `-O2'): * `-Wmaybe-uninitialized' is moved to `-Wextra'. If `-Wall' has been specified, then gcc emits an informational note stating that `-Wmaybe-uninitialized' (or any other warning that has similar problems) has been disabled. * Provide a command-line option to disable such a note. * The user may always enable `-Wmaybe-uninitialized' either explicitly or as part of `-Wextra'. * If `-Wmaybe-uninitialized' is enabled by the user, then it implies `-O2' computations. That is to say, when the user specifies: -Og -Wmaybe-uninitialized or: -Og -Wextra then the user is explicitly telling the compiler to do all the optimizations of `-O2', but ONLY for the purpose of implementing `-Wmaybe-uninitialized' (or whichever warning requires those optimizations to function well); all those optimizations are to be thrown out after they have been used to good effect by `-Wmaybe-uninitialized'. The Code generation, etc., shall be performed at the optimization level the user specified (namely, `-Og' in this case). In other words, save the user from gcc's foibles, but let the user pay for the extra computation if so desired! What do you think? Sincerely, Michael Witten PS All of this trouble indicates that C (and other languages) are just not expressive enough with regard to initialization. Initialization semantics are basically a matter of API contract specification; the programmer needs the tools to write it down. Surely, gcc could provide `__builtin_assume_initialized(x);' and parameter attributes to help inform the reader (i.e., to help inform the compiler) about the code; a function parameter attribute could specify whether the given argument can be considered initialized after a call, and maybe specify further constraints, such as whether the guarantee is made only when the function return value is nonzero (or a certain value), etc. We need the language to write our thoughts down!
Re: [PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
On Wed, 8 Apr 2015 21:13:10 +0200 (CEST), Gerald Pfeifer wrote: > On Wed, 27 Apr 2011, Michael Witten wrote: >> --- >> trunk/gcc/doc/extend.texi |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi >> index eddff95..c154958 100644 >> --- a/trunk/gcc/doc/extend.texi >> +++ b/trunk/gcc/doc/extend.texi >> @@ -3997,7 +3997,7 @@ >> @smallexample >> __attribute__((noreturn)) void d0 (void), >> __attribute__((format(printf, 1, 2))) d1 (const char *, ...), >> - d2 (void) >> + d2 (void); >> @end smallexample >> >> @noindent > > Hi Michael, > > and big apologies for this falling through a lot of cracks > apparently. I just committed your patch with the ChangeLog > below. > > If there are any other patches that have not been committed > (nor NACKed yet, I know there were some as well), please let > us know and I will look into getting at least documentation > patches addressed swiftly going forward. > > Thank you, and sorry again, > Gerald > > 2015-04-08 Michael Witten > > * doc/extend.texi (Attribute Syntax): Add a trailing semicolon > to an example. > > Index: doc/extend.texi > === > --- doc/extend.texi (revision 221930) > +++ doc/extend.texi (working copy) > @@ -4771,7 +4771,7 @@ > @smallexample > __attribute__((noreturn)) void d0 (void), > __attribute__((format(printf, 1, 2))) d1 (const char *, ...), > - d2 (void) > + d2 (void); > @end smallexample > > @noindent Well, now! What a pleasant surprise! I was looking for a reason to crack open a beer, and this shall do nicely. Say, how did you end up coming across this patch after nearly 4 years? Anyway, thanks for letting me know, and thank you and the rest of the GCC team for all of your hard work; you make the world go round. Sincerely, Michael Witten
Re: [google] Linker plugin to do function reordering using callgraph edge profiles (issue5124041)
> Re: [google] Linker plugin to do function reordering... Is there a particularly good reason for why you guys slip `[google]' into all of your `Subject:' lines? I was under the impresions that this list is for work on GCC. Consider putting something germane in the brackets instead.
Re: [google] Linker plugin to do function reordering using callgraph edge profiles (issue5124041)
On Sat, 24 Sep 2011 10:00:37 -0400, Diego Novillo wrote: > On 11-09-24 09:37 , Michael Witten wrote: >>> Re: [google] Linker plugin to do function reordering... >> >> Is there a particularly good reason for why you guys >> slip `[google]' into all of your `Subject:' lines? > > Yes, labels in brackets tend to be markers for branches, version > numbers, specific modules. In this case, they're used to indicate > patches to one of the google branches (http://gcc.gnu.org/svn.html, > http://gcc.gnu.org/ml/gcc/2011-01/msg00246.html). >From that email: > google/integration >A branch following trunk that contains some minimal patches that > are likely not useful anywhere outside of Google's build environment. > These are typically configuration patches. Why is gnu.gcc.org hosting work that is specific to some company's build system? > google/main >A branch of google/integration that contains Google local patches > that we are looking to contribute to trunk. Some of these patches are > either in the process of being reviewed, or have not yet been > proposed. The intent of this branch is to serve as a staging platform > to allow collaboration with external developers. Patches in this > branch are only expected to remain here until they are reviewed and > accepted in trunk. Why is it necessary to announce a patch [series] for this branch when it is intended that such a patch [series] make it to the trunk? Shouldn't an employee of your company submit a `trunk'-worthy patch [series] for review as would anyone else? Isn't having one branch named `google' (or `google/maint') too ridiculously generic to be of any use whatsoever? Wouldn't it make far more sense to have a topic branch if deemed necessary (for, say, a large patch series)? Why is gnu.gcc.org hosting such a pointless branch? Is it just that the technical inadequacies of SVN made it easier for your multi-billion-dollar company to host its essentially private work in GNU's repository? Furthermore, looking at the `Subject' header of this email: Subject: Re: [google] Linker plugin to do function reordering using callgraph edge profiles (issue5124041) I wonder what `issue5124041' means. Is that a reference that only has meaning for employees of your company? Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
Message On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > > * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, > and reorganize nodes to group the discussion of attributes more > logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > >* gcc/doc/extend.texi: Add a `;', remove trailing whitespace, >and reorganize nodes to group the discussion of attributes more >logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > >* gcc/doc/extend.texi: Add a `;', remove trailing whitespace, >and reorganize nodes to group the discussion of attributes more >logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > >* gcc/doc/extend.texi: Add a `;', remove trailing whitespace, >and reorganize nodes to group the discussion of attributes more >logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > >* gcc/doc/extend.texi: Add a `;', remove trailing whitespace, >and reorganize nodes to group the discussion of attributes more >logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: extend.texi: Rearrange nodes; no text was removed or added > [4] Docs: extend.texi: Reword and rearrange attribute node introductions > > trunk/gcc/doc/extend.texi | 5449 > +++-- > 1 files changed, 2730 insertions(+), 2719 deletions(-) > > CHANGELOG > > Essentially, I think it would be easiest to squash all of these patches > together into one revision; here is a ChangeLog entry for such a revision: > > 2011-04-27 Michael Witten > >* gcc/doc/extend.texi: Add a `;', remove trailing whitespace, >and reorganize nodes to group the discussion of attributes more >logically. > > -- > 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
[PATCH 0/4] Docs: extend.texi
See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8
[PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
--- trunk/gcc/doc/extend.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi index eddff95..c154958 100644 --- a/trunk/gcc/doc/extend.texi +++ b/trunk/gcc/doc/extend.texi @@ -3997,7 +3997,7 @@ @smallexample __attribute__((noreturn)) void d0 (void), __attribute__((format(printf, 1, 2))) d1 (const char *, ...), - d2 (void) + d2 (void); @end smallexample @noindent -- 1.7.4.18.g68fe8
[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} attri
[PATCH 4/4] Docs: extend.texi: Reword and rearrange attribute node introductions
The rearrangement performed in the previous patch left the text in
somewhat of an inconsistent state in terms of the flow of concepts;
this patch improves the flow of concepts to something more sane by
editing the introductions to these nodes:
Attribute Syntax
Type Attributes
Variable Attributes
Function Attributes
---
trunk/gcc/doc/extend.texi | 53 +++-
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index 3b453e5..a9611de 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -1962,10 +1962,22 @@
@cindex attribute syntax
This section describes the syntax with which @code{__attribute__} may be
-used, and the constructs to which attribute specifiers bind, for the C
+used, and the constructs to which attribute specifiers bind for the C
-language. Some details may vary for C++ and Objective-C@. Because of
+language and (to a limited degree) some of its descendants.
+
+The keyword @code{__attribute__} allows you to specify special
+attributes when making a declaration. This keyword is followed by an
+attribute specification inside double parentheses.
+
+You may also specify attributes with @samp{__} preceding and following
+each keyword. This allows you to use them in header files without
+being concerned about a possible macro of the same name. For example,
+you may use @code{__noreturn__} instead of @code{noreturn}.
+
+GCC plugins may provide their own attributes.
+
-infelicities in the grammar for attributes, some forms described here
-may not be successfully parsed in all cases.
+Because of infelicities in the grammar for attributes, some forms
+described here may not be successfully parsed in all cases.
There are some problems with the semantics of attributes in C++. For
example, there are no manglings for attributes, although they may affect
@@ -2191,6 +2203,9 @@
@cindex attribute of types
@cindex type attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of @code{struct} and @code{union} types when you define
such types. This keyword is followed by an attribute specification
@@ -2583,6 +2598,9 @@
@cindex attribute of variables
@cindex variable attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of variables or structure fields. This keyword is followed
by an attribute specification inside double parentheses. Some
@@ -3214,14 +3232,17 @@
@cindex functions that have different optimization options
@cindex functions that are dynamically resolved
-In GNU C, you declare certain things about functions called in your program
-which help the compiler optimize function calls and check your code more
-carefully.
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
-The keyword @code{__attribute__} allows you to specify special
-attributes when making a declaration. This keyword is followed by an
-attribute specification inside double parentheses. The following
-attributes are currently defined for functions on all targets:
+The keyword @code{__attribute__} allows you to specify special attributes
+of function declarations in order to help the compiler optimize function
+calls and check your code more carefully. This keyword is followed by
+an attribute specification inside double parentheses. Other attributes
+are available for types (@pxref{Type Attributes}) and for variables
+(@pxref{Variable Attributes}).
+
+The following attributes are currently defined for functions on all targets:
@code{aligned}, @code{alloc_size}, @code{noreturn},
@code{returns_twice}, @code{noinline}, @code{noclone},
@code{always_inline}, @code{flatten}, @code{pure}, @code{const},
@@ -3237,16 +3258,6 @@
including @code{section} are supported for variables declarations
(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
-GCC plugins may provide their own attributes.
-
-You may also specify attributes with @samp{__} preceding and following
-each keyword. This allows you to use them in header files without
-being concerned about a possible macro of the same name. For example,
-you may use @code{__noreturn__} instead of @code{noreturn}.
-
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
-
@table @code
@c Keep this table alphabetized by attribute name. Treat _ as space.
--
1.7.4.18.g68fe8
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Tue, 3 May 2011 22:52:25 +0200 (CEST), Gerald Pfeifer 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.
To what do we owe this tradition other than laziness?
Shall I match the mindlessness of this rule by introducing a variant
patch that also alters non-whitespace on the offending lines?
Sincerely,
Michael Witten
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Thu, May 5, 2011 at 09:32, Richard Guenther wrote: > And yes, in "harm" I mostly refer to svn blame annoyances and to > patch/branch merge conflicts where context that causes the conflict > only changed in whitespace. Your tools are limiting the quality of your work. Are we not the toolmakers?
