This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Volunteer for Testing
- To: Bill Wendling <wendling at ncsa dot uiuc dot edu>
- Subject: Re: Volunteer for Testing
- From: Bernd Schmidt <bernds at redhat dot com>
- Date: Tue, 5 Dec 2000 19:36:02 +0000 (GMT)
- cc: gcc at gcc dot gnu dot org
On Tue, 5 Dec 2000, Bill Wendling wrote:
> I read the request for people to help with testing of gcc and I would
> like to help with testing 2.95.3. I have access to a number of machines
> (via work) and may be able to use them for this. Among them are:
>
> HPUX 10.20 and 11.00
> Sun 5.7 and 5.6
> Linux 2.2.x on Intel
> Alpha OSF1
> FreeBSD 4.1.1
> Irix 6.5
All of these are interesting. Which libc version is installed on the
Linux machine?
> how does one begin doing this?
Download gcc-2.95.2 and the current testsuite:
ftp://gcc.gnu.org/pub/gcc/releases/gcc-2.95.2/gcc-2.95.2.tar.gz
ftp://gcc.gnu.org/pub/gcc/snapshots/2000-11-27/gcc-tests-20001127.tar.gz
Extract both, then move the testsuite into the right place
rm -rf gcc-2.95.2/gcc/testsuite
mv gcc-20001127/gcc/testsuite gcc-2.95.2/gcc/
Then, go to "gcc-2.95.2/gcc/testsuite" and apply the patch below:
patch -p0 <testsuite.diff
Then, build the 2.95.2 release on all available targets (using "make
bootstrap"). Run the testsuite ("make -k check"), and send in the results.
There's a script, "gcc-2.95.2/contrib/test_summary", which will apparently
help you postprocess those results into a usable form. I have to admit I've
never used it, but it says at the top that if you run it like this (while in
the toplevel build directory)
gcc-2.95.2/contrib/test_summary | sh
it will automatically mail the results to the right place.
The same thing will then have to be done for the 2.95.3 test releases which
ought to start appearing in about two weeks. If you want, you can already
do tests on the current branch; the CVS branch tag is "gcc-2_95-branch".
Don't forget to substitute the new testsuite on the branch as well.
Thanks for your help! Let me know if anything goes wrong with these
instructions.
Bernd
diff --width=160 -du lib/g++.exp lib.1/g++.exp
--- lib/g++.exp Sun Nov 26 12:20:50 2000
+++ lib/g++.exp Thu Nov 30 11:02:19 2000
@@ -68,7 +68,6 @@
#
proc g++_include_flags { args } {
global srcdir
- global HAVE_LIBSTDCXX_V3
set flags ""
@@ -83,15 +82,9 @@
set gccpath [get_multilibs]
- if { ${HAVE_LIBSTDCXX_V3} } {
- set odir_v3 [lookfor_file ${gccpath} libstdc++-v3]
- set sdir_v3 [lookfor_file ${srcdir} libstdc++-v3]
- append flags [exec ${odir_v3}/tests_flags --compiler ${odir_v3} ${sdir_v3}]
- } else {
- set odir_v2 [lookfor_file ${gccpath} libstdc++]
- set sdir_v2 [lookfor_file ${srcdir} libstdc++]
- append flags "-I${sdir_v2} -I${sdir_v2}/stl "
- }
+ set odir_v2 [lookfor_file ${gccpath} libstdc++]
+ set sdir_v2 [lookfor_file ${srcdir} libstdc++]
+ append flags "-I${sdir_v2} -I${sdir_v2}/stl "
return "$flags"
}
@@ -223,7 +216,7 @@
# Make sure that lines are not wrapped. That can confuse the
# error-message parsing machinery.
- lappend ALWAYS_CXXFLAGS "additional_flags=-fmessage-length=0"
+ # lappend ALWAYS_CXXFLAGS "additional_flags=-fmessage-length=0"
verbose -log "ALWAYS_CXXFLAGS set to $ALWAYS_CXXFLAGS"
diff --width=160 -du lib/objc.exp lib.1/objc.exp
--- lib/objc.exp Sun Aug 6 19:41:49 2000
+++ lib/objc.exp Thu Nov 30 11:02:03 2000
@@ -143,7 +143,7 @@
lappend options "additional_flags=-DNO_VARARGS"
}
set objcpath "[get_multilibs]"
- set libobjc_dir [lookfor_file ${objcpath} libobjc/.libs/libobjc.a]
+ set libobjc_dir [lookfor_file ${objcpath} libobjc/libobjc.a]
if { $libobjc_dir != "" } {
set libobjc_dir [file dirname ${libobjc_dir}]
set objc_link_flags "-L${libobjc_dir}"