Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, Sep 02, 2016 at 05:39:49PM -0500, Segher Boessenkool wrote: > It seems to be a regression, anyway? Older versions built fine? I see this warning, but only in stage1 of the build. Segher

Re: [PATCH] Move class substring_loc from c-family into gcc

On Fri, 2016-09-02 at 16:55 -0600, Martin Sebor wrote: > I've successfully tested the patch below by incorporating it into > the -Wformat-length pass I've been working on. I'd like to submit > the latest and hopefully close to final version of my work for > review without duplicating this code

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 9/2/16, Segher Boessenkool wrote: > On Fri, Sep 02, 2016 at 05:08:34PM -0400, Eric Gallager wrote: >> > The only way to know for sure what GCC is warning about is to look at >> > the uninit dump. >> >> How exactly do I generate an uninit dump? I'm not seeing any

Re: [PATCH] Move class substring_loc from c-family into gcc

I've successfully tested the patch below by incorporating it into the -Wformat-length pass I've been working on. I'd like to submit the latest and hopefully close to final version of my work for review without duplicating this code and it might be helpful if it was possible to build my latest

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, Sep 02, 2016 at 05:08:34PM -0400, Eric Gallager wrote: > > The only way to know for sure what GCC is warning about is to look at the > > uninit dump. > > How exactly do I generate an uninit dump? I'm not seeing any relevant > options in the GCC manual... -fdump-tree-uninit > > Moreover,

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 9/2/16, Manuel López-Ibáñez wrote: > On 02/09/16 20:27, Segher Boessenkool wrote: >> On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: >>> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*, >>> unsigned int)’: >>>

Re: [PATCH, ubsan, obvious] Fix typo in string empty check

On 02.09.2016 23:54, Jakub Jelinek wrote: Sure, sorry. gcc/ * ubsan.c (ubsan_use_new_style_p): Fix check for empty string. -- Thanks, K

Re: [PATCH, IPA] Check pointer for 0 before use in `get_odr_type`

On 02.09.2016 23:56, Jakub Jelinek wrote: On Fri, Sep 02, 2016 at 11:53:01PM +0300, Kirill Yukhin wrote: gcc/ * gcc/ipa-devirt.c (get_odr_type): Check odr_types_ptr for zero before dereferencing it. I've already tested/posted

Re: [PATCH, IPA] Check pointer for 0 before use in `get_odr_type`

On Fri, Sep 02, 2016 at 11:53:01PM +0300, Kirill Yukhin wrote: > Hello, > Looks like `get_odr_type ()` contains code which dereferences > pointer before check it for zero. I moved the line under the check. > > Bootstrap/regtest on x?86|x86_64 in progress. > > Is it ok for trunk if pass? > >

Re: [PATCH, ubsan, obvious] Fix typo in string empty check

On Fri, Sep 02, 2016 at 11:22:24PM +0300, Kirill Yukhin wrote: > Hello, > Patch in the bottom fixes typo in check of for string emptiness > > gcc/ > * gcc/ubsan.c (ubsan_use_new_style_p): Fix check for empty string. No gcc/ in the ChangeLog entry. > I'll bootstrap/regtest the patch and

[PATCH, IPA] Check pointer for 0 before use in `get_odr_type`

Hello, Looks like `get_odr_type ()` contains code which dereferences pointer before check it for zero. I moved the line under the check. Bootstrap/regtest on x?86|x86_64 in progress. Is it ok for trunk if pass? gcc/ * gcc/ipa-devirt.c (get_odr_type): Check odr_types_ptr for

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, Sep 02, 2016 at 09:31:14PM +0100, Manuel López-Ibáñez wrote: > Nevertheless, assignments within 'if' are one of the things that make > reading GCC code harder than it needs to be (and combine.c is scary). Yes and yes. But we really should not warn here. Segher

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 02/09/16 20:27, Segher Boessenkool wrote: On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*, unsigned int)’: ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized in this function

[PATCH, ubsan, obvious] Fix typo in string empty check

Hello, Patch in the bottom fixes typo in check of for string emptiness gcc/ * gcc/ubsan.c (ubsan_use_new_style_p): Fix check for empty string. I'll bootstrap/regtest the patch and check it into as obvious if no objections. -- Thanks, K commit 57ad19906b808386220d628a1ba326e043e0d211

