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 l
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/t
> 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.
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 `
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 f
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 li
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 li
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 li
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 li
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 li
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
---
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
__attrib
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
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 Attrib
e 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
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
16 matches
Mail list logo
