===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.81
@@ -308,11 +308,11 @@ is a good candidate for being mentioned
<p>Larger accomplishments, either as part of a specific project, or long
term commitment, merit mention on the front page. Examples include projects
-like tree-ssa, new backends, major advances in optimization or standards
+like tree-ssa, new back ends, major advances in optimization or standards
compliance.</p>
<p>The gcc-announce mailing list serves to announce new releases and changes
-like frontends or backends being dropped.</p>
+like front ends or back ends being dropped.</p>
</body>
</html>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/frontends.html,v
retrieving revision 1.38
@@ -33,14 +33,14 @@ are very mature.</p>
href="http://www.mercurylang.org/download/gcc-backend.html">Mercury</a>,
a declarative logic/functional language. The University of Melbourne Mercury
compiler is written in Mercury; originally it compiled via C but now it also
-has a backend that generates assembler directly, using the GCC backend.</li>
+has a back end that generates assembler directly, using the GCC back end.</li>
<li><a href="http://CobolForGCC.sourceforge.net/">Cobol For GCC</a>
(at an early stage of development).</li>
<li><a href="http://www.nongnu.org/gm2/">GNU Modula-2</a> implements
the PIM2, PIM3, PIM4 and ISO dialects of the language. The compiler
-is fully operational with the GCC 4.1.2 backend (on GNU/Linux x86
+is fully operational with the GCC 4.1.2 back end (on GNU/Linux x86
systems). Work is in progress to move the frontend to the GCC trunk.
The frontend is mostly written in Modula-2, but includes a bootstrap
procedure via a heavily modified version of p2c.</li>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.106
@@ -95,7 +95,7 @@ before <a href="#subscribe">subscribing<
<li><b><a href="http://gcc.gnu.org/ml/jit/">jit</a></b>
is for discussion and development of
<a href="http://gcc.gnu.org/wiki/JIT">libgccjit</a>, an experimental
- library for implementing Just-In-Time compilation using gcc as a backend.
+ library for implementing Just-In-Time compilation using GCC as a back end.
The list is intended for both users and developers of the library.
Patches for the jit branch should go to both this list and
<b>gcc-patches</b>.</li>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.137
@@ -1079,10 +1079,10 @@ noticed or fixed defects or made other u
<dt><b>May 1, 2000</b></dt>
<dd>
<p>Richard Earnshaw of ARM Ltd, and Nick Clifton of Cygnus, a Red Hat
-company, have contributed a new backend for the Arm and Thumb
+company, have contributed a new back end for the Arm and Thumb
processors.</p>
-<p>The new backend combines code generation for the Arm, the Thumb and
+<p>The new back end combines code generation for the Arm, the Thumb and
the StrongArm into one compiler, with the target processor and
instruction sets being selectable via command line switches.</p>
</dd>
@@ -1260,7 +1260,7 @@ changes from the old GCC 2 sources.
<dt><b>September 2, 1999</b></dt>
<dd>
-Richard Henderson has finished merging the ia32 backend rewrite into the
+Richard Henderson has finished merging the ia32 back end rewrite into the
mainline GCC sources. The rewrite is designed to improve optimization
opportunities for the Pentium II target, but also provides a cleaner
way to optimize for the Pentium III, AMD-K7 and other high end ia32
@@ -1537,7 +1537,7 @@ Cygnus donates <a href="news/chill.html"
<dt><b>August 25, 1998</b></dt>
<dd>
- David Miller donates rewritten <a href="news/sparc.html"><b>sparc backend</b></a>.
+ David Miller donates rewritten <a href="news/sparc.html"><b>SPARC back end</b></a>.
</dd>
<dt><b>August 19, 1998</b></dt>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.189
@@ -880,7 +880,7 @@ be prefixed with the initials of the dis
<dt>dataflow-branch</dt>
<dd>This branch has been merged into mainline on June 6, 2007
- as svn revision 125624. It used to contain replacement of backend
+ as svn revision 125624. It used to contain a replacement of back-end
dataflow with df.c based dataflow. The branch was maintained
by Daniel Berlin <
<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.0/index.html,v
retrieving revision 1.2
@@ -84,7 +84,7 @@ release:</p>
libraries built by EGCS 1.0 that contain C++ code (upgrade to 1.0.1 and
use that).</p></li>
- <li><p> Various bugfixes in the x86, hppa, mips, and rs6000/ppc backends.</p>
+ <li><p> Various bugfixes in the x86, hppa, mips, and rs6000/ppc back ends.</p>
<p>The x86 changes fix code generation errors exposed when building
glibc2 and the usual GNU/Linux dynamic linker (ld.so).</p>
@@ -143,7 +143,7 @@ serious problems in EGCS 1.0.1.</p>
<li> Add missing entries to g77 lang-options.</li>
<li> Fix problem with -fpedantic in the g77 compiler.</li>
<li> Fix "backspace" problem with g77 on alphas.</li>
- <li> Fix x86 backend problem with Fortran literals and -fpic.</li>
+ <li> Fix x86 back end problem with Fortran literals and -fpic.</li>
<li> Fix some of the problems with negative subscripts for g77 on
alphas.</li>
<li> Fixes for Fortran builds on cygwin32/mingw32.</li>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/features.html,v
retrieving revision 1.21
@@ -60,7 +60,7 @@
<li> x86: Alignment of static store data and jump targets is per
Intel recommendations now. Various improvements throughout the
x86 port to improve performance on Pentium processors (including
- improved epilogue sequences for Pentium chips and backend
+ improved epilogue sequences for Pentium chips and back end
improvements which should help register allocation on all x86
variants. Conditional move support has been fixed and enabled for
PPro processors.
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/index.html,v
retrieving revision 1.6
@@ -87,7 +87,7 @@ EGCS 1.1:</p>
<li> Fix a few arm code generation bugs.</li>
<li> Fixincludes will fix additional broken SCO OpenServer header
files.</li>
- <li> Fix a m68k backend bug which caused invalid offsets in reg+d
+ <li> Fix a m68k back end bug which caused invalid offsets in reg+d
addresses.</li>
<li> Fix problems with 64bit AIX 4.3 support.</li>
<li> Fix handling of long longs for varargs/stdarg functions on the
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/features.html,v
retrieving revision 1.39
@@ -46,7 +46,7 @@
</ul></li>
<li>New Targets and Target Specific Improvements
<ul>
- <li><a href="../news/sparc.html">SPARC backend rewrite</a>.</li>
+ <li><a href="../news/sparc.html">SPARC back end rewrite</a>.</li>
<li>-mschedule=8000 will optimize code for PA8000 class processors;
-mpa-risc-2-0 will generate code for PA2.0 processors</li>
<li>Various micro-optimizations for the ia32 port. K6 optimizations</li>
@@ -197,7 +197,7 @@ enabled by default in future releases.
<ul>
<li>Work around bug in Sun V5.0 compilers which caused bootstrap
comparison failures on SPARC targets.</li>
- <li>Fix SPARC backend bug which caused aborts in final.c.</li>
+ <li>Fix SPARC back end bug which caused aborts in final.c.</li>
<li>Fix sparc-hal-solaris2* configuration fragments.</li>
<li>Fix bug in sparc block profiling.</li>
<li>Fix obscure code generation bug for the PARISC targets.</li>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.123
@@ -639,7 +639,7 @@ int i = A().f(); // error, f() requires
<a href="http://gcc.gnu.org/wiki/FunctionMultiVersioning">wiki</a> for more
information.
</li>
- <li> The x86 backend has been improved to allow option
+ <li> The x86 back end has been improved to allow option
<code>-fschedule-insns</code> to work reliably.
This option can be used to schedule instructions better and leads to
improved performace in certain cases.</li>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/news/profiledriven.html,v
retrieving revision 1.8
@@ -54,7 +54,7 @@ passes destroyed the profile.
</p>
<p> The first contribution to this project was to revamp large parts
-of the GCC backend to maintain a consistent copy of the control flow
+of the GCC back end to maintain a consistent copy of the control flow
graph so that all optimization passes can easily get correct profile
information. As part of this rework, the jump optimization pass has
been rewritten. The new jump optimization should be faster and easier
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/news/sparc.html,v
retrieving revision 1.6
@@ -10,7 +10,7 @@
<p>August 25, 1998</p>
<p>We are pleased to announce that David Miller has donated a rewrite of the
-SPARC backend for GCC. This rewrite should improve performance as well as
+SPARC back end for GCC. This rewrite should improve performance as well as
improve long term maintainability of the compiler. Details follow.</p>
<pre>
@@ -139,7 +139,7 @@ improve long term maintainability of the
4) Tremendously improved support for instruction level parallelism on
UltraSPARC. Using some new pieces of infrastructure added to
- the Haifa scheduler recently, the SPARC backend can now achieve
+ the Haifa scheduler recently, the SPARC back end can now achieve
higher levels of instruction issue per cycle on UltraSPARC than
has ever been possible before.
@@ -201,13 +201,13 @@ improve long term maintainability of the
similar techniques will be incorporated into the sparc64 support
code as well.
-6) Nearly all operations ever generated by the SPARC backend are
+6) Nearly all operations ever generated by the SPARC back end are
described with a single RTL pattern which generates a single
SPARC instruction. This is important for delay slot and
instruction level scheduling.
7) There are no more hard coded hard registers used in the
- RTL generated by the SPARC backend. The only exceptions to
+ RTL generated by the SPARC back end. The only exceptions to
this which remain are unavoidable cases such as for argument
passing semantics and for the PIC base register (the latter can
actually be eliminated, and this is a planned future enhancement).
@@ -240,7 +240,7 @@ improve long term maintainability of the
b) The second instruction adds "some unspecified number
of low bits of 0x12345678" to register %o0
- The new SPARC backend will output code which tells the optimizer
+ The new SPARC back end will output code which tells the optimizer
exactly what is going on in each instruction, and also generate
a temporary for the sake of common subexpression detection:
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfg.html,v
retrieving revision 1.18
@@ -285,7 +285,7 @@ with external scope and some infrastruct
on a state variable which indicates we've started the lowering process.
For the actual lowering process, we want to avoid twiddling the existing
-backends as much as possible. If I recall, the general idea Richard and
+back ends as much as possible. If I recall, the general idea Richard and
I came up with was:
For each insn:
@@ -410,11 +410,11 @@ the compiler can now predict branches us
infrequent. It also allows to handle and specially predict constructs
such as return of (negative) constants, out of range code and, exception
handling where the front end knows that those are infrequent, but the
-backend has no information about it.</p>
+back end has no information about it.</p>
<p>We can also use it to preserve more information about high-level
loops. For instance loop a with continue statement looks like two
-nested loops to the backend, but the optimizer may be able to estimate
+nested loops to the back end, but the optimizer may be able to estimate
that the internal (continue) loop is not that frequent.</p>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cli.html,v
retrieving revision 1.22
@@ -21,7 +21,7 @@
<dl>
<dt>2009-07</dt>
-<dd><p>Update CLI backend to GCC 4.4, TAG added</p></dd>
+<dd><p>Update CLI back end to GCC 4.4, TAG added</p></dd>
</dl>
<dl>
@@ -33,7 +33,7 @@
<dl>
<dt>2009-04</dt>
-<dd><p>Update CLI backend to GCC 4.3, TAG added</p></dd>
+<dd><p>Update CLI back end to GCC 4.3, TAG added</p></dd>
</dl>
<dl>
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/documentation.html,v
retrieving revision 1.5
@@ -21,7 +21,7 @@ technical writing skills.</p>
<li><a href="#internals_and_porting">Better documentation of how GCC
works and how to port it</a></li>
- <li><a href="#RTL">Fully document the backend intermediate language
+ <li><a href="#RTL">Fully document the back end intermediate language
data structures</a></li>
<li><a href="#improve_manual_index">Improve the indexing
@@ -168,7 +168,7 @@ specified in the formal definition of th
</ol>
-<h2><a name="RTL">Fully document the backend intermediate
+<h2><a name="RTL">Fully document the back end intermediate
language data structures</a></h2>
<p>Document every RTX code and accessor macro, every insn name, every