[PATCH] PR fortran/77460

I plan to commit the following patch in the next day or two. Objections? 2016-09-03 Steven G. Kargl PR fortran/77460 * simplify.c (simplify_transformation_to_scalar): On error, result may be NULL, simply return. 2016-09-03 Steven G. Kargl

Re: [PATCH, obvious] Remove double condition from dwarf2out.c

On 02.09.2016 20:00, Jakub Jelinek wrote: On Fri, Sep 02, 2016 at 07:52:45PM +0300, Kirill Yukhin wrote: Hi, Remove identical conditions from AND in return. Will check-in after bootstrap/regtest on i386|x86_64 as obvious. gcc/ * dwarf2out.c (dw_val_equal_p): Remove redundant condition in

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 9/2/16, David Malcolm wrote: > On Fri, 2016-09-02 at 15:41 -0400, Eric Gallager wrote: >> On 9/2/16, Segher Boessenkool wrote: >> > On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: >> > > ../../gcc/combine.c: In function ‘int >> >

Re: PR35503 - warn for restrict pointer

On 02/09/16 18:44, David Malcolm wrote: Much better would be to have the formatting be done inside the diagnostics subsystem's call into pp_format, with something like this: warning_at_rich_loc_n (, OPT_Wrestrict, arg_positions .length (),

Re: [PATCH 4/4] (v2) Add -fdiagnostics-generate-patch

