V3: SPARC bug and tree freeze

Joseph S. Myers jsm28@cam.ac.uk
Sun Nov 12 05:32:00 GMT 2000


On Sun, 12 Nov 2000, Robert Dewar wrote:

> 2. Running a complex set of tests is not such an easy task and it is
> easy to make a mistake doing it, or to fail to notice a discrepancy.

Running the GCC testsuite is trivial.  I do something along the following
lines (with a couple of trivial scripts, and optimizing the first step
away if I already have the test logs for unmodified GCC and haven't
updated my GCC tree since running those tests):

# Build unmodified GCC and run make -k check
mv `find . -name '*.sum'` ..
# Build patched GCC and run make -k check
diff ../libstdc++.sum i686-pc-linux-gnu/libstdc++/testsuite/libstdc++.sum
diff ../libio.sum i686-pc-linux-gnu/libio/testsuite/libio.sum
diff ../g++.sum gcc/testsuite/g++.sum
diff ../g77.sum gcc/testsuite/g77.sum
diff ../objc.sum gcc/testsuite/objc.sum
diff ../gcc.sum gcc/testsuite/gcc.sum

If adding or changing testcases as part of the patch, I compare gcc.log as
well to make sure that the output is exactly as intended.

I hope that any Ada testsuites that get included in GCC will similarly
provide .sum or similar summary files that can meaningfully be compared
with diff (with any regressions obvious, and with any non-regression
differences minimal).

> As for "who will provide the machines", I will immediately make a
> commitment that if something like this is set up, ACT will contribute
> a top of the line PC for the task (we may be able to do more, but I
> have to consult with other folks before offering too much on my own
> since we have limited resources :-)

What, with such facilities, is the procedure for developers without such a
machine themselves to debug problems automated testing shows up?  (My
understanding is that the existing regression checker deliberately uses a
simulator target, so that any GCC developer can build for that environment
to investigate problems.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk



More information about the Gcc-bugs mailing list