Projects for beginners

["Zack Weinberg" <zackw at stanford dot edu>]

Here's my list of GCC-related projects that could usefully be
attempted by beginners to GCC.  (Not necessarily beginners to C and
Unix; in some cases they require considerable programming skill.)
Please add whatever you can think of, once the thread dies down, I'll
pack it all up in HTML, add some more detailed instructions, and put
it on the website.

Bug patrol:
  Do janitorial work on the bug database.
	- make sure fixed bugs are closed, follow up on old bugs,
	demand more information for incomplete bugs, etc.

  Digest test cases out of bug report database.

  Analyze failing test cases.
	- Usually doable with a debugger, the RTL manual, and
	willingness to poke around.  Do XFAILing tests too.

  Get rid of testsuite/gcc.misc-tests and testsuite/g++.dg/special.
	- I'm 90% sure all the tests in there can be moved into the
	common directories.  However, there's enough dragon droppings
	to make me doubt.  Requires ability to make sense of bizarre
	Tcl and ancient commentary.

  Cross-reference all the tests and find all the duplicates.
	- Have to figure out just what constitutes a duplicate.

  Set up more autobuilders.
	- Proposal: we should have an autobuilder for each of the
	"primary evaluation platforms" for GCC 3.0, and as many of the
	secondaries as we can.
	- Be nice to have at least one that was beefy enough that it
	could run with RTL checking on.
	- Tinderbox, anyone?


Code cleanliness:
  Warnings patrol.

  Add multiple include guards to all header files.

  Verify all the object->header dependencies in the Makefiles.
	- Mega bonus points for automating this.

  Delete garbage.
	- #if 0 blocks that have been there for years, unused
	functions, unused entire files, dead configurations, dead
	Makefile logic, dead RTL and tree forms, ...

  Find comments of the form /* Look at this again after gcc 2.3 */ and
  investigate whatever issue it was.

  Cross-reference all the headers; find all the places where two or more
  headers declare the same function, global, etc.
	- For someone who's good with scripting languages.  I'm sure
	there's a clever Perl module out there for this sort of thing.

  Then fix it so every global declaration occurs in exactly one header.

  Find all the places where one flag bit is used with N different
  meanings and give each different meaning a different accessor macro.
  Augment the tree/RTL checking macros so they verify that the
  accessors match the data.

Configuration and build issues:
  Find places that are still using obsolete system-category macros (USG,
  BSTRING, etc) and autoconfiscate them.

  Get as much out of the x-host and xm-host.h files into
  autoconf tests, system.h, etc., as possible.
	- I would give even odds that it can all go.

  Same for the t-machine files.
	- These probably aren't going away, but there's a lot of
	obsolete cruft in them.  Start by expunging all remaining
	traces of libgcc1.  There are also plenty of things that
	should be done with feature tests, e.g. INSTALL_ASSERT_H.

  Get rid of build-make and cross-make.

  Clean up the autoconf script.
	- I'm particularly thinking of the horrible tests for assembler
	features, but there's plenty of other atrocities.
	- Check out autoconf 2.50 and see if it will help.
	- Feed back gcc-private autoconf macros to the autoconf
	maintainers.  We have several that would be widely useful.

  Fix the Makefile so it doesn't confuse the build and host systems
  anymore.
	- *Should* be search-and-replace.


Port cleanup:
  Migrate default definitions of tm.h macros out of random source files
  into defaults.h.

  Convert huge macros in tm.h to functions in corresponding tm.c.

  Convert configurations to new style where tm.h chunks do not include
  each other incestuously.

  Find and update code that uses obsolete mechanisms.  Then get rid of
  the backward compat code in the compiler proper.

  Clean up #ifdef messes in tm.h files.
	- Is there a preferred style here?

  Convert md files that use cc0 so they don't anymore.
	- This is apparently doable with some stereotyped insn
	patterns.  You'd need to understand RTL, but it strikes me as
	a good learn-by-doing project.  See
	http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00643.html.


Library infrastructure:
  Find private implementations of general data structures, and make them
  use library routines instead.
	- notably, there's private hash tables all over the place.
	- careful; there's at least three places where not
	using hashtab.c is deliberate.

  Write nifty pseudotemplate versions of existing general data structures
  to avoid abstraction penalties.
	- For someone who's good with the preprocessor macros.  This
	has been #2 on my to-do list for way too long.
	- Then you can forget the caveat in the previous entry.

  Generalize gcc-specific data structure modules and move them to
  libiberty.
	- e.g. [s]bitmap.c.

  Find private workarounds for host bugs and move them to libiberty.

  Get libiberty built for the build system so we can get rid of all
  kinds of crap in the Makefile and the genfoo.c programs.
	- Talk to Kaveh first.


Documentation:
  Document every RTX code and accessor macro thoroughly.
  Ditto, every meaningful insn name.
  Ditto, every tm.h macro.
  Ditto, every command line switch.
	- May involve hunting down whoever added whichever
	thing it is and torturing information out of them.

  Finish documenting the tree structure and the front-end interface.
	- We've got quite a bit of this but it is scattered all over
	the place.  It belongs in the official manual.

  Find all the out-of-date advice for porters and replace it with
  correct advice.

  Roll information in external documents into the official manual.

  Improve user and installation documentation.
	- Pick your favorite FAQ from the lists and roll it into the manual.
	- Add information on relevant standards.
	- Document the exact semantics of all the extensions.  Also
	say what they're good for.  If they're useless, admit it.

zw