| Message ID | 48f37d2c-7273-aaf9-cbdc-e6100115183b@gmail.com |
|---|---|
| State | New |
| Headers | show |
Martin Sebor <msebor@gmail.com> writes: > @@ -373,7 +373,7 @@ example, this code would produce an error: > > @smallexample > #if 0 > -You can't expect this to work. > +You cannot expect this to work. > #endif > @end smallexample > Sure the maintainers would have caught this, but: the "'" is needed here. The point is that code doesn't tokenise properly. Thanks, Richard
> The GCC manual uses "cannot" in most places (280 lines) but there > are a few instances of "can't" (33 lines). > > The attached patch replaces the informal "can't" with the former > for consistency. In my opinion, this is the wrong direction. Contractions are becoming more acceptable in even more formal writing and there's even a current US Supreme Court justice who uses them in her opinions. I certainly don't think it's worth a change to use "can't" throughout, but I'm not in favor of eliminating it either.
On 03/14/2017 01:41 PM, Richard Sandiford wrote: > Martin Sebor <msebor@gmail.com> writes: >> @@ -373,7 +373,7 @@ example, this code would produce an error: >> >> @smallexample >> #if 0 >> -You can't expect this to work. >> +You cannot expect this to work. >> #endif >> @end smallexample >> > > Sure the maintainers would have caught this, but: the "'" is needed here. > The point is that code doesn't tokenise properly. Great catch, thanks! I'll be sure to fix that if the patch is approved. Martin
On Tue, 14 Mar 2017, Martin Sebor wrote: > PS I wasted quite a bit of time updating tm.texi. I kept getting > the error below and didn't realize (forgot) that it was asking me > to copy $objdir/gcc/tm.texi to $srcdir/gcc/doc/tm.texi. Can > someone explain why this file requires these special steps when > the rest of the .texi files can be updated directly? Both a GPL copy and a GFDL copy of the text shared between tm.texi and target.def need to be checked in (hence not just having tm.texi.in but not tm.texi checked in). If existing text that was only in one place (so only under one of GPL and GFDL) is being moved so that there are copies under both licenses, then this involves docstring relicensing review (otherwise, just copying the generated tm.texi without any extra review for that copying is appropriate).
On 03/14/2017 02:53 PM, Richard Kenner wrote: >> The GCC manual uses "cannot" in most places (280 lines) but there >> are a few instances of "can't" (33 lines). >> >> The attached patch replaces the informal "can't" with the former >> for consistency. > > In my opinion, this is the wrong direction. Contractions are becoming > more acceptable in even more formal writing and there's even a current > US Supreme Court justice who uses them in her opinions. > > I certainly don't think it's worth a change to use "can't" throughout, > but I'm not in favor of eliminating it either. I don't consider this change important enough to spend too much time on but since you voiced an objection but offered little in the way of a rationale I feel I'd be remiss not to respond and explain my perspective. First, I agree that the less formal language is becoming more acceptable. Some style guides explicitly allow contractions, but others advise against them. The technical specifications that significant parts of GCC aim to conform to, and those I happen to work with the most closely (the C, C++, and POSIX standards), avoid them. The IEEE Editorial Style Manual recommends against using them. The author of Engineer's Guide to Technical Writing, Kenneth Budinski, equates them with slang. I personally don't feel too strongly about it, but the change seems like an opportunity to improve not just the style of the manual but also increase its consistency. I could see one being indifferent to such changes but I have trouble understanding how they could be viewed as the wrong direction. What is your rationale against it and what would you consider the right direction for the manual? Martin PS While researching this subject I came across the following two interesting references that I think are worth quoting: In Engineer's Guide to Technical Writing, the author writes: Contractions should never be used in technical writing [my opinion]. They are essentially a form of slang, and slang expressions are not appropriate in technical writing. Some technical writers disagree with it. They believe that writing without contractions is stiff. Use the appropriate practice for your organization. Use contractions sparingly, if at all. The NASA Technical Documentation Style Guide offers, in my view, sound advice: Contractions (for example, it's for it is or it has; don't for do not; doesn't for does not; isn't for is not; and won't for will not) are not forbidden in technical or business writing. A few well-placed contractions can help your material sound as if a person wrote it--always a worthy goal. But too many contractions can make your message sound too casual. The challenge with following this advice in the GCC manual is that engineers are rarely good at writing or judging the right tone of text. Often, contributions are also made by non-native speakers some of whom may not be able to discern between the of a contraction that helps achieve the goal and one that works against it. The one thing most of us do have is an eye and affinity for consistency, so using one style consistently throughout the manual seems like a good (and safe) approach.
> First, I agree that the less formal language is becoming more > acceptable. Some style guides explicitly allow contractions, > but others advise against them. The technical specifications > that significant parts of GCC aim to conform to, and those I > happen to work with the most closely (the C, C++, and POSIX > standards), avoid them. The IEEE Editorial Style Manual > recommends against using them. The author of Engineer's Guide > to Technical Writing, Kenneth Budinski, equates them with slang. How old are those documents? More recently, see http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ The latter references other documents, which advocate for more use of contractions even in formal writing. > I personally don't feel too strongly about it, but the change > seems like an opportunity to improve not just the style of > the manual but also increase its consistency. I could see > one being indifferent to such changes but I have trouble > understanding how they could be viewed as the wrong direction. > What is your rationale against it and what would you consider > the right direction for the manual? I think it's the wrong direction because I'd be in favor of gradually *introducing* contractions into to the manual instead of a change that eliminates them. I wouldn't be against a change that went in the other direction (used contractions consistently), but it would be good a large change, so I'm not advocating for doing that, but just instead using contractions in all new material and when modifying old material for other reasons.
On 03/15/2017 05:00 AM, Richard Kenner wrote: >> First, I agree that the less formal language is becoming more >> acceptable. Some style guides explicitly allow contractions, >> but others advise against them. The technical specifications >> that significant parts of GCC aim to conform to, and those I >> happen to work with the most closely (the C, C++, and POSIX >> standards), avoid them. The IEEE Editorial Style Manual >> recommends against using them. The author of Engineer's Guide >> to Technical Writing, Kenneth Budinski, equates them with slang. > > How old are those documents? More recently, see They're all the latest versions (C++ 2011, C++ 2017, and the IEEE Editorial Style Manual is the 2016 update). But to get a more representative sample I've surveyed some other references I have sitting on my hard drive. I found none that uses contractions: ARM Compiler Toolchain 4.1 Reference (2011) Clang 5,0 Compiler User’s Manual(*) (2017) DWARF Debugging Information Format Version 5 (2017) HP aCC 6.20 C Programmer's Guide(**)(2008) IBM Power ISA Version 3.0 (2015) IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014) Intel C++ Compiler 17.0 Developer Guide and Reference (2016) Intel 64 and IA-32 Architectures Software Developer’s Manual (2011) MIPS64 Architecture for Programmers (2010) Oracle Developer Studio 12.5 C/C++ Users Guide (2016) [*] Except for a few instances of don't. [**] "Can't" used in comments in coding examples. > http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm > https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ > > The latter references other documents, which advocate for more use of > contractions even in formal writing. These are legal guides, obviously not relevant in the context of technical writing. >> I personally don't feel too strongly about it, but the change >> seems like an opportunity to improve not just the style of >> the manual but also increase its consistency. I could see >> one being indifferent to such changes but I have trouble >> understanding how they could be viewed as the wrong direction. >> What is your rationale against it and what would you consider >> the right direction for the manual? > > I think it's the wrong direction because I'd be in favor of gradually > *introducing* contractions into to the manual instead of a change that > eliminates them. I wouldn't be against a change that went in the other > direction (used contractions consistently), but it would be good a large > change, so I'm not advocating for doing that, but just instead using > contractions in all new material and when modifying old material for > other reasons. Interesting. I don't share that view and clearly neither do writers of any of the technical specifications I listed above but I will go along with whatever the documentation maintainers think is appropriate or preferable for GCC. Martin
On 03/15/2017 09:40 AM, Martin Sebor wrote: > On 03/15/2017 05:00 AM, Richard Kenner wrote: >>> First, I agree that the less formal language is becoming more >>> acceptable. Some style guides explicitly allow contractions, >>> but others advise against them. The technical specifications >>> that significant parts of GCC aim to conform to, and those I >>> happen to work with the most closely (the C, C++, and POSIX >>> standards), avoid them. The IEEE Editorial Style Manual >>> recommends against using them. The author of Engineer's Guide >>> to Technical Writing, Kenneth Budinski, equates them with slang. >> >> How old are those documents? More recently, see > > They're all the latest versions (C++ 2011, C++ 2017, and the IEEE > Editorial Style Manual is the 2016 update). > > But to get a more representative sample I've surveyed some other > references I have sitting on my hard drive. I found none that > uses contractions: > > ARM Compiler Toolchain 4.1 Reference (2011) > Clang 5,0 Compiler User’s Manual(*) (2017) > DWARF Debugging Information Format Version 5 (2017) > HP aCC 6.20 C Programmer's Guide(**)(2008) > IBM Power ISA Version 3.0 (2015) > IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014) > Intel C++ Compiler 17.0 Developer Guide and Reference (2016) > Intel 64 and IA-32 Architectures Software Developer’s Manual (2011) > MIPS64 Architecture for Programmers (2010) > Oracle Developer Studio 12.5 C/C++ Users Guide (2016) > > [*] Except for a few instances of don't. > [**] "Can't" used in comments in coding examples. > >> >> http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm >> >> https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ >> >> The latter references other documents, which advocate for more use of >> contractions even in formal writing. > > These are legal guides, obviously not relevant in the context > of technical writing. Sorry, I meant "not obviously relevant." > >>> I personally don't feel too strongly about it, but the change >>> seems like an opportunity to improve not just the style of >>> the manual but also increase its consistency. I could see >>> one being indifferent to such changes but I have trouble >>> understanding how they could be viewed as the wrong direction. >>> What is your rationale against it and what would you consider >>> the right direction for the manual? >> >> I think it's the wrong direction because I'd be in favor of gradually >> *introducing* contractions into to the manual instead of a change that >> eliminates them. I wouldn't be against a change that went in the other >> direction (used contractions consistently), but it would be good a large >> change, so I'm not advocating for doing that, but just instead using >> contractions in all new material and when modifying old material for >> other reasons. My disagreement aside, I should have thanked you for clarifying your view. (Thank you.) > > Interesting. I don't share that view and clearly neither do > writers of any of the technical specifications I listed above > but I will go along with whatever the documentation maintainers > think is appropriate or preferable for GCC. > > Martin
On 03/14/2017 09:53 PM, Richard Kenner wrote: >> The GCC manual uses "cannot" in most places (280 lines) but there >> are a few instances of "can't" (33 lines). >> >> The attached patch replaces the informal "can't" with the former >> for consistency. > > In my opinion, this is the wrong direction. Contractions are becoming > more acceptable in even more formal writing and there's even a current > US Supreme Court justice who uses them in her opinions. > > I certainly don't think it's worth a change to use "can't" throughout, > but I'm not in favor of eliminating it either. I think for non-native speakers of English, using the full word is easier to read (you can't take my experience as an example, as I was exposed to written English 48 years ago). I think replacing the few instances of can't with cannot is worth the clarity. Kind regards,
> > The latter references other documents, which advocate for more use of > > contractions even in formal writing. > > These are legal guides, not obviously relevant in the context > of technical writing. Yes and no. The argument for them is that legal writing is the most formal of all and has been the slowest to adopt contractions.
On 03/15/2017 09:40 AM, Martin Sebor wrote: > On 03/15/2017 05:00 AM, Richard Kenner wrote: >>> First, I agree that the less formal language is becoming more >>> acceptable. Some style guides explicitly allow contractions, >>> but others advise against them. The technical specifications >>> that significant parts of GCC aim to conform to, and those I >>> happen to work with the most closely (the C, C++, and POSIX >>> standards), avoid them. The IEEE Editorial Style Manual >>> recommends against using them. The author of Engineer's Guide >>> to Technical Writing, Kenneth Budinski, equates them with slang. >> >> How old are those documents? More recently, see > > They're all the latest versions (C++ 2011, C++ 2017, and the IEEE > Editorial Style Manual is the 2016 update). > > But to get a more representative sample I've surveyed some other > references I have sitting on my hard drive. I found none that > uses contractions: > > ARM Compiler Toolchain 4.1 Reference (2011) > Clang 5,0 Compiler User’s Manual(*) (2017) > DWARF Debugging Information Format Version 5 (2017) > HP aCC 6.20 C Programmer's Guide(**)(2008) > IBM Power ISA Version 3.0 (2015) > IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014) > Intel C++ Compiler 17.0 Developer Guide and Reference (2016) > Intel 64 and IA-32 Architectures Software Developer’s Manual (2011) > MIPS64 Architecture for Programmers (2010) > Oracle Developer Studio 12.5 C/C++ Users Guide (2016) > > [*] Except for a few instances of don't. > [**] "Can't" used in comments in coding examples. > >> >> http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm >> >> https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ >> >> The latter references other documents, which advocate for more use of >> contractions even in formal writing. > > These are legal guides, obviously not relevant in the context > of technical writing. > >>> I personally don't feel too strongly about it, but the change >>> seems like an opportunity to improve not just the style of >>> the manual but also increase its consistency. I could see >>> one being indifferent to such changes but I have trouble >>> understanding how they could be viewed as the wrong direction. >>> What is your rationale against it and what would you consider >>> the right direction for the manual? >> >> I think it's the wrong direction because I'd be in favor of gradually >> *introducing* contractions into to the manual instead of a change that >> eliminates them. I wouldn't be against a change that went in the other >> direction (used contractions consistently), but it would be good a large >> change, so I'm not advocating for doing that, but just instead using >> contractions in all new material and when modifying old material for >> other reasons. > > Interesting. I don't share that view and clearly neither do > writers of any of the technical specifications I listed above > but I will go along with whatever the documentation maintainers > think is appropriate or preferable for GCC. I got behind on mail so I'm coming into this a few days late.... :-( The GCC manual isn't as formal a document as a language standards document. I think "can't" is OK, but OTOH I would write "cannot" myself, and since there's already a clear bias in favor of "cannot" in the text, I think the patch is OK, modulo fixing the one use in the example. -Sandra
Index: gcc/doc/extend.texi =================================================================== --- gcc/doc/extend.texi (revision 246134) +++ gcc/doc/extend.texi (working copy) @@ -7509,7 +7509,7 @@ In this case, GCC does not actually output assembl function, unless you specify the option @option{-fkeep-inline-functions}. If there is a nonintegrated call, then the function is compiled to assembler code as usual. The function must also be compiled as usual if -the program refers to its address, because that can't be inlined. +the program refers to its address, because that cannot be inlined. @opindex Winline Note that certain usages in a function definition can make it unsuitable @@ -9176,7 +9176,7 @@ This results in an incomplete type, much like what @code{struct foo} without describing the elements. A later declaration that does specify the possible values completes the type. -You can't allocate variables or storage using the type while it is +You cannot allocate variables or storage using the type while it is incomplete. However, you can work with pointers to that type. This extension may not be very useful, but it makes the handling of Index: gcc/doc/hostconfig.texi =================================================================== --- gcc/doc/hostconfig.texi (revision 246134) +++ gcc/doc/hostconfig.texi (working copy) @@ -22,7 +22,7 @@ header. @xref{System Config}. @menu * Host Common:: Things every host probably needs implemented. -* Filesystem:: Your host can't have the letter `a' in filenames? +* Filesystem:: Your host cannot have the letter `a' in filenames? * Host Misc:: Rare configuration options for hosts. @end menu Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi (revision 246134) +++ gcc/doc/install.texi (working copy) @@ -3633,7 +3633,7 @@ The libffi library haven't been ported to 64-bit H Refer to @uref{binaries.html,,binaries} for information about obtaining precompiled GCC binaries for HP-UX@. Precompiled binaries must be obtained -to build the Ada language as it can't be bootstrapped using C@. Ada is +to build the Ada language as it cannot be bootstrapped using C@. Ada is only available for the 32-bit PA-RISC runtime. Starting with GCC 3.4 an ISO C compiler is required to bootstrap. The @@ -3713,12 +3713,12 @@ Although the HP and GNU linkers are both supported HP linker be used for link editing on this target. At this time, the GNU linker does not support the creation of long -branch stubs. As a result, it can't successfully link binaries +branch stubs. As a result, it cannot successfully link binaries containing branch offsets larger than 8 megabytes. In addition, there are problems linking shared libraries, linking executables with @option{-static}, and with dwarf2 unwind and exception support. It also doesn't provide stubs for internal calls to global functions -in shared libraries, so these calls can't be overloaded. +in shared libraries, so these calls cannot be overloaded. The HP dynamic loader does not support GNU symbol versioning, so symbol versioning is not supported. It may be necessary to disable symbol Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi (revision 246134) +++ gcc/doc/invoke.texi (working copy) @@ -6471,7 +6471,7 @@ different size. @opindex Winvalid-pch @opindex Wno-invalid-pch Warn if a precompiled header (@pxref{Precompiled Headers}) is found in -the search path but can't be used. +the search path but cannot be used. @item -Wlong-long @opindex Wlong-long @@ -10733,7 +10733,7 @@ more details. The run-time behavior can be influe the available options are shown at startup of the instrumented program. See @url{https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags} for a list of supported options. -The option can't be combined with @option{-fsanitize=thread} +The option cannot be combined with @option{-fsanitize=thread} and/or @option{-fcheck-pointer-bounds}. @item -fsanitize=kernel-address @@ -10740,7 +10740,7 @@ and/or @option{-fcheck-pointer-bounds}. @opindex fsanitize=kernel-address Enable AddressSanitizer for Linux kernel. See @uref{https://github.com/google/kasan/wiki} for more details. -The option can't be combined with @option{-fcheck-pointer-bounds}. +The option cannot be combined with @option{-fcheck-pointer-bounds}. @item -fsanitize=thread @opindex fsanitize=thread @@ -10751,7 +10751,7 @@ details. The run-time behavior can be influenced u environment variable; see @url{https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags} for a list of supported options. -The option can't be combined with @option{-fsanitize=address}, +The option cannot be combined with @option{-fsanitize=address}, @option{-fsanitize=leak} and/or @option{-fcheck-pointer-bounds}. @item -fsanitize=leak @@ -10763,7 +10763,7 @@ and other allocator functions. See @uref{https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer} for more details. The run-time behavior can be influenced using the @env{LSAN_OPTIONS} environment variable. -The option can't be combined with @option{-fsanitize=thread}. +The option cannot be combined with @option{-fsanitize=thread}. @item -fsanitize=undefined @opindex fsanitize=undefined @@ -10841,7 +10841,7 @@ a++; This option enables instrumentation of array bounds. Various out of bounds accesses are detected. Flexible array members, flexible array member-like arrays, and initializers of variables with static storage are not instrumented. -The option can't be combined with @option{-fcheck-pointer-bounds}. +The option cannot be combined with @option{-fcheck-pointer-bounds}. @item -fsanitize=bounds-strict @opindex fsanitize=bounds-strict @@ -10848,7 +10848,7 @@ arrays, and initializers of variables with static This option enables strict instrumentation of array bounds. Most out of bounds accesses are detected, including flexible array members and flexible array member-like arrays. Initializers of variables with static storage are not -instrumented. The option can't be combined +instrumented. The option cannot be combined with @option{-fcheck-pointer-bounds}. @item -fsanitize=alignment @@ -23164,7 +23164,7 @@ disabled by specifying @option{-mno-zdcbranch}. @item -mcbranch-force-delay-slot @opindex mcbranch-force-delay-slot Force the usage of delay slots for conditional branches, which stuffs the delay -slot with a @code{nop} if a suitable instruction can't be found. By default +slot with a @code{nop} if a suitable instruction cannot be found. By default this option is disabled. It can be enabled to work around hardware bugs as found in the original SH7055. @@ -24689,7 +24689,7 @@ Generate output containing library calls for float @strong{Warning:} the requisite libraries are not part of GCC@. Normally the facilities of the machine's usual C compiler are used, but -this can't be done directly in cross-compilation. You must make your +this cannot be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation. @@ -26593,7 +26593,7 @@ If a standard directory begins with the configured @findex COMPILER_PATH The value of @env{COMPILER_PATH} is a colon-separated list of directories, much like @env{PATH}. GCC tries the directories thus -specified when searching for subprograms, if it can't find the +specified when searching for subprograms, if it cannot find the subprograms using @env{GCC_EXEC_PREFIX}. @item LIBRARY_PATH @@ -26601,7 +26601,7 @@ subprograms using @env{GCC_EXEC_PREFIX}. The value of @env{LIBRARY_PATH} is a colon-separated list of directories, much like @env{PATH}. When configured as a native compiler, GCC tries the directories thus specified when searching for special -linker files, if it can't find them using @env{GCC_EXEC_PREFIX}. Linking +linker files, if it cannot find them using @env{GCC_EXEC_PREFIX}. Linking using GCC also uses these directories when searching for ordinary libraries for the @option{-l} option (but directories specified with @option{-L} come first). @@ -26660,7 +26660,7 @@ seen in the compilation. As it searches for the i compiler looks for a precompiled header in each directory just before it looks for the include file in that directory. The name searched for is the name specified in the @code{#include} with @samp{.gch} appended. If -the precompiled header file can't be used, it is ignored. +the precompiled header file cannot be used, it is ignored. For instance, if you have @code{#include "all.h"}, and you have @file{all.h.gch} in the same directory as @file{all.h}, then the @@ -26701,13 +26701,13 @@ A precompiled header file can be used only when th Only one precompiled header can be used in a particular compilation. @item -A precompiled header can't be used once the first C token is seen. You +A precompiled header cannot be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you cannot include a precompiled header from inside another header. @item The precompiled header file must be produced for the same language as -the current compilation. You can't use a C precompiled header for a C++ +the current compilation. You cannot use a C precompiled header for a C++ compilation. @item Index: gcc/doc/loop.texi =================================================================== --- gcc/doc/loop.texi (revision 246134) +++ gcc/doc/loop.texi (working copy) @@ -567,7 +567,7 @@ relative to @code{p + i}. The access functions of @code{@{i_init, + i_step@}_for1} and @code{@{j_init, +, j_step@}_for2} relative to @code{a}. -Usually, the object the pointer refers to is either unknown, or we can't +Usually, the object the pointer refers to is either unknown, or we cannot prove that the access is confined to the boundaries of a certain object. Two data references can be compared only if at least one of these two Index: gcc/doc/md.texi =================================================================== --- gcc/doc/md.texi (revision 246134) +++ gcc/doc/md.texi (working copy) @@ -3728,7 +3728,7 @@ Any kind of immediate operand, unless it matches t Memory location with B base register, but not using a long offset. @item W -A memory operand with an address that can't be used in an unaligned access. +A memory operand with an address that cannot be used in an unaligned access. @end ifset @item Z Index: gcc/doc/objc.texi =================================================================== --- gcc/doc/objc.texi (revision 246134) +++ gcc/doc/objc.texi (working copy) @@ -1157,7 +1157,7 @@ GCC version 4.6. The GNU Objective-C runtime provides a hook, called @code{__objc_msg_forward2}, which is called by -@code{objc_msg_lookup()} when it can't find a method implementation in +@code{objc_msg_lookup()} when it cannot find a method implementation in the runtime tables and after calling @code{+resolveInstanceMethod:} and @code{+resolveClassMethod:} has been attempted and did not succeed in dynamically registering the method. Index: gcc/doc/rtl.texi =================================================================== --- gcc/doc/rtl.texi (revision 246134) +++ gcc/doc/rtl.texi (working copy) @@ -2225,7 +2225,7 @@ Represents the result of subtracting @var{y} from of comparison. The result is computed without overflow, as if with infinite precision. -Of course, machines can't really subtract with infinite precision. +Of course, machines cannot really subtract with infinite precision. However, they can pretend to do so when only the sign of the result will be used, which is the case when the result is stored in the condition code. And that is the @emph{only} way this kind of expression may Index: gcc/doc/tm.texi =================================================================== --- gcc/doc/tm.texi (revision 246134) +++ gcc/doc/tm.texi (working copy) @@ -2546,7 +2546,7 @@ force @var{x} into a memory location. For example immediate values into general-purpose registers, but does not have an instruction for loading an immediate value into a floating-point register, so @code{PREFERRED_RELOAD_CLASS} returns @code{NO_REGS} when -@var{x} is a floating-point constant. If the constant can't be loaded +@var{x} is a floating-point constant. If the constant cannot be loaded into any kind of register, code generation will be better if @code{TARGET_LEGITIMATE_CONSTANT_P} makes the constant illegitimate instead of using @code{TARGET_PREFERRED_RELOAD_CLASS}. @@ -2577,7 +2577,7 @@ to use when it is necessary to be able to hold a v ordinarily be used. Unlike @code{PREFERRED_RELOAD_CLASS}, this macro should be used when -there are certain modes that simply can't go in certain reload classes. +there are certain modes that simply cannot go in certain reload classes. The value is a register class; perhaps @var{class}, or perhaps another, smaller class. @@ -9996,7 +9996,7 @@ floating point operations, but to perform a single the FPSCR PR bit has to be cleared, while for a double precision operation, this bit has to be set. Changing the PR bit requires a general purpose register as a scratch register, hence these FPSCR sets have to -be inserted before reload, i.e.@: you can't put this into instruction emitting +be inserted before reload, i.e.@: you cannot put this into instruction emitting or @code{TARGET_MACHINE_DEPENDENT_REORG}. You can have multiple entities that are mode-switched, and select at run time Index: gcc/doc/tm.texi.in =================================================================== --- gcc/doc/tm.texi.in (revision 246134) +++ gcc/doc/tm.texi.in (working copy) @@ -2304,7 +2304,7 @@ force @var{x} into a memory location. For example immediate values into general-purpose registers, but does not have an instruction for loading an immediate value into a floating-point register, so @code{PREFERRED_RELOAD_CLASS} returns @code{NO_REGS} when -@var{x} is a floating-point constant. If the constant can't be loaded +@var{x} is a floating-point constant. If the constant cannot be loaded into any kind of register, code generation will be better if @code{TARGET_LEGITIMATE_CONSTANT_P} makes the constant illegitimate instead of using @code{TARGET_PREFERRED_RELOAD_CLASS}. @@ -2326,7 +2326,7 @@ to use when it is necessary to be able to hold a v ordinarily be used. Unlike @code{PREFERRED_RELOAD_CLASS}, this macro should be used when -there are certain modes that simply can't go in certain reload classes. +there are certain modes that simply cannot go in certain reload classes. The value is a register class; perhaps @var{class}, or perhaps another, smaller class. @@ -7266,7 +7266,7 @@ floating point operations, but to perform a single the FPSCR PR bit has to be cleared, while for a double precision operation, this bit has to be set. Changing the PR bit requires a general purpose register as a scratch register, hence these FPSCR sets have to -be inserted before reload, i.e.@: you can't put this into instruction emitting +be inserted before reload, i.e.@: you cannot put this into instruction emitting or @code{TARGET_MACHINE_DEPENDENT_REORG}. You can have multiple entities that are mode-switched, and select at run time Index: gcc/doc/trouble.texi =================================================================== --- gcc/doc/trouble.texi (revision 246134) +++ gcc/doc/trouble.texi (working copy) @@ -25,7 +25,7 @@ where people's opinions differ as to what is best. This is necessary, but doesn't always work smoothly. * Standard Libraries:: GCC uses the system C library, which might not be compliant with the ISO C standard. -* Disappointments:: Regrettable things we can't change, but not quite bugs. +* Disappointments:: Regrettable things we cannot change, but not quite bugs. * C++ Misunderstandings:: Common misunderstandings with GNU C++. * Non-bugs:: Things we think are right, but some others disagree. * Warnings and Errors:: Which problems in your code get warnings, @@ -373,7 +373,7 @@ example, this code would produce an error: @smallexample #if 0 -You can't expect this to work. +You cannot expect this to work. #endif @end smallexample @@ -743,7 +743,7 @@ In @code{get_i()}, @code{i} is not used in a depen compiler will look for a name declared at the enclosing namespace scope (which is the global scope here). It will not look into the base class, since that is dependent and you may declare specializations of -@code{Base} even after declaring @code{Derived}, so the compiler can't +@code{Base} even after declaring @code{Derived}, so the compiler cannot really know what @code{i} would refer to. If there is no global variable @code{i}, then you will get an error message.