This page lists projects for GCC's documentation. Some of these concern the internals documentation of GCC, and obviously require intimate knowledge of GCC's internals. The other projects are about work on the user documentation, and could be taken on by anyone who has mastered US English and has basic technical writing skills.
Always, anytime, feel free to shout at anyone who sends in a patch without including all relevant documentation changes.
It is also always appreciated if you read the whole manual and become familiar with what is documented where, and what documentation appears to be missing. Report or fix any problems you see.
Fully document the interface of front ends to GCC, that is, the
interfaces, and the various functions, data structures, etc., that
a front end must or may provide.
We've got quite a bit of this but it is scattered all over the
place. It belongs in the official manual. There is a C/C++ specific manual,
which is incomplete, though. The file
gcc/LANGUAGES contains incomplete and outdated information
about changes made in not so recent years to the
interface. Several people have written partial manuals on implementing
new front ends. Pointers to some of those can be found in our readings list. With the advent of tree-ssa,
most of these manuals are obsolete.
The porting manual describes what used to be the proper way to write a GCC back end. It is several years out of date. Find all the out-of-date advice for porters and replace it with correct advice. Mark old, deprecated features as such. Replace examples using old targets with examples for newer targets.
Here is an outline proposed by Allan Adler.
Document every RTX code and accessor macro, every insn name, every
tm.h macro and every target hook thoroughly. (See this list of
undocumented tm.h macros).
These may involve hunting down whoever added whichever thing it is and torturing information out of them.
Work out the correct argument and return types for each tm.h
macro, and make the manual describe them with
and similar using C prototypes. For those macros for which
performance is not important, change them to be functions, in the
targetm structure for target hooks.
All command-line options should be indexed, and there should be index entries for the text of all error messages that might be confusing, if there is a relevant part of the manual. See a message to gcc-bugs about this.
Start with the readings list and the
secondary Texinfo documents in the source tree, such as
libstdc++-v3/docs/html/17_intro/porting.texi. Pick your
favorite FAQ from the lists and roll it into the manual.
make dviat top level to build DVI versions of all manuals. Add a
make htmltarget to build HTML versions of manuals (using
texinfo.texincludes some support for PDF output).
Go through the list of "Actual Bugs" in
gcc/doc/trouble.texi. Work out what they refer to, if
necessary by asking people who were involved in GCC development when
those bugs were documented. If a bug is no longer present, remove it
from the list; if it is still present, file a bug
Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.