This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[wwwdocs]: Patch for wwwdocs
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>
- Date: Fri, 28 Oct 2005 14:17:27 -0400
- Subject: [wwwdocs]: Patch for wwwdocs
I transformd the cvs session into an SVN one, and replaced the cvs docs
so they only talk about wwwdocs.
Other than that, it's just replacement of cvs info with equivalent svn
info.
Okay?
? .svn.html.swp
Index: contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.65
diff -u -p -r1.65 contribute.html
--- contribute.html 23 Oct 2005 19:57:40 -0000 1.65
+++ contribute.html 28 Oct 2005 18:13:15 -0000
@@ -69,7 +69,7 @@ well as requirements on code formatting.
<p>Submissions which do not conform to the standards will be returned
with a request to address any such problems.</p>
-<!-- also referenced from cvswrite.html -->
+<!-- also referenced from svnwrite.html -->
<h2><a name="testing">Testing Patches</a></h2>
<p>All patches must be thoroughly tested. We encourage you to test
@@ -206,7 +206,7 @@ be plaintext rather than part of the pat
ChangeLog changes rapidly and a patch to the ChangeLog would probably
no longer apply by the time your patch is reviewed.
If your change fixes a PR, put text in the ChangeLog entry mentioning
-the PR. The <code>cvs commit</code> machinery understands how to
+the PR. The <code>svn commit</code> machinery understands how to
extract this information and automatically append the commit log to
the PR. In order to be recognized, the text must fit a particular
form. It must start with "PR", and then must include the category
@@ -223,13 +223,15 @@ of your testing.
<dt>The patch itself</dt>
<dd>
-If you are accessing the <a href="cvs.html">CVS repository</a> at
-gcc.gnu.org, use "<code>cvs update; cvs diff -c3p</code>";
-else, use "<code>diff -c3p OLD NEW</code>" or
-"<code>diff -up OLD NEW</code>". If your version of diff
-does not support these options, then get the latest version of GNU
-diff. Patches against current development (mainline CVS) are
-preferred to patches against releases, unless your patch is intended
+If you are accessing the <a href="svn.html">SVN repository</a> at
+gcc.gnu.org, please configure your svn to use GNU diff
+and generate patches using the "<code>-up</code>" or
+"<code>-c3p</code>" options.
+See <a href="http://gcc.gnu.org/wiki/SvnSetup";>SVN setup instructions</a>
+for more details.
+If your version of diff does not support these options, then get the
+latest version of GNU diff. Patches against current development (SVN trunk)
+are preferred to patches against releases, unless your patch is intended
as a candidate for the release branch.
</dd>
@@ -267,9 +269,9 @@ acceptable, as long as the ChangeLog is
<p>When you have all these pieces, bundle them up in a mail message and
send it to <a href="lists.html">the appropriate mailing list(s)</a>.
(Patches will go to one or more lists depending on what you are
-changing.) For further information on the GCC CVS repository, see
-the <a href="cvs.html">Anonymous read-only CVS access</a> and <a
-href="cvswrite.html">Read-write CVS access</a> pages.</p>
+changing.) For further information on the GCC SVN repository, see
+the <a href="svn.html">Anonymous read-only SVN access</a> and <a
+href="svnwrite.html">Read-write SVN access</a> pages.</p>
<p>If you do not receive a response to a patch that you have submitted
within two weeks or so, it may be a good idea to chase it by sending a
@@ -279,7 +281,7 @@ URL of the entry in the mailing list arc
<p>Everything listed here still applies if you can check in the patch
without further approval under the <a
-href="cvswrite.html#policies">GCC write access policies</a>, except
+href="svnwrite.html#policies">GCC write access policies</a>, except
that ChangeLog entries may be included as part of the patch since
no-one else will need to apply it to the tree later and diffs representing
totally new files may be omitted (especially if large) since they can be
Index: cvs.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v
retrieving revision 1.200
diff -u -p -r1.200 cvs.html
--- cvs.html 29 Aug 2005 16:13:51 -0000 1.200
+++ cvs.html 28 Oct 2005 18:13:15 -0000
@@ -17,8 +17,8 @@
open development environment, we are making our CVS source repository
available read-only to the public at large.</p>
-<p>That way you can pick up any version (including releases) of GCC that
-is in our repository or our <a href="#wwwdocs">web pages</a>.</p>
+<p>That way you can pick up any version (including releases)
+our <a href="#wwwdocs">web pages</a>.</p>
<p>In addition, you can browse our CVS history online at</p>
@@ -46,468 +46,13 @@ and SSH installed, you can check out the
Alternately add
<code>-d :ext:anoncvs@savannah.gnu.org:/cvsroot/gcc</code>
immediately after <code>cvs</code> in the commands below.</li>
- <li>The command <code>cvs -qz9 checkout -P gcc wwwdocs</code>,
- will check out both modules in our CVS repository.
- Module <code>gcc</code> is the compiler source while module
- <code>wwwdocs</code> contains the sources for our web pages.</li>
+ <li>The command <code>cvs -qz9 checkout -P wwwdocs</code>,
+ will check out the web documentation in our CVS repository.</li>
</ol>
<p>In case of problems with the repository at savannah.gnu.org please
contact savannah-hackers@gnu.org.</p>
-
-<h3><a name="generated_files"></a>Generated files</h3>
-
-<p>Our CVS source tree contains a number of files that are generated
-from other source files by build tools such as Bison, Autoconf, and
-Gperf. Bison is now required when using CVS to access our sources,
-but all other generated files are included in the source tree so that
-GCC can be built without these build tools. The CVS checkout and
-update operations do not insure that the timestamps of generated files
-are later than those of the files they are generated from. The script
-<code>contrib/gcc_update</code> updates the timestamps for all these
-generated files. See the comments in that script for instructions on
-running it.</p>
-
-<p>GCC's build system (in particular Make) uses file timestamps to
-determine if a generated file needs to be updated by running a particular
-build tool. Because of this, GCC's build system may believe that
-a generated file needs regenerating even though its source has not
-changed, and require a particular build tool to rebuild that generated
-file. If the appropriate build tool is installed on your system, then
-this will not be a problem. If you do not intend to make changes to
-the source, you can avoid installing these build tools by running
-<code>contrib/gcc_update</code>.</p>
-
-<p>There has been some discussion of removing these generated files
-from GCC's CVS source tree (there is no discussion of removing them
-from the released source tarballs). If that happens then
-building GCC from the CVS source tree would require installing
-the above mentioned build tools. Installing these build tools is not
-particularly difficult, but can be time consuming especially if you
-only occasionally install GCC on a particular system.</p>
-
-<p>The build tools that GCC uses are all available from the GNU
-Project (see <a href="http://www.gnu.org";>http://www.gnu.org</a>),
-are often already available on many systems, and can often be found
-already built for some systems. A partial list of these build tools
-is: Autoconf, Bison, Xgettext, Automake, and Gperf.</p>
-
-<h3>Conflicts when using <code>cvs update</code></h3>
-
-<p>It is not uncommon to get CVS conflict messages for some generated files
-when updating your local sources from the CVS repository. Typically such
-conflicts occur with autoconf generated files.</p>
-
-<p>As long as you haven't been making modifications to the generated files
-or the generator files, it is safe to delete the offending file, then run
-<code>cvs update</code> again to get a new copy.</p>
-
-
-<h2>CVS tags, branches and checkouts</h2>
-
-<p> You can check out the latest version of the GCC <em>x</em>.<em>y</em>
-release branch with the following command:</p>
-
-<blockquote><p>
-<code>cvs -z 9 co -P -rgcc-<em>x</em>_<em>y</em>-branch gcc</code>
-</p></blockquote>
-
-<p>By changing the <code>-r</code> argument above you can check out
-particular releases or snapshots or the latest snapshot. </p>
-
-<h3>Release and snapshot branches</h3>
-
-<p>For recent releases, the CVS tag for GCC <i>X</i>.<i>Y</i>.<i>Z</i> is
-of the form "gcc_<i>X</i>_<i>Y</i>_<i>Z</i>_release"; the following list
-therefore provides only some representative examples.</p>
-
-<p>The CVS branch for GCC releases in the <i>X</i>.<i>Y</i> series is
-generally of the form "gcc-<i>X</i>_<i>Y</i>-branch".</p>
-
-<ul>
- <li>gcc_ss_<i>yyyymmdd</i></li>
- <li>gcc_3_4_3_release</li>
- <li>gcc_3_4_2_release</li>
- <li>gcc_3_4_1_release</li>
- <li>gcc_3_4_0_release</li>
- <li>gcc-3_4-branch</li>
- <li>egcs_1_1_2_release</li>
- <li>egcs_1_1_1_release</li>
- <li>egcs_1_1_release</li>
- <li>egcs_1_1_branch</li>
- <li>egcs_1_0_3_release</li>
- <li>egcs_1_0_2_release</li>
- <li>egcs_1_0_1_release</li>
- <li>egcs_1_0_release</li>
- <li>egcs_ss_<i>yyyymmdd</i> For snapshots prior to 19990913</li>
-</ul>
-
-<h3><a name="devbranches">Active Development Branches</a></h3>
-
-<h4>General Infrastructure</h4>
-
-<dl>
-
- <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
- <dd>This branch is for the development of profiling heuristics
- and profile based optimizations for trees, such as profile driven inline
- heuristics. Another goal of this branch is to demonstrate that maintaining
- the CFG and profile information over expanding from GIMPLE trees to RTL
- is feasible and can bring considerable performance improvements.</dd>
-
- <dt>struct-reorg-branch</dt>
- <dd>This branch is for the development of structure reorganization
- optimizations, including field reordering, structure splitting for
- trees. These optimizations are profile information driven. This is
- a subbranch of tree-profiling. This branch is being maintained by
- Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings,
- Mostafa Hagog.</dd>
-
- <dt>autovect-branch</dt>
- <dd>This branch is the successor to the lno-branch. The purpose of this
- branch is tree-level <a href="projects/tree-ssa/vectorization.html">
- autovectorization</a> work, and related work that the autovectorizer
- could use or benefit from (like data-dependence analysis,
- <a href="projects/tree-ssa/lno.html">loop nest optimizations</a>).</dd>
-
- <dt><a href="projects/cfg.html">rtlopt-branch</a></dt>
- <dd>This branch is the successor to the cfg-branch, with the exception
- that it is based on GCC pre-3.4. The purpose of the branch is to develop
- and test infrastructure for CFG based code improving transformations on
- RTL.</dd>
-
- <dt>killloop-branch</dt>
- <dd>The missing optimizations and optimization improvements necessary
- for removing the old loop optimizer are developed on this branch. Patches
- for this branch should be marked with the tag <code>[killloop]</code>
- in the subject line, and CC'ed to
- <a href="mailto:dvorakz@suse.cz";>Zdenek Dvorak</a>.</dd>
-
- <dt>new-regalloc-branch</dt>
- <dd>Daniel Berlin and Michael Matz are working on an implementation
- of a graph-coloring register allocator on this branch. It is known to
- bootstrap under x86-linux-gnu and ppc-linux-gnu.</dd>
-
- <dt>structure-aliasing-branch</dt>
- <dd>This branch contains improvements to the tree optimizers ability
- to do pointer-to-structure aliasing analysis and optimization.
- This involves some significant rework of the way
- our memory information is represented in the tree-ssa form.
- The branch is maintained by Daniel Berlin.
- Patches and discussion related to the branch should be marked
- with the tag <code>[sa]</code> in the subject line. The usual
- contribution and testing rules apply. Patches should be CC'd
- to Daniel Berlin for final approval.</dd>
-
- <dt>gomp-20050608-branch</dt>
- <dd>This branch is used by the <a href="projects/gomp/">GOMP
- project</a> to implement <a
- href="http://www.openmp.org/drupal/";>OpenMP</a> support in GCC.
- Patches and discussions regarding the design and implementation
- of GOMP should go to the main GCC development lists. Messages
- should be marked with <code>[gomp]</code> in the subject line.
- The usual contribution and testing rules apply. The branch is
- maintained by Diego Novillo and Sebastian Pop. Patches should
- be approved by the respective maintainers.</dd>
-
- <dt>ssaupdate-branch</dt>
- <dd>This branch serves to clean up and improve utilities for the SSA
- form updating, as well as for related changes of the SSA form
- representation. This branch is supposed to be short-lived and should
- be merged to mainline as soon as possible. Patches and discussions
- related to the branch should be marked with the tag
- <code>[ssaupdate]</code> in the subject line. The patches for this
- branch do not require approval, but they should be sent to gcc-patches
- list and the usual testing rules apply.</dd>
-
- <dt><a href="projects/cfo.html">cfo-branch</a></dt>
- <dd>The goal of this branch is to add a new extension for improving
- the code size optimization of GCC with code factoring methods (code
- motion and merging algorithms). Messages should be marked with
- <code>[cfo]</code> in the subject line. The usual contribution and
- testing rules apply.</dd>
-
- <dt>dfp-branch</dt>
-
- <dd>This branch is to develop the C extension for decimal floating
- point arithmetic (<a
- href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1107.htm";>ISO/IEC
- WG14 N1107</a>). The branch is maintained by Ben Elliston <<a
- href="mailto:bje@au.ibm.com";>bje@au.ibm.com</a>> and will be
- routinely merged with mainline. Patches should be marked with the
- tag <code>[dfp]</code> in the subject line.</dd>
-
- <dt>reload-branch</dt>
- <dd>This branch contains a version of reload in which the tracking
- of reload register lifetimes and the inheritance code has been
- rewritten in an attempt to make it more maintainable.</dd>
-
- <dt>improved-aliasing-branch</dt>
- <dd>This branch contains improvements to the tree-based aliasing
- infrastructure. The branch is maintained by Daniel Berlin <<a
- href="mailto:dberlin@dberlin.org";>dberlin@dberlin.org</a>> and
- Diego Novillo <<a href="mailto:dnovillo@redhat.com";>
- dnovillo@redhat.com</a>> and will be routinely merged with
- mainline. Patches should be marked with the tag
- <code>[improved-aliasing]</code> in the subject line.</dd>
-
-</dl>
-
-<h4>Architecture-specific</h4>
-
-<dl>
-
- <dt>csl-arm-branch</dt>
- <dd>CodeSourcery branch for developing ARM back end improvements.
- The branch is maintained by CodeSourcery personnel. Patches should
- be marked with the tag <code>[csl-arm-branch]</code> in the subject
- line.</dd>
-
- <dt>csl-sol210-3_4-branch</dt>
- <dd>CodeSourcery branch for developing Solaris 2.10 AMD64 support
- for GCC 3.4. This branch is maintained by CodeSourcery personnel.
- Patches should be marked with the tag
- <code>[csl-sol210-branch]</code> in the subject line.</dd>
-
- <dt>hammer-3_3-branch</dt>
- <dd>The goal of this branch is to have a stable compiler based on GCC 3.3
- with improved performance for AMD's 64-bit Hammer CPUs. The branch is
- maintained by Jan Hubicka <<a href="mailto:jh@suse.cz";>jh@suse.cz</a>>
- and Andreas Jaeger <<a href="mailto:aj@suse.de";>aj@suse.de</a>>.
- Patches added on this branch might not be appropriate for the GCC 3.3
- branch due to our policies concerning release branches. All patches
- will be added to mainline CVS (for 3.4). The branch is regularly
- merged with the GCC 3.3 branch.</dd>
-
- <dt>gcc-3_4-e500-branch</dt>
- <dd>This branch is for stabilization of the powerpc-*spe
- architecture, and for adding support for the 8548 chip (e500 v2). This
- branch is maintained by Aldy Hernandez. Patches should be marked with the
- tag <code>[3.4-e500]</code> in the subject line. ChangeLog entries should
- go in ChangeLog.e500.</dd>
-
- <dt>ia64-fp-model-branch</dt>
- <dd>This branch is a short-lived development branch with the goal of
- implementing the improvements and features discussed at the <a href=
- "http://gcc.gnu.org/wiki/ia64%20floating%20point";>ia64 floating point</a>
- page on the <a href="http://gcc.gnu.org/wiki/";>GCC wiki</a>. It is
- maintained by Zack Weinberg <<a
- href="mailto:zack@codesourcery.com";>zack@codesourcery.com</a>>.
- Patches should be marked with the tag <code>[ia64-fp-model]</code>
- in the subject line.</dd>
-
-</dl>
-
-<h4>Language-specific</h4>
-
-<dl>
-
- <dt><a href="projects/cxx-reflection/">cxx-reflection-branch</a></dt>
- <dd>Part of the work on providing support for compile time reflection
- in C++ is done in this branch. This branch is maintained by Gabriel
- Dos Reis <<a href="mailto:gdr@integrable-solutions.net";>gdr@integrable-solutions.net</a>>.</dd>
-
- <dt>objc-improvements-branch</dt>
- <dd>This branch was originally used to merge Objective-C bug fixes and
- enhancements from Apple Computer into the FSF tree; this has now been
- completed. Presently, the purpose of the branch is to implement the
- Objective-C++ language in the FSF GCC source tree. The message thread
- starting <a href="http://gcc.gnu.org/ml/gcc/2003-07/msg00535.html";>here</a>
- describes this at more length. This branch is being maintained by Zem
- Laski <<a href="mailto:zlaski@apple.com";>zlaski@apple.com</a>>.</dd>
-
- <dt>libada-gnattools-branch</dt>
- <dd>This is the spiritual successor to the libada branch. This branch
- exists to solve
- <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911";>bug 5911</a>
- and others, by breaking out the Ada runtime into a libada directory and
- the Ada tools into a gnattools directory. Current work is devoted to
- cleaning up the configure and make machinery, and separating it as much
- as possible from the GCC build machinery. Nathanael Nerode
- <<a href="mailto:neroden@gcc.gnu.org";>neroden@gcc.gnu.org</a>>
- is maintaining this branch.</dd>
-
- <dt>gcjx-branch</dt>
- <dd>This branch is used for development of gcjx, a rewrite of the
- front end for the Java programming language. Patches should be
- marked with the tag <code>[gcjx]</code> and should be sent to the
- java-patches list. Tom Tromey <<a
- href="mailto:tromey@redhat.com";>tromey@redhat.com</a>> is
- maintaining this branch. </dd>
-
- <dt>libstdcxx_so_7-branch</dt>
- <dd>This is a branch for experimental work on the C++ Runtime Library
- (libstdc++-v3) beyond the current version 6 library ABI. Paolo Carlini
- <<a href="mailto:pcarlini@suse.de";>pcarlini@suse.de</a>>
- and Benjamin Kosnik
- <<a href="mailto:bkoz@redhat.com";>bkoz@redhat.com</a>> are
- maintaining this branch.</dd>
-
-</dl>
-
-<h3><a name="distrobranches">Distribution Branches</a></h3>
-
-<p>These branches are maintained by organizations distributing GCC.
-No changes should be made to those branches without the explicit
-permission of the distributing organization. The branch name should
-be prefixed with the initials of the distributing organization.</p>
-
-<dl>
- <dt>apple-local-200502-branch</dt>
- <dd>This branch is for various improvements in use at Apple and to
- coordinate work with others. This branch is maintained by the folks
- at Apple. Previous branch was apple-ppc-branch.</dd>
-
- <dt>csl-3_3_1-branch</dt>
- <dd>CodeSourcery release based on GCC 3.3.1.</dd>
-
- <dt>csl-arm-2004-q3-branch</dt>
- <dd>CodeSourcery ARM 2004-Q3 release</dd>
-
- <dt>csl-3_4-linux-branch</dt>
- <dd>CodeSourcery GNU/Linux compilers based on GCC 3.4.x.</dd>
-
- <dt>csl-3_4_3-linux-branch</dt>
- <dd>CodeSourcery GNU/Linux compilers based on GCC 3.4.3, with
- patches from the csl-arm-branch.</dd>
-
- <dt>csl-gxxpro-3_4-branch</dt>
- <dd>CodeSourcery's Sourcery G++ compilers, based on GCC 3.4.x.</dd>
-
- <dt>gcc-3_2-rhl8-branch</dt>
- <dd>Red Hat GNU/Linux compilers based on GCC 3.2.x.</dd>
-
- <dt>gcc-3_4-rhl-branch</dt>
- <dd>Red Hat GNU/Linux compilers based on GCC 3.4.x.</dd>
-
- <dt>gcc-4_0-rhl-branch</dt>
- <dd>Red Hat GNU/Linux compilers based on GCC 4.0.x.</dd>
-
-</dl>
-
-<h3><a name="olddevbranches">Inactive Development Branches</a></h3>
-
-<dl>
-
- <dt>edge-vector-branch <br />
- cp-parser-branch<br />
- cp-parser-branch-2<br />
- pch-branch<br />
- gcc-3_4-basic-improvements-branch<br />
- mips-3_4-rewrite-branch<br />
- dfa-branch<br />
- gcj-abi-2-dev-branch<br />
- <a href="projects/tree-ssa/">tree-ssa-20020619-branch</a><br />
- csl-sol210-branch (Solaris 2.10 AMD64 support)</dt>
- <dd>These branches have been merged into the mainline.</dd>
-
- <dt>apple-ppc-branch</dt>
- <dd>This branch was for various improvements in use at Apple and to
- coordinate work with others. This branch was maintained by the folks
- at Apple. It has been superseded by apple-local-200502-branch.</dd>
-
- <dt><a href="projects/strees/index.html">stree-branch</a></dt>
- <dd>This branch was for improving compilation speed and reducing memory
- use by representing declarations as small flat data structures whenever
- possible, lazily expanding them into full trees when necessary. This
- branch was being maintained by Matt Austern, Robert Bowdidge, Geoff
- Keating, and Mike Stump. Patches were marked with the tag
- <code>[stree]</code> in the subject line.</dd>
-
- <dt>compile-server-branch</dt>
- <dd>This branch was aimed at improving compile speed by caching work
- done between compilations. The work saved is mainly related to header
- file processing. This branch was maintained by Mike Stump and Per Bothner.
- Patches were marked with the tag <code>[cs]</code> in the subject
- line.</dd>
-
- <dt>libobjc-branch</dt>
- <dd>The branch is aimed to clean up libobjc and make it run on Darwin.
- Patches should be marked with the tag <code>[libobjc-branch]</code>
- in the subject line. Patches can be approved by Andrew Pinski
- <<a href="mailto:pinskia@gcc.gnu.org";>pinskia@gcc.gnu.org</a>>
- or Nicola Pero
- <<a href="mailto:n.pero@mi.flashnet.it";>n.pero@mi.flashnet.it</a>>.</dd>
-
- <dt>cfg-branch</dt>
- <dd>This branch was created to develop and test infrastructure
- for easier writing of new RTL based optimizations. The branch
- was based on GCC pre-3.3 and has been partially merged into the
- mainline for GCC 3.4. It is now closed, and work continues on
- the rtlopt-branch.</dd>
-
- <dt>tree-ssa-cfg-branch</dt>
- <dd>This branch has been merged into the tree-ssa-20020619-branch.</dd>
-
- <dt><a href="projects/ast-optimizer.html">ast-optimizer-branch</a></dt>
- <dd>The purpose of this branch was to improve GCC's tree based
- optimizations. The patches of this branch have been moved to the
- tree-ssa-20020619-branch.</dd>
-
- <dt>faster-compiler-branch</dt>
- <dd>This was a temporary branch for compiler speedups for GCC 3.4.
- See <a href="http://gcc.gnu.org/ml/gcc/2002-08/msg00498.html";>this
- thread</a> for discussion of possible work still to be done in this
- area. The branch is unmaintained at present.</dd>
-
- <dt>gcc-3_3-e500-branch</dt>
- <dd>This branch was for backporting the PowerPC/E500 back end to GCC 3.3.
- See <a href="http://gcc.gnu.org/ml/gcc/2003-04/msg00733.html";>this
- message</a> for details.</dd>
-
- <dt>gomp-01-branch</dt>
- <dt>gomp-branch</dt>
- <dd>These two branches were initial attempts to implement
- OpenMP support in GCC. They were never properly maintained and
- have now been superceded by <code>gomp-20050608-branch</code>.</dd>
-
- <dt><a href="projects/tree-ssa/lno.html">lno-branch</a></dt>
- <dd>A sub-branch of tree-ssa that aims at implementing a loop
- nest optimizer at the tree level. Was largely merged into mainline,
- and is currently unmaintained.
- This work now continues on the autovect-branch.</dd>
-
- <dt>java-gui-branch</dt>
- <dd>This was a temporary branch for development of java GUI libraries
- (AWT and Swing) in the libjava directory. It has been superseded
- by java-gui-20050128-branch</dd>
-
- <dt>java-gui-20050128-branch</dt>
- <dd>This was a temporary branch for development of java GUI libraries
- (AWT and Swing) in the libjava directory. It has been merged into
- mainline.</dd>
-
- <dt>csl-hpux-branch</dt>
- <dd>This branch was for changes to G++ to be more compatible with
- ABI bugs in the HP-UX C++ compiler. It is now unmaintained.</dd>
-
- <dt>tree-cleanup-branch</dt>
- <dd>This branch contained improvements and reorganization to the
- tree optimizers that were not ready in time for GCC 4.0. The
- goal was to cleanup the tree optimizers and improve the sequencing
- of the passes. It has now been merged into mainline for the
- 4.1 release.</dd>
-
- <dt>bje-unsw-branch</dt>
- <dd>This branch was dedicated to some research work by Ben Elliston
- at the University of New South Wales (UNSW) on transformation
- phase ordering. It will never merge with mainline, although a
- selection of patches may be submitted over time.</dd>
-
- <dt>gcc-3_3-rhl-branch</dt>
- <dd>This branch used to hold Red Hat GNU/Linux compilers based on
- GCC 3.3.x.</dd>
-</dl>
-
-<h2><a name="wwwdocs">Web pages</a></h2>
-
-<p>The web pages for the GCC project are also in the CVS repository
-and you can check them out, submit patches, etc just like you do for
-the compiler itself.</p>
-
-<p>Use <code>cvs co -P wwwdocs</code> to check out the web pages.</p>
-
<p>Patches should be marked with the tag [wwwdocs] in the subject line.</p>
<h2><a name="system">The host system</a></h2>
Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.523
diff -u -p -r1.523 index.html
--- index.html 10 Oct 2005 17:37:42 -0000 1.523
+++ index.html 28 Oct 2005 18:13:15 -0000
@@ -21,7 +21,7 @@ of native and cross targets (including G
to <a href="contribute.html">contribute changes</a> and
<a href="testing/">help testing</a> GCC.
Our sources are readily and freely available
-via <a href="cvs.html">CVS</a> and <a href="snapshots.html">weekly
+via <a href="svn.html">SVN</a> and <a href="snapshots.html">weekly
snapshots</a>.</p>
<p>Major decisions about GCC are made by the <a href="steering.html">
@@ -90,6 +90,12 @@ mission statement</a>.</p>
<dl>
+<dt><b>October 26, 2005</b></dt>
+<dd>
+GCC has moved from CVS to <a href="svn.html">SVN</a>
+for revision control.
+</dd>
+
<dt><b>September 28, 2005</b></dt>
<dd>
<a href="gcc-4.0/">GCC 4.0.2</a> has been released.
Index: lists.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.93
diff -u -p -r1.93 lists.html
--- lists.html 13 Feb 2005 12:43:53 -0000 1.93
+++ lists.html 28 Oct 2005 18:13:15 -0000
@@ -93,11 +93,11 @@ as well as in
<li><b><a href="http://gcc.gnu.org/ml/gcc-cvs/";>gcc-cvs</a></b>
is a read-only, relatively high volume list which tracks checkins to the
- GCC CVS repository.</li>
+ GCC SVN repository.</li>
<li><b><a href="http://gcc.gnu.org/ml/libstdc++-cvs/";>libstdc++-cvs</a></b>
is a read-only, relatively low volume list which tracks checkins to
- the libstdc++-v3 part of the GCC CVS repository. This is a subset
+ the libstdc++-v3 part of the GCC SVN repository. This is a subset
of the messages to <b>gcc-cvs</b>.</li>
<li><b><a href="http://gcc.gnu.org/ml/gcc-cvs-wwwdocs/";>gcc-cvs-wwwdocs</a></b>
Index: mirrors.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.167
diff -u -p -r1.167 mirrors.html
--- mirrors.html 26 Sep 2005 00:37:44 -0000 1.167
+++ mirrors.html 28 Oct 2005 18:13:15 -0000
@@ -65,8 +65,5 @@ Key fingerprint = 90AA 4704 69D3 965A 87
name of the server, the path to the GCC mirror and the country/city
where the mirror is located.</p>
-<p>If you want to mirror the whole GCC CVS repository, ask about
-<a href="cvsup.html">CVSup access</a>.</p>
-
</body>
</html>
Index: rsync.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/rsync.html,v
retrieving revision 1.11
diff -u -p -r1.11 rsync.html
--- rsync.html 13 Mar 2005 09:44:51 -0000 1.11
+++ rsync.html 28 Oct 2005 18:13:15 -0000
@@ -2,7 +2,7 @@
<head>
<meta name="description" content="Anonymous rsync read-only access to the GCC project." />
-<meta name="keywords" content="CVS, version control, GCC, source, public, repository, rsync" />
+<meta name="keywords" content="SVN, version control, GCC, source, public, repository, rsync" />
<title>GCC: Anonymous read-only rsync access</title>
</head>
@@ -10,17 +10,17 @@
<h1>GCC: Anonymous read-only rsync access</h1>
<p>In an ongoing effort to accelerate development of GCC and provide an
-open development environment, we are offering our CVS repository and
+open development environment, we are offering our SVN repository and
various other data through anonymous rsync access.</p>
-<p>That way you can make local copies of the GCC CVS repository to ease
+<p>That way you can make local copies of the GCC SVN repository to ease
the burden on the GCC main site, and browse the source locally using
-<code>cvs</code>.</p>
+<code>svn</code>.</p>
<h2>Using rsync</h2>
-<p>The GCC repository is available at <code>rsync://gcc.gnu.org/gcc-cvs</code>.
-The whole repository takes over 2.8G of disk space,
+<p>The GCC repository is available at <code>rsync://gcc.gnu.org/gcc-svn</code>.
+The whole repository takes over 7.8G of disk space,
which takes a substantial time to transfer.
Subsequent synchronizations will be much faster, though, as rsync uses
a smart algorithm to only transfer differences over the network.</p>
@@ -28,9 +28,7 @@ a smart algorithm to only transfer diffe
<p>Here is how you get a copy of the repository:</p>
<blockquote><pre>
rsync --archive --delete --compress \
- --exclude '#cvs.*' --exclude 'CVSROOT/config' \
- --exclude 'CVSROOT/history' --exclude 'CVSROOT/updatelog' \
- rsync://gcc.gnu.org/gcc-cvs gcc-cvs
+ rsync://gcc.gnu.org/gcc-svn gcc-svn
</pre></blockquote>
<p>The same command can be run periodically to synchronize your copy of
the repository.</p>
@@ -51,17 +49,8 @@ rsync rsync://gcc.gnu.org/
available.</p>
<h2>Using the local repository</h2>
-<p>Refer to <a href="cvs.html">CVS instructions</a> to check out your local
+<p>Refer to <a href="svn.html">SVN instructions</a> to check out your local
copy of the repository.</p>
-<p>If your new repository is local to the system where you'll check out
-a copy then you'll define <code>CVSROOT</code> in your environment to be
-the full pathname of its <code>gcc-cvs</code> directory. If it's on
-another system then you'll define <code>CVSROOT</code> to be
-<code>:ext:<i>user</i>@<i>host</i>:<i>path</i></code>.
-By default CVS will use <code>rsh</code> to access the remote repository,
-but you can use <code>ssh</code> instead by setting the environment
-variable <code>CVS_RSH</code> to <code>ssh</code>.</p>
-
</body>
</html>
Index: style.mhtml
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.82
diff -u -p -r1.82 style.mhtml
--- style.mhtml 10 Jul 2005 21:09:24 -0000 1.82
+++ style.mhtml 28 Oct 2005 18:13:15 -0000
@@ -219,10 +219,9 @@
</td></tr>
<tr><td <nav-body-style> >
<p>
- <a href="<get-var BACKPATH>cvs.html">CVS read access</a><br />
+ <a href="<get-var BACKPATH>svn.html">CVS read access</a><br />
<a href="<get-var BACKPATH>rsync.html">Rsync read access</a><br />
- <a href="<get-var BACKPATH>cvsup.html">CVSup mirrors</a><br />
- <a href="<get-var BACKPATH>cvswrite.html">CVS write access</a><br />
+ <a href="<get-var BACKPATH>svnwrite.html">CVS write access</a><br />
</p>
</td></tr>
</table></td></tr>
Index: svn.html
===================================================================
RCS file: svn.html
diff -N svn.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ svn.html 28 Oct 2005 18:13:15 -0000
@@ -0,0 +1,520 @@
+<html>
+
+<head>
+<meta name="description" content="Anonymous read-only access to the GCC project SVN source repository." />
+<meta name="keywords" content="SVN, version control, GCC, source, public, repository" />
+<title>GCC: Anonymous read-only SVN access</title>
+</head>
+
+<!-- GCC maintainers, please do not hesitate to update/contribute entries
+ concerning branches you maintain! 2005-08-29, Gerald.
+-->
+
+<body>
+<h1>GCC: Anonymous read-only SVN access</h1>
+
+<p>In an ongoing effort to accelerate development of GCC and provide an
+open development environment, we are making our SVN source repository
+available read-only to the public at large.</p>
+
+<p>That way you can pick up any version (including releases) of GCC that
+is in our repository or our <a href="#wwwdocs">web pages</a>.</p>
+
+<p> Web pages are still stored in CVS, and thus, should be accessed
+using the directions for <a href="cvs.html">CVS<a></p>
+
+<p>In addition, you can browse our SVN history online at</p>
+
+<ul>
+<!-- Commented out till savannah gets back to us
+ <li><a href="http://savannah.gnu.org/cgi-bin/viewcvs/gcc/";>savannah.gnu.org</a>
+ using viewcvs, or</li> -->
+ <li><a href="http://gcc.gnu.org/viewcvs/";>gcc.gnu.org</a>
+ using ViewCVS.</li>
+</ul>
+
+
+<h2>Using the SVN repository</h2>
+
+<p><b>In January 2004, these instructions were modified to reflect security
+changes implemented after an attack on the Free Software Foundation's
+site.</b></p>
+
+<p>Assuming you have both <a href="http://subversion.tigris.org/";>SVN</a>
+and SSH installed, you can check out the GCC sources as follows:</p>
+
+<ol type="i">
+ <li>The command <code>svn -q checkout svn://gcc.gnu.org/svn/gcc gcc</code>,
+ will retrieve the compiler sources</li>
+</ol>
+
+<p>In case of problems with the repository at savannah.gnu.org please
+contact savannah-hackers@gnu.org.</p>
+
+
+<h3><a name="generated_files"></a>Generated files</h3>
+
+<p>Our SVN source tree contains a number of files that are generated
+from other source files by build tools such as Bison, Autoconf, and
+Gperf. Bison is now required when using SVN to access our sources,
+but all other generated files are included in the source tree so that
+GCC can be built without these build tools. The SVN checkout and
+update operations do not insure that the timestamps of generated files
+are later than those of the files they are generated from. The script
+<code>contrib/gcc_update</code> updates the timestamps for all these
+generated files. See the comments in that script for instructions on
+running it.</p>
+
+<p>GCC's build system (in particular Make) uses file timestamps to
+determine if a generated file needs to be updated by running a particular
+build tool. Because of this, GCC's build system may believe that
+a generated file needs regenerating even though its source has not
+changed, and require a particular build tool to rebuild that generated
+file. If the appropriate build tool is installed on your system, then
+this will not be a problem. If you do not intend to make changes to
+the source, you can avoid installing these build tools by running
+<code>contrib/gcc_update</code>.</p>
+
+<p>There has been some discussion of removing these generated files
+from GCC's SVN source tree (there is no discussion of removing them
+from the released source tarballs). If that happens then
+building GCC from the SVN source tree would require installing
+the above mentioned build tools. Installing these build tools is not
+particularly difficult, but can be time consuming especially if you
+only occasionally install GCC on a particular system.</p>
+
+<p>The build tools that GCC uses are all available from the GNU
+Project (see <a href="http://www.gnu.org";>http://www.gnu.org</a>),
+are often already available on many systems, and can often be found
+already built for some systems. A partial list of these build tools
+is: Autoconf, Bison, Xgettext, Automake, and Gperf.</p>
+
+<h3>Conflicts when using <code>svn update</code></h3>
+
+<p>It is not uncommon to get svn conflict messages for some generated files
+when updating your local sources from the SVN repository. Typically such
+conflicts occur with autoconf generated files.</p>
+
+<p>As long as you haven't been making modifications to the generated files
+or the generator files, it is safe to delete the offending file, then run
+<code>svn update</code> again to get a new copy.</p>
+
+
+<h2>svn tags, branches and checkouts</h2>
+
+<p> You can check out the latest version of the GCC <em>x</em>.<em>y</em>
+release branch with the following command:</p>
+
+<blockquote><p>
+<code>SVN co svn://gcc.gnu.org/svn/gcc/branches/gcc-<em>x</em>_<em>y</em>-branch gcc</code>
+</p></blockquote>
+
+<p>By changing the <code>URL</code> argument above you can check out
+particular releases or snapshots or the latest snapshot. </p>
+
+<h3>Release and snapshot branches</h3>
+
+<p>For recent releases, the SVN tag for GCC <i>X</i>.<i>Y</i>.<i>Z</i> is
+of the form "gcc_<i>X</i>_<i>Y</i>_<i>Z</i>_release"; the following list
+therefore provides only some representative examples.</p>
+
+<p>The SVN branch for GCC releases in the <i>X</i>.<i>Y</i> series is
+generally of the form "gcc-<i>X</i>_<i>Y</i>-branch".</p>
+
+<ul>
+ <li>gcc_ss_<i>yyyymmdd</i></li>
+ <li>gcc_3_4_3_release</li>
+ <li>gcc_3_4_2_release</li>
+ <li>gcc_3_4_1_release</li>
+ <li>gcc_3_4_0_release</li>
+ <li>gcc-3_4-branch</li>
+ <li>egcs_1_1_2_release</li>
+ <li>egcs_1_1_1_release</li>
+ <li>egcs_1_1_release</li>
+ <li>egcs_1_1_branch</li>
+ <li>egcs_1_0_3_release</li>
+ <li>egcs_1_0_2_release</li>
+ <li>egcs_1_0_1_release</li>
+ <li>egcs_1_0_release</li>
+ <li>egcs_ss_<i>yyyymmdd</i> For snapshots prior to 19990913</li>
+</ul>
+
+<h3><a name="devbranches">Active Development Branches</a></h3>
+
+<h4>General Infrastructure</h4>
+
+<dl>
+
+ <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
+ <dd>This branch is for the development of profiling heuristics
+ and profile based optimizations for trees, such as profile driven inline
+ heuristics. Another goal of this branch is to demonstrate that maintaining
+ the CFG and profile information over expanding from GIMPLE trees to RTL
+ is feasible and can bring considerable performance improvements.</dd>
+
+ <dt>struct-reorg-branch</dt>
+ <dd>This branch is for the development of structure reorganization
+ optimizations, including field reordering, structure splitting for
+ trees. These optimizations are profile information driven. This is
+ a subbranch of tree-profiling. This branch is being maintained by
+ Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings,
+ Mostafa Hagog.</dd>
+
+ <dt>autovect-branch</dt>
+ <dd>This branch is the successor to the lno-branch. The purpose of this
+ branch is tree-level <a href="projects/tree-ssa/vectorization.html">
+ autovectorization</a> work, and related work that the autovectorizer
+ could use or benefit from (like data-dependence analysis,
+ <a href="projects/tree-ssa/lno.html">loop nest optimizations</a>).</dd>
+
+ <dt><a href="projects/cfg.html">rtlopt-branch</a></dt>
+ <dd>This branch is the successor to the cfg-branch, with the exception
+ that it is based on GCC pre-3.4. The purpose of the branch is to develop
+ and test infrastructure for CFG based code improving transformations on
+ RTL.</dd>
+
+ <dt>killloop-branch</dt>
+ <dd>The missing optimizations and optimization improvements necessary
+ for removing the old loop optimizer are developed on this branch. Patches
+ for this branch should be marked with the tag <code>[killloop]</code>
+ in the subject line, and CC'ed to
+ <a href="mailto:dvorakz@suse.cz";>Zdenek Dvorak</a>.</dd>
+
+ <dt>new-regalloc-branch</dt>
+ <dd>Daniel Berlin and Michael Matz are working on an implementation
+ of a graph-coloring register allocator on this branch. It is known to
+ bootstrap under x86-linux-gnu and ppc-linux-gnu.</dd>
+
+ <dt>structure-aliasing-branch</dt>
+ <dd>This branch contains improvements to the tree optimizers ability
+ to do pointer-to-structure aliasing analysis and optimization.
+ This involves some significant rework of the way
+ our memory information is represented in the tree-ssa form.
+ The branch is maintained by Daniel Berlin.
+ Patches and discussion related to the branch should be marked
+ with the tag <code>[sa]</code> in the subject line. The usual
+ contribution and testing rules apply. Patches should be CC'd
+ to Daniel Berlin for final approval.</dd>
+
+ <dt>gomp-20050608-branch</dt>
+ <dd>This branch is used by the <a href="projects/gomp/">GOMP
+ project</a> to implement <a
+ href="http://www.openmp.org/drupal/";>OpenMP</a> support in GCC.
+ Patches and discussions regarding the design and implementation
+ of GOMP should go to the main GCC development lists. Messages
+ should be marked with <code>[gomp]</code> in the subject line.
+ The usual contribution and testing rules apply. The branch is
+ maintained by Diego Novillo and Sebastian Pop. Patches should
+ be approved by the respective maintainers.</dd>
+
+ <dt>ssaupdate-branch</dt>
+ <dd>This branch serves to clean up and improve utilities for the SSA
+ form updating, as well as for related changes of the SSA form
+ representation. This branch is supposed to be short-lived and should
+ be merged to mainline as soon as possible. Patches and discussions
+ related to the branch should be marked with the tag
+ <code>[ssaupdate]</code> in the subject line. The patches for this
+ branch do not require approval, but they should be sent to gcc-patches
+ list and the usual testing rules apply.</dd>
+
+ <dt><a href="projects/cfo.html">cfo-branch</a></dt>
+ <dd>The goal of this branch is to add a new extension for improving
+ the code size optimization of GCC with code factoring methods (code
+ motion and merging algorithms). Messages should be marked with
+ <code>[cfo]</code> in the subject line. The usual contribution and
+ testing rules apply.</dd>
+
+ <dt>dfp-branch</dt>
+
+ <dd>This branch is to develop the C extension for decimal floating
+ point arithmetic (<a
+ href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1107.htm";>ISO/IEC
+ WG14 N1107</a>). The branch is maintained by Ben Elliston <<a
+ href="mailto:bje@au.ibm.com";>bje@au.ibm.com</a>> and will be
+ routinely merged with mainline. Patches should be marked with the
+ tag <code>[dfp]</code> in the subject line.</dd>
+
+ <dt>reload-branch</dt>
+ <dd>This branch contains a version of reload in which the tracking
+ of reload register lifetimes and the inheritance code has been
+ rewritten in an attempt to make it more maintainable.</dd>
+
+ <dt>improved-aliasing-branch</dt>
+ <dd>This branch contains improvements to the tree-based aliasing
+ infrastructure. The branch is maintained by Daniel Berlin <<a
+ href="mailto:dberlin@dberlin.org";>dberlin@dberlin.org</a>> and
+ Diego Novillo <<a href="mailto:dnovillo@redhat.com";>
+ dnovillo@redhat.com</a>> and will be routinely merged with
+ mainline. Patches should be marked with the tag
+ <code>[improved-aliasing]</code> in the subject line.</dd>
+
+</dl>
+
+<h4>Architecture-specific</h4>
+
+<dl>
+
+ <dt>csl-arm-branch</dt>
+ <dd>CodeSourcery branch for developing ARM back end improvements.
+ The branch is maintained by CodeSourcery personnel. Patches should
+ be marked with the tag <code>[csl-arm-branch]</code> in the subject
+ line.</dd>
+
+ <dt>csl-sol210-3_4-branch</dt>
+ <dd>CodeSourcery branch for developing Solaris 2.10 AMD64 support
+ for GCC 3.4. This branch is maintained by CodeSourcery personnel.
+ Patches should be marked with the tag
+ <code>[csl-sol210-branch]</code> in the subject line.</dd>
+
+ <dt>hammer-3_3-branch</dt>
+ <dd>The goal of this branch is to have a stable compiler based on GCC 3.3
+ with improved performance for AMD's 64-bit Hammer CPUs. The branch is
+ maintained by Jan Hubicka <<a href="mailto:jh@suse.cz";>jh@suse.cz</a>>
+ and Andreas Jaeger <<a href="mailto:aj@suse.de";>aj@suse.de</a>>.
+ Patches added on this branch might not be appropriate for the GCC 3.3
+ branch due to our policies concerning release branches. All patches
+ will be added to mainline SVN (for 3.4). The branch is regularly
+ merged with the GCC 3.3 branch.</dd>
+
+ <dt>gcc-3_4-e500-branch</dt>
+ <dd>This branch is for stabilization of the powerpc-*spe
+ architecture, and for adding support for the 8548 chip (e500 v2). This
+ branch is maintained by Aldy Hernandez. Patches should be marked with the
+ tag <code>[3.4-e500]</code> in the subject line. ChangeLog entries should
+ go in ChangeLog.e500.</dd>
+
+ <dt>ia64-fp-model-branch</dt>
+ <dd>This branch is a short-lived development branch with the goal of
+ implementing the improvements and features discussed at the <a href=
+ "http://gcc.gnu.org/wiki/ia64%20floating%20point";>ia64 floating point</a>
+ page on the <a href="http://gcc.gnu.org/wiki/";>GCC wiki</a>. It is
+ maintained by Zack Weinberg <<a
+ href="mailto:zack@codesourcery.com";>zack@codesourcery.com</a>>.
+ Patches should be marked with the tag <code>[ia64-fp-model]</code>
+ in the subject line.</dd>
+
+</dl>
+
+<h4>Language-specific</h4>
+
+<dl>
+
+ <dt><a href="projects/cxx-reflection/">cxx-reflection-branch</a></dt>
+ <dd>Part of the work on providing support for compile time reflection
+ in C++ is done in this branch. This branch is maintained by Gabriel
+ Dos Reis <<a href="mailto:gdr@integrable-solutions.net";>gdr@integrable-solutions.net</a>>.</dd>
+
+ <dt>objc-improvements-branch</dt>
+ <dd>This branch was originally used to merge Objective-C bug fixes and
+ enhancements from Apple Computer into the FSF tree; this has now been
+ completed. Presently, the purpose of the branch is to implement the
+ Objective-C++ language in the FSF GCC source tree. The message thread
+ starting <a href="http://gcc.gnu.org/ml/gcc/2003-07/msg00535.html";>here</a>
+ describes this at more length. This branch is being maintained by Zem
+ Laski <<a href="mailto:zlaski@apple.com";>zlaski@apple.com</a>>.</dd>
+
+ <dt>libada-gnattools-branch</dt>
+ <dd>This is the spiritual successor to the libada branch. This branch
+ exists to solve
+ <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911";>bug 5911</a>
+ and others, by breaking out the Ada runtime into a libada directory and
+ the Ada tools into a gnattools directory. Current work is devoted to
+ cleaning up the configure and make machinery, and separating it as much
+ as possible from the GCC build machinery. Nathanael Nerode
+ <<a href="mailto:neroden@gcc.gnu.org";>neroden@gcc.gnu.org</a>>
+ is maintaining this branch.</dd>
+
+ <dt>gcjx-branch</dt>
+ <dd>This branch is used for development of gcjx, a rewrite of the
+ front end for the Java programming language. Patches should be
+ marked with the tag <code>[gcjx]</code> and should be sent to the
+ java-patches list. Tom Tromey <<a
+ href="mailto:tromey@redhat.com";>tromey@redhat.com</a>> is
+ maintaining this branch. </dd>
+
+ <dt>libstdcxx_so_7-branch</dt>
+ <dd>This is a branch for experimental work on the C++ Runtime Library
+ (libstdc++-v3) beyond the current version 6 library ABI. Paolo Carlini
+ <<a href="mailto:pcarlini@suse.de";>pcarlini@suse.de</a>>
+ and Benjamin Kosnik
+ <<a href="mailto:bkoz@redhat.com";>bkoz@redhat.com</a>> are
+ maintaining this branch.</dd>
+
+</dl>
+
+<h3><a name="distrobranches">Distribution Branches</a></h3>
+
+<p>These branches are maintained by organizations distributing GCC.
+No changes should be made to those branches without the explicit
+permission of the distributing organization. The branch name should
+be prefixed with the initials of the distributing organization.</p>
+
+<dl>
+ <dt>apple-local-200502-branch</dt>
+ <dd>This branch is for various improvements in use at Apple and to
+ coordinate work with others. This branch is maintained by the folks
+ at Apple. Previous branch was apple-ppc-branch.</dd>
+
+ <dt>csl-3_3_1-branch</dt>
+ <dd>CodeSourcery release based on GCC 3.3.1.</dd>
+
+ <dt>csl-arm-2004-q3-branch</dt>
+ <dd>CodeSourcery ARM 2004-Q3 release</dd>
+
+ <dt>csl-3_4-linux-branch</dt>
+ <dd>CodeSourcery GNU/Linux compilers based on GCC 3.4.x.</dd>
+
+ <dt>csl-3_4_3-linux-branch</dt>
+ <dd>CodeSourcery GNU/Linux compilers based on GCC 3.4.3, with
+ patches from the csl-arm-branch.</dd>
+
+ <dt>csl-gxxpro-3_4-branch</dt>
+ <dd>CodeSourcery's Sourcery G++ compilers, based on GCC 3.4.x.</dd>
+
+ <dt>gcc-3_2-rhl8-branch</dt>
+ <dd>Red Hat GNU/Linux compilers based on GCC 3.2.x.</dd>
+
+ <dt>gcc-3_4-rhl-branch</dt>
+ <dd>Red Hat GNU/Linux compilers based on GCC 3.4.x.</dd>
+
+ <dt>gcc-4_0-rhl-branch</dt>
+ <dd>Red Hat GNU/Linux compilers based on GCC 4.0.x.</dd>
+
+</dl>
+
+<h3><a name="olddevbranches">Inactive Development Branches</a></h3>
+
+<dl>
+
+ <dt>edge-vector-branch <br />
+ cp-parser-branch<br />
+ cp-parser-branch-2<br />
+ pch-branch<br />
+ gcc-3_4-basic-improvements-branch<br />
+ mips-3_4-rewrite-branch<br />
+ dfa-branch<br />
+ gcj-abi-2-dev-branch<br />
+ <a href="projects/tree-ssa/">tree-ssa-20020619-branch</a><br />
+ csl-sol210-branch (Solaris 2.10 AMD64 support)</dt>
+ <dd>These branches have been merged into the mainline.</dd>
+
+ <dt>apple-ppc-branch</dt>
+ <dd>This branch was for various improvements in use at Apple and to
+ coordinate work with others. This branch was maintained by the folks
+ at Apple. It has been superseded by apple-local-200502-branch.</dd>
+
+ <dt><a href="projects/strees/index.html">stree-branch</a></dt>
+ <dd>This branch was for improving compilation speed and reducing memory
+ use by representing declarations as small flat data structures whenever
+ possible, lazily expanding them into full trees when necessary. This
+ branch was being maintained by Matt Austern, Robert Bowdidge, Geoff
+ Keating, and Mike Stump. Patches were marked with the tag
+ <code>[stree]</code> in the subject line.</dd>
+
+ <dt>compile-server-branch</dt>
+ <dd>This branch was aimed at improving compile speed by caching work
+ done between compilations. The work saved is mainly related to header
+ file processing. This branch was maintained by Mike Stump and Per Bothner.
+ Patches were marked with the tag <code>[cs]</code> in the subject
+ line.</dd>
+
+ <dt>libobjc-branch</dt>
+ <dd>The branch is aimed to clean up libobjc and make it run on Darwin.
+ Patches should be marked with the tag <code>[libobjc-branch]</code>
+ in the subject line. Patches can be approved by Andrew Pinski
+ <<a href="mailto:pinskia@gcc.gnu.org";>pinskia@gcc.gnu.org</a>>
+ or Nicola Pero
+ <<a href="mailto:n.pero@mi.flashnet.it";>n.pero@mi.flashnet.it</a>>.</dd>
+
+ <dt>cfg-branch</dt>
+ <dd>This branch was created to develop and test infrastructure
+ for easier writing of new RTL based optimizations. The branch
+ was based on GCC pre-3.3 and has been partially merged into the
+ mainline for GCC 3.4. It is now closed, and work continues on
+ the rtlopt-branch.</dd>
+
+ <dt>tree-ssa-cfg-branch</dt>
+ <dd>This branch has been merged into the tree-ssa-20020619-branch.</dd>
+
+ <dt><a href="projects/ast-optimizer.html">ast-optimizer-branch</a></dt>
+ <dd>The purpose of this branch was to improve GCC's tree based
+ optimizations. The patches of this branch have been moved to the
+ tree-ssa-20020619-branch.</dd>
+
+ <dt>faster-compiler-branch</dt>
+ <dd>This was a temporary branch for compiler speedups for GCC 3.4.
+ See <a href="http://gcc.gnu.org/ml/gcc/2002-08/msg00498.html";>this
+ thread</a> for discussion of possible work still to be done in this
+ area. The branch is unmaintained at present.</dd>
+
+ <dt>gcc-3_3-e500-branch</dt>
+ <dd>This branch was for backporting the PowerPC/E500 back end to GCC 3.3.
+ See <a href="http://gcc.gnu.org/ml/gcc/2003-04/msg00733.html";>this
+ message</a> for details.</dd>
+
+ <dt>gomp-01-branch</dt>
+ <dt>gomp-branch</dt>
+ <dd>These two branches were initial attempts to implement
+ OpenMP support in GCC. They were never properly maintained and
+ have now been superceded by <code>gomp-20050608-branch</code>.</dd>
+
+ <dt><a href="projects/tree-ssa/lno.html">lno-branch</a></dt>
+ <dd>A sub-branch of tree-ssa that aims at implementing a loop
+ nest optimizer at the tree level. Was largely merged into mainline,
+ and is currently unmaintained.
+ This work now continues on the autovect-branch.</dd>
+
+ <dt>java-gui-branch</dt>
+ <dd>This was a temporary branch for development of java GUI libraries
+ (AWT and Swing) in the libjava directory. It has been superseded
+ by java-gui-20050128-branch</dd>
+
+ <dt>java-gui-20050128-branch</dt>
+ <dd>This was a temporary branch for development of java GUI libraries
+ (AWT and Swing) in the libjava directory. It has been merged into
+ mainline.</dd>
+
+ <dt>csl-hpux-branch</dt>
+ <dd>This branch was for changes to G++ to be more compatible with
+ ABI bugs in the HP-UX C++ compiler. It is now unmaintained.</dd>
+
+ <dt>tree-cleanup-branch</dt>
+ <dd>This branch contained improvements and reorganization to the
+ tree optimizers that were not ready in time for GCC 4.0. The
+ goal was to cleanup the tree optimizers and improve the sequencing
+ of the passes. It has now been merged into mainline for the
+ 4.1 release.</dd>
+
+ <dt>bje-unsw-branch</dt>
+ <dd>This branch was dedicated to some research work by Ben Elliston
+ at the University of New South Wales (UNSW) on transformation
+ phase ordering. It will never merge with mainline, although a
+ selection of patches may be submitted over time.</dd>
+
+ <dt>gcc-3_3-rhl-branch</dt>
+ <dd>This branch used to hold Red Hat GNU/Linux compilers based on
+ GCC 3.3.x.</dd>
+</dl>
+
+<h2><a name="wwwdocs">Web pages</a></h2>
+
+<p>The web pages for the GCC project are also in the SVN repository
+and you can check them out, submit patches, etc just like you do for
+the compiler itself.</p>
+
+<p>Use <code>SVN co -P wwwdocs</code> to check out the web pages.</p>
+
+<p>Patches should be marked with the tag [wwwdocs] in the subject line.</p>
+
+<h2><a name="system">The host system</a></h2>
+
+<p>The setup of the machine running the gcc.gnu.org site is also
+available, through
+<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=sourceware";>
+cvsweb</a> and anonymous read-only CVS. Use the same procedure
+as in <a href="cvs.html">CVS documentation</a> but use
+<code>:pserver:anoncvs@gcc.gnu.org:/cvs/sourceware</code> for the repository
+and <code>infra</code> for the module.</p>
+
+</body>
+</html>
Index: svnwrite.html
===================================================================
RCS file: svnwrite.html
diff -N svnwrite.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ svnwrite.html 28 Oct 2005 18:13:15 -0000
@@ -0,0 +1,396 @@
+<html>
+<head>
+<meta name="description"
+ content="Instructions for read-write access to the GCC SVN repository." />
+<meta name="keywords"
+ content="GCC, patches, checking in, SVN, SSH, access policy" />
+<title>Read-write SVN access</title>
+</head>
+
+<body>
+
+<h1>Read-write SVN access</h1>
+
+<p>We have read/write access to the SVN repository available for
+significant developers. Maintainers are also encouraged to <a
+ href="bugs/management.html">edit our bugs database</a>.
+
+Read/write access to the wwwdocs repository containing GCC
+www documents is still done using <a href="cvswrite.html">CVS</a>
+</p>
+
+<hr />
+<h2>Contents</h2>
+<ol>
+ <li><a href="#authenticated">Authenticated access</a></li>
+ <li><a href="#setup">Setting up your local SVN tree</a></li>
+ <li><a href="#policies">Write access policies</a></li>
+ <li><a href="#testing">Testing changes</a></li>
+ <li><a href="#checkin">Checking in a change</a></li>
+ <li><a href="#example">Example check-in session</a></li>
+ <li><a href="#branches">Creating branches</a></li>
+</ol>
+
+<hr />
+<h2><a name="authenticated">Authenticated access</a></h2>
+
+<p>We provide authenticated access via the SSH protocol.</p>
+
+<p>If you already have an account on sources.redhat.com, please send
+email to <code>overseers(at)gcc.gnu.org</code> with a request
+for access to the GCC repository. Include the name of the person who
+is sponsoring your access.
+Else use <a
+href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi";>this form</a>
+to supply your SSH public key (which you can generate via the
+<code>ssh-keygen</code> program) and other details.</p>
+
+<p>Once we have this information we will set up an account on
+gcc.gnu.org and inform you by mail. At this point you
+should be able to check out a tree with SVN and add yourself to the
+MAINTAINERS file to test write access, following the instructions below.</p>
+
+<hr />
+<h2><a name="setup">Setting up your local SVN tree</a></h2>
+
+<p>Once your account has been set up, check out the GCC sources by
+issuing the command:</p>
+
+<blockquote><p><code>
+svn co svn+ssh://:<i>username</i>@gcc.gnu.org:/svn/gcc/trunk gcc
+</code></p></blockquote>
+
+<p>where <i>username</i> is your user name at gcc.gnu.org.</p>
+
+<p>It is also possible to convert an existing SVN tree to use SSH by
+using svn switch --relocate:</p>
+
+<blockquote><p><code>
+svn switch --relocate svn://gcc.gnu.org/svn/gcc \
+svn+ssh://<i>username</i>@gcc.gnu.org:/svn/gcc
+</code></p></blockquote>
+
+<p>To avoid the nuisance of having to supply your passphrase for each
+operation, you may want to use <code>ssh-agent</code>(1) and
+<code>ssh-add</code>(1).</p>
+
+<p>To avoid messages about (lack of) X11 forwarding, put in your
+<samp>$HOME/.ssh/config</samp> an entry like:</p>
+
+<blockquote><p><code>
+Host gcc.gnu.org<br />
+ForwardX11 no
+</code></p></blockquote>
+
+<hr />
+<h2><a name="policies">Write access policies</a></h2>
+
+<p>The GCC project grants some developers various levels of write
+access to the GCC master sources. SVN doesn't provide fine grained
+control over access to the repository; therefore, we depend on each
+developer to follow the appropriate policies.</p>
+
+<dl>
+ <dt>Global write permission.</dt>
+ <dd><p>A very limited number of developers have global write
+ permission over the entire repository. They may check in changes to
+ any part of the compiler without approval from anyone else. They
+ may also approve other people's changes to any part of the
+ compiler.</p></dd>
+
+ <dt>Localized write permission.</dt>
+ <dd><p>This is for people who have primary responsibility for ports,
+ front ends, or significant hunks of code in the compiler. These
+ folks are allowed to make changes in code they maintain without
+ approval from anyone else, and approve other people's changes in
+ those files. They must get approval from the appropriate maintainers
+ for changes elsewhere in the compiler.</p>
+
+ <p>Maintainers of a port maintain the files in config/<i>port</i>/,
+ the configure fragments for the port, documentation for the port and
+ test cases for features or bugs specific to this port. Port
+ maintainers do not have approval rights in other files.</p></dd>
+
+ <dt>Write after approval.</dt>
+ <dd><p>This is folks that make regular contributions, but do not
+ fall into one of the two previous categories. People with write
+ after approval need to submit their patches to the list; once the
+ patches have been approved by the appropriate maintainers the
+ patches may be checked into the GCC sources. The steering committee
+ or a well-established GCC maintainer (including, but not limited to
+ global write maintainers) can <a href="#authenticated">
+ approve for write access</a> any person with GNU copyright assignment
+ papers in place and known to submit good patches.</p></dd>
+</dl>
+
+<p>The list of folks with write access to the repository can be found
+in the MAINTAINERS file in the GCC distribution.</p>
+
+<p>When you have checked in a patch exactly as it has been approved,
+you do not need to tell that to people -- including the approver.
+People interested in when a particular patch is committed can check
+SVN or the <a href="http://gcc.gnu.org/ml/gcc-SVN/";>gcc-SVN</a>
+list.</p>
+
+<h3>Free for all</h3>
+
+<p>The following changes can be made by everyone with SVN write access:</p>
+
+<p>Fixes for obvious typos in ChangeLog files, docs, web pages, comments
+and similar stuff. Just check in the fix and copy it to
+<code>gcc-patches</code>. We don't want to get overly anal-retentive
+about checkin policies.</p>
+
+<p>Similarly, no outside approval is needed to revert a patch that you
+checked in.</p>
+
+<p><a href="codingconventions.html#upstream">Importing files maintained
+outside the tree from their official versions</a>.</p>
+
+<p><a href="#branches">Creating and using a branch</a> for development,
+including outside the parts of the compiler one maintains, provided that
+changes on the branch have copyright assignments on file. Merging such
+developments back to the mainline still needs approval in the usual way.</p>
+
+
+<hr />
+<h2><a name="testing">Testing changes</a></h2>
+
+<p>All changes must be tested according to the
+<a href="contribute.html#testing">instructions for testing patches</a>
+before they are checked in. If you wrote the patch yourself, you
+should test it yourself, unless there is a reason why someone else
+must do it for you (for instance, if you are fixing a problem on a
+system you do not have access to). If you are checking in a patch for
+someone else, you only need to test it if they did not.</p>
+
+<p>You must test exactly the change you intend to check in; it is not
+good enough to have tested an earlier variant. (Unless the only
+changes from the earlier variant are formatting and comment changes;
+if there are <strong>any</strong> changes to the code itself you
+should re-bootstrap.) It is a good idea to re-test patches which were
+submitted a long time ago before applying them, even if nothing
+appears to have changed.</p>
+
+<p>When you post your change to <code>gcc-patches</code>, state the
+canonical name(s) of the platform(s) you used for testing.</p>
+
+<p>These rules are designed to ensure that checked-in code does not
+contain bugs that prevent other people from continuing to get their
+work done. There will always be bugs, but these rules help to
+minimize the amount of time where the tree does not build at
+all. Repeated failure to adhere to these rules could result in the
+revocation of check-in privileges by the Steering Committee.</p>
+
+<hr />
+<h2><a name="checkin">Checking in a change</a></h2>
+
+<p>The following is meant to provide a very quick overview of how to
+check in a change. It is not meant to be a replacement for the SVN
+manual but instead a supplement. The SVN manual is available both
+as part of the SVN source distribution, as well as at
+<a href="http://svnbook.com";>The SVN book homepage</a></p>
+
+<p>In all the commands listed below, you can give an explicit list of
+filenames to the SVN command. We recommend you list files explicitly
+when performing checkins to avoid accidental checkins of local
+code.</p>
+
+<p>We prefer that each SVN checkin be of a complete, single logical
+change, which may affect multiple files. The log message for that
+checkin should be the complete ChangeLog entry for the change. This
+makes it easier to correlate changes across files, and minimizes the
+time the repository is inconsistent. If you have several unrelated
+changes, you should check them in with separate SVN commit
+commands.</p>
+
+<ol>
+<li>Sync your sources with the master repository via "<code>svn
+update</code>" before attempting a checkin; this will save you a little
+time if someone else has modified that file since the last time you
+synced your sources. It will also identify any files in your local
+tree that you have modified.</li>
+
+<li>Apply the patch to your local tree and update the ChangeLog file.
+Use the current date/time for the ChangeLog entry, not the time that
+the patch was submitted.</li>
+
+<li>Make sure to rebuild any generated files that would be affected by
+the patch. Make sure to check them in along with the files explicitly
+modified by the patch.</li>
+
+<li>We recommend using "<code>svn diff</code>" after applying a patch to a
+local tree. Review the output to make sure that only the changes you
+wanted to check in will be checked in. Also check to see if the
+copyright dates need to be updated.</li>
+
+<li>Use "<code>svn commit</code>" to check in the patch. You can enter
+the log message via the "<code>-m</code>" argument to commit, or wait for
+the editor window to appear and enter the log message in the editor
+window.</li>
+
+<li>After exiting the editor, SVN will connect to the GCC SVN server
+and check in your changes. When your prompt returns the checkin is
+finished. A message will be sent to the gcc-cvs mailing
+list indicating that a change was made. SVN will provide a message if
+an error occurs and it will not check in any files.</li>
+</ol>
+
+<hr />
+<h2><a name="example">Example check-in session</a></h2>
+
+<p>Here's an actual check-in session for a patch John Carr recently
+sent to the GCC list. This was the ChangeLog for his change:</p>
+
+<blockquote><pre>
+Sun Feb 8 08:02:13 1998 John Carr <jfc@mit.edu>
+
+ * bitmap.c (bitmap_debug_file): HOST_PTR_PRINTF converts a pointer,
+ not a HOST_WIDE_INT.
+
+ * calls.c (expand_call): Change test of expand_inline_function
+ return value to stop compiler warning.
+
+ * genattrtab.c (RTL_HASH): Cast pointer to long, not HOST_WIDE_INT.
+</pre></blockquote>
+
+<h3>First, I sync my local repository.</h3>
+
+<blockquote><pre>
+[/law/gcc] svn update
+? libobjc
+? gcc/.ada
+? gcc/jump.c.SAVE
+? gcc/loop.c.SAVE
+M MAINTAINERS
+M Makefile.in
+M gcc/loop.c
+M gcc/cp/parse.c
+M gcc/objc/Make-lang.in
+M gcc/objc/Makefile.in
+At revision 105932
+</pre></blockquote>
+
+<p>The question marks indicate files in my local repository that are
+not part of the official sources. The "M" indicates files I've
+changed locally for some unrelated work -- thus I have to be careful
+to avoid checking them in. A "U" would have indicated a file that SVN
+updated because my local copy was out of date relative to the master
+sources.</p>
+
+<p>The local repository is now up to date.</p>
+
+<h3>Apply the patch to the local source</h3>
+
+<blockquote><pre>
+[/law/gcc/gcc] patch < ~/Mail/gcc/pendingpatches/42
+Hmm... Looks like a new-style context diff to me...
+The text leading up to this was:
+<i>[ uninteresting text deleted ]</i>
+|*** bitmap.c.egcs Sat Dec 20 06:31:11 1997
+|--- bitmap.c Sun Feb 8 08:01:32 1998
+--------------------------
+Patching file bitmap.c using Plan A...
+Hunk #1 succeeded at 563.
+Hunk #2 succeeded at 573.
+Hmm... The next patch looks like a new-style context diff to me...
+The text leading up to this was:
+--------------------------
+|*** calls.c.egcs Sun Feb 8 07:44:02 1998
+|--- calls.c Sun Feb 8 08:00:08 1998
+--------------------------
+Patching file calls.c using Plan A...
+Hunk #1 succeeded at 730.
+Hmm... The next patch looks like a new-style context diff to me...
+The text leading up to this was:
+--------------------------
+|*** genattrtab.c.egcs Sun Feb 8 07:44:04 1998
+|--- genattrtab.c Sun Feb 8 08:05:36 1998
+--------------------------
+Patching file genattrtab.c using Plan A...
+Hunk #1 succeeded at 506.
+done
+</pre></blockquote>
+
+<h3>Add ChangeLog entry by hand</h3>
+
+<p>ChangeLog entries should be handled as straight text;
+patches against ChangeLogs rarely apply correctly.</p>
+
+<h3>Review changes for correctness</h3>
+
+<p>The patch and its associated <code>ChangeLog</code> entry are in my
+local tree; now I run <code>svn diff</code> on the modified files and
+review the output, verifying that it only contains the changes we want.</p>
+
+<blockquote><pre>
+[/law/gcc/gcc] svn diff bitmap.c calls.c genattrtab.c
+</pre></blockquote>
+
+<h3>Update Copyrights</h3>
+
+<p>Review the changed files to see if any copyrights need updating, in
+this particular case all three needed their copyrights updated.</p>
+
+<blockquote><pre>
+[/law/gcc/gcc] vi bitmap.c calls.c genattrtab.c
+</pre></blockquote>
+
+<h3>Commit the changes to the central repository</h3>
+
+<blockquote><pre>
+[/law/gcc/gcc] svn commit ChangeLog bitmap.c calls.c genattrtab.c
+</pre></blockquote>
+
+<p>My editor starts and I enter the log message; the lines starting
+with <code>This line, and those below, will be ignored</code> are automatically
+added by SVN and will be automatically removed:</p>
+
+<blockquote><pre>
+ * bitmap.c (bitmap_debug_file): HOST_PTR_PRINTF converts a pointer,
+ not a HOST_WIDE_INT.
+
+ * calls.c (expand_call): Change test of expand_inline_function
+ return value to stop compiler warning.
+
+ * genattrtab.c (RTL_HASH): Cast pointer to long, not HOST_WIDE_INT.
+
+--This line, and those below, will be ignored--
+M ChangeLog
+M bitmap.c
+M calls.c
+M genattrtab.c
+</pre></blockquote>
+
+<p>Now write & quit from the editor, and SVN will start the actual
+checkin process....</p>
+
+<blockquote><pre>
+Sending ChangeLog
+Sending bitmap.c
+Sending calls.c
+Sending genattrtab.c
+Transmitting file data .
+Committed revision 105933.
+[/law/gcc/gcc]
+</pre></blockquote>
+
+<p>And that's it!</p>
+
+<hr />
+<h2><a name="branches">Creating branches</a></h2>
+
+<p>To create a branch for development, simply copy the trunk directory
+to a directory in /branches as follows:</p>
+
+<blockquote><pre>
+svn cp svn+ssh://<i>username</i>@gcc.gnu.org/svn/gcc/trunk \
+ svn+ssh://<i>username</i>@gcc.gnu.org/svn/branches/$BRANCH
+</pre></blockquote>
+
+<p>Also, please document such branches at
+<a href="svn.html#devbranches">svn.html#devbranches</a>.
+</p>
+
+</body>
+</html>