The scripts (sbox-scripts.tar) on this page are useful when testing the effects of a patch on compile time and memory consumption in the compiler. The scripts have evolved over a long period of time and have that home-grown undocumented taste. However, they are very short and simple to understand. They merely mechanize the chore of throwing millions of lines of code into GCC and see how it behaves before and after a specific change.
The basic idea is that you will have a before compiler and an after compiler. The only difference between the two should be the specific patch that you are testing. The scripts assume the presence of several code bases in pre-processed form:
cc1-i-files: This is a collection of .i and .ii files generated by a full GCC bootstrap. To generate these files, you need to have a recently built GCC and use the script prepare-cc1-i-files to generate them.
DLV: You will need to contact Gerald Pfeifer to get access to this code. It is the source of the infamous bug 8361.
MICO: A CORBA implementation. Available here.
TRAMP3D: Richard Guenther's C++ simulation code
SPEC2000: The pre-processed code from the SPEC 2000 benchmarks. You will need a SPEC licence and recompile it with -save-temps.
FF3D: Finite element PDE solver. Available here.
The main scripts you will need are:
setup-cc1-tests: Creates a directory structure in the current working directory with before and after sub-directories for each of the packages mentioned above. It also copies cc1 and cc1plus from the before and after GCC build directories that you specify.
cc1test: Runs cc1 and cc1plus over all the cc1-i-files in the current directory. It has arguments to specify whether you want all files or just the small ones or the big ones, etc.
cpp-test: This one is used for running files from the other packages (DLV, FF3D, MICO, TRAMP3D, SPEC2000 and VARIOUS). Clearly this could also be done by cc1test, but this is how the two scripts evolved and I couldn't be bothered to merge them yet.
time-stats: Once the tests have run, this computes the total compile time or the maximum compile time over all the .time files specified. These .time files are assumed to have been generated with -ftime-report.
mem-stats: Likewise for memory utilization. This assumes that the -fmem-report was used.
There are various other scripts to do specific counts or paw through dump files. They are pretty self-explanatory and short. Also, there is a gfortran.par configuration file for using with Polyhedron 2005.
For checking memory usage of processes the following two scripts also turned out useful: maxmem2.sh and maxmem-pipe2.py. They are based on parsing strace output (of mmap* and brk syscalls) instead of polling memory usage via the /proc file system (or equivalent). You would use it as maxmem2.sh gcc -c foo.c.