On Wed, 2016-08-24 at 21:13 -0400, David Malcolm wrote: > Changed in v2: I dropped -fdiagnostics-apply-fixits > > This patch uses the edit_context machinery to provide a new > -fdiagnostics-generate-patch option. > > If set an edit_context is created for global_dc, and any > fix-it hints emitted

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, 2016-09-02 at 15:41 -0400, Eric Gallager wrote: > On 9/2/16, Segher Boessenkool wrote: > > On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: > > > ../../gcc/combine.c: In function ‘int > > > combine_instructions(rtx_insn*, > > > unsigned int)’: > >

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 9/2/16, Segher Boessenkool wrote: > On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: >> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*, >> unsigned int)’: >> ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized >>

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: > ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*, > unsigned int)’: > ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized > in this function [-Wmaybe-uninitialized] > if ((next =

Re: [patch, libstdc++] std::shuffle: Generate two swap positions at a time if possible

On 2016-09-02 20:20, Eelis van der Weegen wrote: On 2016-08-31 14:45, Jonathan Wakely wrote: Is this significantly faster than just using uniform_int_distribution<_IntType>{0, __bound - 1}(__g) so we don't need to duplicate the logic? (And people maintaining the code won't reconvince themselves

[PATCH] Add a warning for suspicious use of conditional expressions in boolean context

Hi! As reported in PR77434 and PR77421 there should be a warning for suspicious uses of conditional expressions with non-boolean arguments. This warning triggers on conditional expressions in boolean context, when both possible results are non-zero integer constants, so that the resulting truth

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 9/2/16, Segher Boessenkool wrote: > On Fri, Sep 02, 2016 at 09:40:36AM -0400, Eric Gallager wrote: >> --- a/gcc/combine.c >> +++ b/gcc/combine.c >> @@ -1122,7 +1122,7 @@ static int >> combine_instructions (rtx_insn *f, unsigned int nregs) >> { >>rtx_insn

Re: [patch, libstdc++] std::shuffle: Generate two swap positions at a time if possible

On 2016-08-31 14:45, Jonathan Wakely wrote: Is this significantly faster than just using uniform_int_distribution<_IntType>{0, __bound - 1}(__g) so we don't need to duplicate the logic? (And people maintaining the code won't reconvince themselves it's correct every time they look at it :-) [..]

[committed] Introduce class edit_context (v3)

Changes in v3: - Updated doc/invoke.texi. - Renamed line_state to edited_line - I rewrote content-tracking in terms of edited lines, rather than tracking the whole file. This avoids the need to load the whole file, instead fetching it as needed from input.c's cache. This required a little fiddly

Re: PR35503 - warn for restrict pointer

On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote: [...] > The attached version passes bootstrap+test on ppc64le-linux-gnu. > Given that it only looks if parameters are restrict qualified and not > how they're used inside the callee, > this can have false positives as in above

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On 09/02/2016 02:35 AM, Uros Bizjak wrote: > --q-- > /* Pass float and _Complex float variable arguments by reference. > This avoids 64-bit store from a FP register to a pretend args save area > and subsequent 32-bit load from the saved location to a FP register. > > Note that

Re: cfg.c: redundant second assignment of bb_copy = NULL in free_original_copy_tables()

On 2 September 2016 at 15:49, Richard Biener wrote: > On Fri, 2 Sep 2016, Prathamesh Kulkarni wrote: > >> Hi, >> There appears to be a redundant second assignmeent bb_copy = NULL in >> free_copy_original_tables(). I suppose it should be >> bb_original = NULL instead ? >> I

Re: [PATCH, obvious] Remove double condition from dwarf2out.c

On Fri, Sep 02, 2016 at 07:52:45PM +0300, Kirill Yukhin wrote: > Hi, > Remove identical conditions from AND > in return. > Will check-in after bootstrap/regtest on i386|x86_64 as obvious. > > gcc/ > * dwarf2out.c (dw_val_equal_p): Remove redundant condition in > return statement. This

[PATCH, obvious] Remove double condition from dwarf2out.c

Hi, Remove identical conditions from AND in return. Will check-in after bootstrap/regtest on i386|x86_64 as obvious. gcc/ * dwarf2out.c (dw_val_equal_p): Remove redundant condition in return statement. -- Thanks, K commit 4c71ef36cda91edaef731e460a58fe09942b2d93 Author: Kirill Yukhin

Re: [PATCH] Fix up -fsanitize=address ctor order (PR sanitizer/77396, take 2)

On September 2, 2016 4:58:20 PM GMT+02:00, Jakub Jelinek wrote: >On Thu, Sep 01, 2016 at 09:58:44AM +0200, Richard Biener wrote: >> Ah, so it expects sth _before_ before-dynamic-init? At least it >seems >> that globals are not only registered inbetween

Re: [PATCH] Fix up ivopts POINTER_TYPE_P handling (PR tree-optimization/77444)

On September 2, 2016 5:11:39 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >I've looked a little bit at svn blame and we had: > tree steptype = type; > if (POINTER_TYPE_P (type)) >steptype = sizetype; >there initially and the > steptype = unsigned_type_for (type); >has been

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On Fri, Sep 2, 2016 at 3:46 PM, Yuri Rumyantsev wrote: > Hi Jeff, > > I am trying to reduce cost of repeated call of if-conversion for > epilogue vectorization. I'd like to clarify your recommendation - > should I design additional support for versioning in >

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Sep 02 2016, Andreas Schwab wrote: > On Sep 02 2016, Ian Lance Taylor wrote: > >> On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote: >>> >>> That breaks libgo on ia64. The problem is that _ucontext_t isn't >>> properly

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Sep 02 2016, Ian Lance Taylor wrote: > On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote: >> >> That breaks libgo on ia64. The problem is that _ucontext_t isn't >> properly aligned. > > Interesting. Thanks for looking into it. What is the

[committed] Remove redundant stmt in i386.c (PR other/77421)

Hi! I've committed as obvious the following change. I've tracked the redundant stmt to appear in r216794, where just a bunch of new cases were added and the redundant stmt together with those. 2016-09-02 Jakub Jelinek PR other/77421 * config/i386/i386.c

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote: > > That breaks libgo on ia64. The problem is that _ucontext_t isn't > properly aligned. Interesting. Thanks for looking into it. What is the required alignment? This code should be aligning it to a pointer

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Sep 2, 2016, at 6:31 AM, Joseph Myers wrote: > > On Fri, 2 Sep 2016, Uros Bizjak wrote: > >> It looks to me that we have no tests for _Complex float variable >> arguments passing in g*.dg/compat/. There are no xfails for alpha* in >> this directory, and these

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

That breaks libgo on ia64. The problem is that _ucontext_t isn't properly aligned. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: libgo/runtime: Fix signal stack size for ia64

On Sep 02 2016, Andreas Schwab wrote: > On Aug 31 2016, Ian Lance Taylor wrote: > >> Index: libgo/runtime/runtime.c >> === >> --- libgo/runtime/runtime.c (revision 239872) >> +++

Re: libgo/runtime: Fix signal stack size for ia64

On Aug 31 2016, Ian Lance Taylor wrote: > Index: libgo/runtime/runtime.c > === > --- libgo/runtime/runtime.c (revision 239872) > +++ libgo/runtime/runtime.c (working copy) > @@ -272,7 +272,14 @@

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

Hi, > + r += !a == ~b; > + r += !a == ~(int) b; I don't understand why ~b should not be warned at -Wall. Frankly I don't even understand why the above statements are completely optimized away. r += !a == ~b; is optimized away, but b = ~b; r += !a == b; Is not. Why? Bernd.

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On Fri, Sep 02, 2016 at 09:40:36AM -0400, Eric Gallager wrote: > --- a/gcc/combine.c > +++ b/gcc/combine.c > @@ -1122,7 +1122,7 @@ static int > combine_instructions (rtx_insn *f, unsigned int nregs) > { >rtx_insn *insn, *next; > - rtx_insn *prev; > + rtx_insn *prev = NULL; >struct

[PATCH] Fix alter_output_for_subst_insn (PR other/77421)

Hi! The two ports that use define_subst (ix86 and visium) don't do anything in this function, other than returning early - return insn_out, so all I could do is look at the intent. The *insn_out == '*' || *insn_out != '@' got flagged by some tool, the "*insn_out == '*' || " part is unnecessary,

C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

Martin reported that -Wlogical-not-parentheses issues a bogus warning for bit operations on booleans, because the warning didn't take integer promotions into account. The following patch ought to fix this problem. It's not exactly trivial because I had to handle even more complex expressions and

[PATCH] Fix up ivopts POINTER_TYPE_P handling (PR tree-optimization/77444)

Hi! I've looked a little bit at svn blame and we had: tree steptype = type; if (POINTER_TYPE_P (type)) steptype = sizetype; there initially and the steptype = unsigned_type_for (type); has been added later on in r209190, without cleaning up the earlier stmts. I think for POINTER_TYPE_P

[PATCH] Remove unnecessary conditional in get_odr_type (PR rtl-optimization/77425)

Hi! As mentioned in the PR, we have static GTY(()) vec *odr_types_ptr; #define odr_types (*odr_types_ptr) and in the else block do odr_types[val->id] = 0; first (which is actually (*odr_types_ptr)[val->id] = 0; without the obfuscation) and then if (odr_types_ptr) ...

[PATCH] Fix UB in sched-int.h iterator (PR rtl-optimization/77425)

Hi! We have #define DEPS_LIST_FIRST(L) ((L)->first) and first is the field of the struct, so for the case when list is NULL we do linkp = >first; which actually gives us NULL too, but with UB. From my analysis of the scheduler code, we should never use linkp (or anything else in the iterator)

[PATCH] Fix up -fsanitize=address ctor order (PR sanitizer/77396, take 2)

On Thu, Sep 01, 2016 at 09:58:44AM +0200, Richard Biener wrote: > Ah, so it expects sth _before_ before-dynamic-init? At least it seems > that globals are not only registered inbetween before/after-dynamic-init. Here is updated patch, bootstrapped/regtested on x86_64-linux and i686-linux, ok for

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

Hi Jeff, I am trying to reduce cost of repeated call of if-conversion for epilogue vectorization. I'd like to clarify your recommendation - should I design additional support for versioning in vect_do_peeling_for_loop_bound or lightweight version of if-conversion is sufficient? Any help in

[PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

While I was silencing some warnings about narrowing conversions, which was https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02129.html (for reference), I also silenced some warnings from -Wmaybe-uninitialized in combine.c and varasm.c while I was at it. I took the easy way out and simply initialized

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Fri, 2 Sep 2016, Uros Bizjak wrote: > It looks to me that we have no tests for _Complex float variable > arguments passing in g*.dg/compat/. There are no xfails for alpha* in > this directory, and these arguments would fail for sure for this > target. I suppose compat tests should be added

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Fri, Sep 2, 2016 at 2:37 PM, Uros Bizjak wrote: > On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek wrote: >> On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote: >>> On Fri, 2 Sep 2016, Uros Bizjak wrote: >>> >>> > argument. Passing _Complex

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek wrote: > On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote: >> On Fri, 2 Sep 2016, Uros Bizjak wrote: >> >> > argument. Passing _Complex float as a variable argument never >> > worked on alpha. Thus, we have no

Re: [RFC][IPA-VRP] Add support for IPA VRP in ipa-cp/ipa-prop

> Hi Honza, > > Here is a re-based version which also addresses the review comments. > > Do you mean the following, I was following other implementations. > > @@ -2264,6 +2430,11 @@ propagate_constants_accross_call (struct > cgraph_edge *cs) > _plats->bits_lattice); >ret |=

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote: > On Fri, 2 Sep 2016, Uros Bizjak wrote: > > > argument. Passing _Complex float as a variable argument never > > worked on alpha. Thus, we have no backward compatibility issues > > Presumably there should be an

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

On Fri, 2 Sep 2016, Uros Bizjak wrote: > argument. Passing _Complex float as a variable argument never > worked on alpha. Thus, we have no backward compatibility issues Presumably there should be an architecture-independent execution test of passing _Complex float in variable

Re: [PATCH][AArch64 - v3] Simplify eh_return implementation

Ramana Radhakrishnan wrote: > Can you please file a PR for this and add some testcases ?  This sounds like > a serious enough problem that needs to be looked at probably going back since > the dawn of time. I've created PR77455. Updated patch below: This patch simplifies the handling of the EH

Re: [PATCH] Use RPO order for fwprop iteration

On Fri, 2 Sep 2016, Robin Dapp wrote: > This causes a performance regression in the xalancbmk SPECint2006 > benchmark on s390x. At first sight, the produced asm output doesn't look > too different but I'll have a closer look. Is the fwprop order supposed > to have major performance implications?

[RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

Hello! I would like to propose an ABI adjustment for the aloha OSF/1 ABI. To quote explanation in the patch: --q-- /* Pass float and _Complex float variable arguments by reference. This avoids 64-bit store from a FP register to a pretend args save area and subsequent 32-bit load from

Re: [PATCH] Use RPO order for fwprop iteration

This causes a performance regression in the xalancbmk SPECint2006 benchmark on s390x. At first sight, the produced asm output doesn't look too different but I'll have a closer look. Is the fwprop order supposed to have major performance implications? Regards Robin > This changes it from PRE on

[ipa-cp] Change option name from -fipa-cp-bit to -fipa-bit-cp in ipcp_store_bits_results()

Committed as obvious after bootstrap+test on x86_64-unknown-linux-gnu. Thanks, Prathamesh 2016-09-02 Prathamesh Kulkarni * ipa-cp.c (ipcp_store_bits_results): Change option name from -fipa-cp-bit to -fipa-bit-cp. diff --git a/gcc/ipa-cp.c

Re: [RFC][IPA-VRP] Early VRP Implementation

Ping ? Thanks, Kugan On 23 August 2016 at 12:11, Kugan Vivekanandarajah wrote: > Hi, > > On 19 August 2016 at 21:41, Richard Biener wrote: >> On Tue, Aug 16, 2016 at 9:45 AM, kugan >> wrote: >>>

Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments

Hi Richard, On 25 August 2016 at 22:24, Richard Biener wrote: > On Thu, Aug 11, 2016 at 1:09 AM, kugan > wrote: >> Hi, >> >> >> On 10/08/16 20:28, Richard Biener wrote: >>> >>> On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek

[Fortran, Patch, PR72832, v1] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

Hi all, attached patch fixes the issue raised by PR72832. The issue was that the array descriptor of the SOURCE= in an ALLOCATE () was used to allocate an array object although an explicit array spec had been given. The initial test showed a second issue when a class array was copied. Compiling

Re: [PATCH, docs] invoke.texi: random copy-editing

On Wed, 29 Aug 2012, Sandra Loosemore wrote: > * doc/invoke.texi: Fix numerous typos and punctuation/grammatical > errors throughout the file. Re-word some awkward sentences and > paragraphs. There are three questions (and to some extent suggestions) on this patch and the text