basic-improvements call for testers

basic-improvements call for testers

[Zack Weinberg]

I have now committed a merge from trunk to the 3.4 basic-improvements
branch.  My tests show only one significant difference between
testsuite results on the mainline and the branch: that is an
additional failure of the libjava testsuite.  As the libjava test
suite is currently in bad shape with 65 unexpected failures on the
mainline, I am not inclined to hold the merge over it.  A pseudo-diff
is appended to this message; if a test suite isn't mentioned, it had
no differences at all between mainline and branch.

Please test the branch and report results using test_summary, but also
copy me; I don't follow gcc-testresults.

I'm aware of three blocker issues for the merge:

- The 32x64 HOST_WIDE_INT problem, which I will be addressing shortly.
- foobar-c.c lacking appropriate dependencies on coretypes.h $(TM_H),
  which I will also address shortly.
- The Darwin sqrt stub problem, which I don't know enough about to
  fix; I'd appreciate it if one of the people experiencing it could
  look into a patch.

If you know of or discover other issues which you think should block
the merge, please say so.

Regarding check-in policies, I would recommend the following:

- For the time being, nothing goes onto mainline unless it is also
  going onto the 3.3 release branch.  To make my life easier, please
  test and apply such patches on the basic-improvements branch also.

- basic-improvements is open for checkins under its usual rules,
  i.e. Stage 2 patches only.

I'd like to get the blocker issues all resolved and the branch merged
to mainline by Monday.  Any help you can lend is greatly appreciated.

zw

--- mainline/report     2002-12-14 10:14:49 -0800
+++ 3.4bib/report       2002-12-14 10:14:49 -0800
 
-Compiler version: 3.3 20021213 (experimental) (i686-pc-linux-gnu)
+Compiler version: 3.4-bi 20021213 (experimental) (i686-pc-linux-gnu)

                === g++ Summary ===
 
-# of expected passes           7891
+# of expected passes           7899
 # of unexpected failures       2
-# of expected failures         92
+# of expected failures         90
 # of untested testcases        9
 # of unsupported tests         3
 
                === gcc Summary ===
 
-# of expected passes           20746
+# of expected passes           20781
 # of unexpected failures       6
 # of expected failures         64
-# of unsupported tests         73
+# of unsupported tests         75

                === libjava tests ===

 ...
 WARNING: program timed out.
 FAIL: SyncTest execution - gij test
 WARNING: program timed out.
+FAIL: SyncTest execution - bytecode->native test
+WARNING: program timed out.
 FAIL: SyncTest execution - gij test
 FAIL: Thread_Alive execution - gij test
 FAIL: Thread_Alive execution - gij test
 ...
 
                === libjava Summary ===
 
-# of expected passes           2772
-# of unexpected failures       65
+# of expected passes           2770
+# of unexpected failures       66
 # of expected failures         14
-# of untested testcases        69
+# of untested testcases        70

Re: basic-improvements call for testers

[Jan Hubicka]

> 
> I have now committed a merge from trunk to the 3.4 basic-improvements
> branch.  My tests show only one significant difference between
> testsuite results on the mainline and the branch: that is an
> additional failure of the libjava testsuite.  As the libjava test
> suite is currently in bad shape with 65 unexpected failures on the
> mainline, I am not inclined to hold the merge over it.  A pseudo-diff
> is appended to this message; if a test suite isn't mentioned, it had
> no differences at all between mainline and branch.
> 
> Please test the branch and report results using test_summary, but also
> copy me; I don't follow gcc-testresults.
> 
> I'm aware of three blocker issues for the merge:
> 
> - The 32x64 HOST_WIDE_INT problem, which I will be addressing shortly.
> - foobar-c.c lacking appropriate dependencies on coretypes.h $(TM_H),
>   which I will also address shortly.
> - The Darwin sqrt stub problem, which I don't know enough about to
>   fix; I'd appreciate it if one of the people experiencing it could
>   look into a patch.
I tried sparc and mips targets on rtlopt branch (that is based on BIB
branch).  On sparc I run into 32x64 host problem you mention.  Mips
bootstrap got syntax error.
So in short I am going to bootstrap mips and sparc32 now.

Honza
> 
> If you know of or discover other issues which you think should block
> the merge, please say so.
> 
> Regarding check-in policies, I would recommend the following:
> 
> - For the time being, nothing goes onto mainline unless it is also
>   going onto the 3.3 release branch.  To make my life easier, please
>   test and apply such patches on the basic-improvements branch also.
> 
> - basic-improvements is open for checkins under its usual rules,
>   i.e. Stage 2 patches only.
> 
> I'd like to get the blocker issues all resolved and the branch merged
> to mainline by Monday.  Any help you can lend is greatly appreciated.
> 
> zw
> 
> --- mainline/report     2002-12-14 10:14:49 -0800
> +++ 3.4bib/report       2002-12-14 10:14:49 -0800
>  
> -Compiler version: 3.3 20021213 (experimental) (i686-pc-linux-gnu)
> +Compiler version: 3.4-bi 20021213 (experimental) (i686-pc-linux-gnu)
> 
>                 === g++ Summary ===
>  
> -# of expected passes           7891
> +# of expected passes           7899
>  # of unexpected failures       2
> -# of expected failures         92
> +# of expected failures         90
>  # of untested testcases        9
>  # of unsupported tests         3
>  
>                 === gcc Summary ===
>  
> -# of expected passes           20746
> +# of expected passes           20781
>  # of unexpected failures       6
>  # of expected failures         64
> -# of unsupported tests         73
> +# of unsupported tests         75
> 
>                 === libjava tests ===
> 
>  ...
>  WARNING: program timed out.
>  FAIL: SyncTest execution - gij test
>  WARNING: program timed out.
> +FAIL: SyncTest execution - bytecode->native test
> +WARNING: program timed out.
>  FAIL: SyncTest execution - gij test
>  FAIL: Thread_Alive execution - gij test
>  FAIL: Thread_Alive execution - gij test
>  ...
>  
>                 === libjava Summary ===
>  
> -# of expected passes           2772
> -# of unexpected failures       65
> +# of expected passes           2770
> +# of unexpected failures       66
>  # of expected failures         14
> -# of untested testcases        69
> +# of untested testcases        70

Re: basic-improvements call for testers

[Andreas Tobler]

Zack Weinberg wrote:

> Please test the branch and report results using test_summary, but also
> copy me; I don't follow gcc-testresults.


I get so far (below), but now I go for a sleep.

Andreas

stage1/xgcc -Bstage1/ 
-B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/ -c   -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common 
  -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. 
-I/Volumes/xufs/gcc-bib/gcc/gcc -I/Volumes/xufs/gcc-bib/gcc/gcc/. 
-I/Volumes/xufs/gcc-bib/gcc/gcc/config 
-I/Volumes/xufs/gcc-bib/gcc/gcc/../include 
/Volumes/xufs/gcc-bib/gcc/gcc/gengenrtl.c -o gengenrtl.o
stage1/xgcc -Bstage1/ 
-B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common 
  -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
  gengenrtl.o ../libiberty/libiberty.a
make[2]: *** [gengenrtl] Abort trap
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2

Re: basic-improvements call for testers

[Geoff Keating]

Andreas Tobler <toa@pop.agri.ch> writes:

> Zack Weinberg wrote:
> 
> > Please test the branch and report results using test_summary, but also
> > copy me; I don't follow gcc-testresults.
> 
> 
> I get so far (below), but now I go for a sleep.
> 
> Andreas
> 
> stage1/xgcc -Bstage1/
> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/ -c   -g -O2
> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE
> -I. -I. -I/Volumes/xufs/gcc-bib/gcc/gcc
> -I/Volumes/xufs/gcc-bib/gcc/gcc/. -I/Volumes/xufs/gcc-bib/gcc/gcc/config
> -I/Volumes/xufs/gcc-bib/gcc/gcc/../include
> /Volumes/xufs/gcc-bib/gcc/gcc/gengenrtl.c -o gengenrtl.o
> stage1/xgcc -Bstage1/
> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2
> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
>   gengenrtl.o ../libiberty/libiberty.a
> make[2]: *** [gengenrtl] Abort trap
> make[1]: *** [stage2_build] Error 2
> make: *** [bootstrap] Error 2

I now see exactly this on Darwin too, after the last merge into BIB.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements call for testers

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:
> Andreas Tobler <toa@pop.agri.ch> writes:
>> stage1/xgcc -Bstage1/
>> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2
>> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
>> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
>> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
>>   gengenrtl.o ../libiberty/libiberty.a
>> make[2]: *** [gengenrtl] Abort trap
>> make[1]: *** [stage2_build] Error 2
>> make: *** [bootstrap] Error 2
>
> I now see exactly this on Darwin too, after the last merge into BIB.

I don't have access to a Darwin machine.  Would you mind trying to
debug this a bit more?

zw

Re: basic-improvements call for testers

[Andreas Tobler]

Zack Weinberg wrote:

> I don't have access to a Darwin machine.  Would you mind trying to
> debug this a bit more?

Ok, now it's on the trunk. The same behaviour. As mentioned earlier very 
hard to debug.
Here a side note, don't know if related:

[titanium:reserved1/gcchfs/objdir] andreast% ./gcc/stage1/xgcc -v
Using built-in specs.
Configured with:
Thread model: posix
gcc version 3.4 20021216 (experimental)

Typing the above should usually give the specs/configured-with. In the 
gdb bt from earlier I see that the abort happens somewhere with do_spec1 
/ do_spec2.

Any ideas?

Thx,

Andreas

Re: basic-improvements call for testers

[Geoff Keating]

> Cc: Andreas Tobler <toa@pop.agri.ch>, gcc@gcc.gnu.org
> From: Zack Weinberg <zack@codesourcery.com>
> Date: Sun, 15 Dec 2002 15:09:12 -0800
> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)
> X-OriginalArrivalTime: 15 Dec 2002 23:08:47.0062 (UTC) FILETIME=[EBF21F60:01C2A48E]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> > Andreas Tobler <toa@pop.agri.ch> writes:
> >> stage1/xgcc -Bstage1/
> >> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2
> >> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> >> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> >> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
> >>   gengenrtl.o ../libiberty/libiberty.a
> >> make[2]: *** [gengenrtl] Abort trap
> >> make[1]: *** [stage2_build] Error 2
> >> make: *** [bootstrap] Error 2
> >
> > I now see exactly this on Darwin too, after the last merge into BIB.
> 
> I don't have access to a Darwin machine.  Would you mind trying to
> debug this a bit more?

It happens in the driver:

#0  0x9005d478 in abort ()
#1  0x00011bd8 in handle_braces (p=0x63bb4 "@:-o %f%u.out}%{!@:%{o*}%{!o:-o a.out}}     %{!Zdynamiclib:%{!A:%{!nostdlib:%{!nostartfiles:%S}}}}     %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G %L}}     %{!A:%{!nostdlib:%{!nostartfiles"...) at /Network/Servers/cauchy/homes/thorin/gkeating/co/basic-improvement/gcc/gcc/gcc.c:5703

I don't see anything wrong with the specs string at this point,
it looks like an example of the %{S:X} rule.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements call for testers

[Daniel Jacobowitz]

On Mon, Dec 16, 2002 at 11:45:22AM -0800, Geoff Keating wrote:
> > Cc: Andreas Tobler <toa@pop.agri.ch>, gcc@gcc.gnu.org
> > From: Zack Weinberg <zack@codesourcery.com>
> > Date: Sun, 15 Dec 2002 15:09:12 -0800
> > User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)
> > X-OriginalArrivalTime: 15 Dec 2002 23:08:47.0062 (UTC) FILETIME=[EBF21F60:01C2A48E]
> > 
> > Geoff Keating <geoffk@geoffk.org> writes:
> > > Andreas Tobler <toa@pop.agri.ch> writes:
> > >> stage1/xgcc -Bstage1/
> > >> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2
> > >> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> > >> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> > >> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
> > >>   gengenrtl.o ../libiberty/libiberty.a
> > >> make[2]: *** [gengenrtl] Abort trap
> > >> make[1]: *** [stage2_build] Error 2
> > >> make: *** [bootstrap] Error 2
> > >
> > > I now see exactly this on Darwin too, after the last merge into BIB.
> > 
> > I don't have access to a Darwin machine.  Would you mind trying to
> > debug this a bit more?
> 
> It happens in the driver:
> 
> #0  0x9005d478 in abort ()
> #1  0x00011bd8 in handle_braces (p=0x63bb4 "@:-o %f%u.out}%{!@:%{o*}%{!o:-o a.out}}     %{!Zdynamiclib:%{!A:%{!nostdlib:%{!nostartfiles:%S}}}}     %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G %L}}     %{!A:%{!nostdlib:%{!nostartfiles"...) at /Network/Servers/cauchy/homes/thorin/gkeating/co/basic-improvement/gcc/gcc/gcc.c:5703
> 
> I don't see anything wrong with the specs string at this point,
> it looks like an example of the %{S:X} rule.

@ isn't legal there according to the driver.  The test for the atom is:

      while (ISIDNUM(*p) || *p == '-' || *p == '+' || *p == '='
             || *p == ',' || *p == '.')
        p++;

If -@ is a valid option here that if statement should be extended to
include it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: basic-improvements call for testers

[Geoff Keating]

> Date: Mon, 16 Dec 2002 14:55:03 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> Cc: zack@codesourcery.com, toa@pop.agri.ch, gcc@gcc.gnu.org
> Mail-Followup-To: Geoff Keating <geoffk@geoffk.org>,
> 	zack@codesourcery.com, toa@pop.agri.ch, gcc@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.5.1i
> X-OriginalArrivalTime: 16 Dec 2002 19:54:18.0435 (UTC) FILETIME=[EB50B130:01C2A53C]
> 
> On Mon, Dec 16, 2002 at 11:45:22AM -0800, Geoff Keating wrote:
> > > Cc: Andreas Tobler <toa@pop.agri.ch>, gcc@gcc.gnu.org
> > > From: Zack Weinberg <zack@codesourcery.com>
> > > Date: Sun, 15 Dec 2002 15:09:12 -0800
> > > User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)
> > > X-OriginalArrivalTime: 15 Dec 2002 23:08:47.0062 (UTC) FILETIME=[EBF21F60:01C2A48E]
> > > 
> > > Geoff Keating <geoffk@geoffk.org> writes:
> > > > Andreas Tobler <toa@pop.agri.ch> writes:
> > > >> stage1/xgcc -Bstage1/
> > > >> -B/Volumes/reserved1/gcctmp/powerpc-apple-darwin6.2/bin/   -g -O2
> > > >> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> > > >> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> > > >> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
> > > >>   gengenrtl.o ../libiberty/libiberty.a
> > > >> make[2]: *** [gengenrtl] Abort trap
> > > >> make[1]: *** [stage2_build] Error 2
> > > >> make: *** [bootstrap] Error 2
> > > >
> > > > I now see exactly this on Darwin too, after the last merge into BIB.
> > > 
> > > I don't have access to a Darwin machine.  Would you mind trying to
> > > debug this a bit more?
> > 
> > It happens in the driver:
> > 
> > #0  0x9005d478 in abort ()
> > #1  0x00011bd8 in handle_braces (p=0x63bb4 "@:-o %f%u.out}%{!@:%{o*}%{!o:-o a.out}}     %{!Zdynamiclib:%{!A:%{!nostdlib:%{!nostartfiles:%S}}}}     %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G %L}}     %{!A:%{!nostdlib:%{!nostartfiles"...) at /Network/Servers/cauchy/homes/thorin/gkeating/co/basic-improvement/gcc/gcc/gcc.c:5703
> > 
> > I don't see anything wrong with the specs string at this point,
> > it looks like an example of the %{S:X} rule.
> 
> @ isn't legal there according to the driver.  The test for the atom is:
> 
>       while (ISIDNUM(*p) || *p == '-' || *p == '+' || *p == '='
>              || *p == ',' || *p == '.')
>         p++;
> 
> If -@ is a valid option here that if statement should be extended to
> include it.

-@ is certainly a valid option.  I think we also have -#.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements call for testers

[Andrew Pinski]

i686-unknown-openbsd3.1 results:

-<TITLE>Andrew Thomas Pinski - Results for 3.3 20021214 (experimental)  
testsuite on i686-unknown-openbs</TITLE>
+<TITLE>Andrew Thomas Pinski - Results for 3.4-bi 20021213  
(experimental) testsuite on i686-unknown-ope</TITLE>
-<pre>LAST_UPDATED: Sat Dec 14 09:01:14 UTC 2002
+<pre>LAST_UPDATED: Sat Dec 14 20:33:04 UTC 2002

  Native configuration is i686-unknown-openbsd3.1

@@ -66,17 +66,18 @@

  Running target unix
  FAIL: g++.dg/ext/instantiate2.C scan-assembler
+FAIL: g++.dg/parse/stack1.C (test for excess errors)
  FAIL: g++.dg/warn/Wunused-2.C  (test for warnings, line 5)
  FAIL: g++.law/profile1.C (test for excess errors)

                 === g++ Summary ===

-# of expected passes           7750
-# of unexpected failures       3
-# of expected failures         93
+# of expected passes           7757
+# of unexpected failures       4
+# of expected failures         91
  # of untested testcases                15
  # of unsupported tests         3
-/export/gates/pinskia/src/gnu/gcc/src/objdir.openbsd/gcc/testsuite/../ 
g++ version 3.3 20021214 (experimental)
+/export/gates/pinskia/src/gnu/gccbibtest/src/objdir.openbsd/gcc/ 
testsuite/../g++ version 3.4-bi 20021213 (experimental)

                 === g77 tests ===

@@ -86,7 +87,7 @@
                 === g77 Summary ===

  # of expected passes           1654
-/export/gates/pinskia/src/gnu/gcc/src/objdir.openbsd/gcc/testsuite/../ 
g77 version 3.3 20021214 (experimental)
+/export/gates/pinskia/src/gnu/gccbibtest/src/objdir.openbsd/gcc/ 
testsuite/../g77 version 3.4-bi 20021213 (experimental)

                 === gcc tests ===

@@ -122,11 +123,11 @@

                 === gcc Summary ===

-# of expected passes           20507
+# of expected passes           20542
  # of unexpected failures       25
  # of expected failures         63
-# of unsupported tests         77
-/export/gates/pinskia/src/gnu/gcc/src/objdir.openbsd/gcc/xgcc version  
3.3 20021214 (experimental)
+# of unsupported tests         79
+/export/gates/pinskia/src/gnu/gccbibtest/src/objdir.openbsd/gcc/xgcc  
version 3.4-bi 20021213 (experimental)

                 === objc tests ===

@@ -136,7 +137,7 @@
                 === objc Summary ===

  # of expected passes           1153
-/export/gates/pinskia/src/gnu/gcc/src/objdir.openbsd/gcc/xgcc version  
3.3 20021214 (experimental)
+/export/gates/pinskia/src/gnu/gccbibtest/src/objdir.openbsd/gcc/xgcc  
version 3.4-bi 20021213 (experimental)

                 === libstdc++-v3 tests ===

@@ -162,9 +163,9 @@
  # of expected failures         17
  # of unsupported tests         6

-Compiler version: 3.3 20021214 (experimental)
+Compiler version: 3.4-bi 20021213 (experimental)
  Platform: i686-unknown-openbsd3.1
-configure flags: --target=i686-unknown-openbsd3.1  
--host=i686-unknown-openbsd3.1 --build=i686-unknown-openbsd3.1  
--disable-nls --verbose --enable-cpp  
--prefix=/home/gates/pinskia/openbsd --enable-shared
+configure flags: --target=i686-unknown-openbsd3.1  
--host=i686-unknown-openbsd3.1 --build=i686-unknown-openbsd3.1  
--disable-nls --verbose --enable-cpp  
--prefix=/home/gates/pinskia/openbsdbibtest --enable-shared


g++.dg/parse/stack1.C: I think is caused by the stack size being only  
4M, so it looks great for i686-unknown-openbsd3.1 .

Re: basic-improvements call for testers

[Mark Mitchell]

--On Saturday, December 14, 2002 10:36:50 AM -0800 Zack Weinberg 
<zack@codesourcery.com> wrote:

> - For the time being, nothing goes onto mainline unless it is also
>   going onto the 3.3 release branch.  To make my life easier, please
>   test and apply such patches on the basic-improvements branch also.

Yes, let's do that.

Zack's creation of the BIB was a service to all of us; it allowed people
who were eager to press forward a place to put there code.  Zack is now
merging this branch back; let's make that as easy as possible.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

libjava testresults (Was: basic-improvements call for testers)

[Mark Wielaard]

Hi (java@gcc.gnu.org added to the CC),

On Sat, Dec 14, 2002 at 10:36:50AM -0800, Zack Weinberg wrote:
> 
> I have now committed a merge from trunk to the 3.4 basic-improvements
> branch.  My tests show only one significant difference between
> testsuite results on the mainline and the branch: that is an
> additional failure of the libjava testsuite.  As the libjava test
> suite is currently in bad shape with 65 unexpected failures on the
> mainline, I am not inclined to hold the merge over it.

That is strange. I tested both mainline and the 3.4-bi branch last night
and the results don't look that bad.

                === libjava tests ===
 
@@ -56,17 +50,15 @@
 FAIL: SyncTest execution - gij test
 WARNING: program timed out.
 FAIL: SyncTest execution - gij test
-FAIL: pr8823 execution - gij test
 FAIL: pr8823 compilation from bytecode
-FAIL: pr8823 execution - gij test
 FAIL: pr8823 -O compilation from bytecode
 
                === libjava Summary ===
 
-# of expected passes           2881
-# of unexpected failures       8
+# of expected passes           2885
+# of unexpected failures       6
 # of expected failures         14
-# of untested testcases        16
+# of untested testcases        14

-Compiler version: 3.3 20021215 (experimental) 
+Compiler version: 3.4-bi 20021213 (experimental) 

So on the branch I get 6 instead of 8 failures. Nice :)

This was on i686-pc-linux-gnu with:

Debian GNU/Linux testing/unstable
Linux 2.4.19-k7
binutils Version: 2.13.90.0.16-1
glibc Version: 2.3.1-5

Also my tests on powerpc on the mainline don't look that bad.
(Although there are some more failures there since on powerpc I include
the results of the Mauve testsuite.)

Could you take a look in the libjava.log file to see what actually goes
wrong on your setup?

Cheers,

Mark

Re: libjava testresults (Was: basic-improvements call for testers)

[Mark Wielaard]

On Mon, 2002-12-16 at 13:15, Mark Wielaard wrote:
> Hi (java@gcc.gnu.org added to the CC),
> [...]
> Also my tests on powerpc on the mainline don't look that bad.

But please note the posting from Jerry Quinn "3.4 bib failed to
bootstrap java on ppc" on the main gcc mailinglist:

        I just tried to build 3.4 bib last night on
        powerpc-unknown-gnu-linux
        and had the java bootstrap fail.
        
        stage1/xgcc -Bstage1/ -B/usr/local/powerpc-unknown-linux-gnu/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes  -fno-common  -DHAVE_CONFIG_H    -I. -Ijava -I../../gcc/gcc -I../../gcc/gcc/java -I../../gcc/gcc/config -I../../gcc/gcc/../include ../../gcc/gcc/java/jcf-write.c -o java/jcf-write.o
        ../../gcc/gcc/java/jcf-write.c: In function `init_jcf_state':
        ../../gcc/gcc/java/jcf-write.c:2853: internal compiler error: Segmentation fault

That probably means that my autobuilder on ppc which tests libgcj
against the Mauve testsuite will probably die as soon as the bib branch
is merged into mainline :(

If it helps I can setup that machine to run the 3.4-bi branch tonight.
But that might take a while (more then 10 hours) since it is a slow
machine and I will have to clear up some disk space for a new CVS tree.

Cheers,

Mark

Re: libjava testresults (Was: basic-improvements call for testers)

[Mark Wielaard]

Hi,

On Mon, 2002-12-16 at 17:26, Mark Wielaard wrote:
> On Mon, 2002-12-16 at 13:15, Mark Wielaard wrote:
> > Hi (java@gcc.gnu.org added to the CC),
> > [...]
> But please note the posting from Jerry Quinn "3.4 bib failed to
> bootstrap java on ppc" on the main gcc mailinglist:
> [...]
> That probably means that my autobuilder on ppc which tests libgcj
> against the Mauve testsuite will probably die as soon as the bib branch
> is merged into mainline :(

It wasn't that dramatic. The bib-branch was merged into mainline and the
testresults are still produced (and posted to gcc-testresults). I had
forgotten that it doesn't do a full bootstrap but only a simple make
using the isntalled gcc 2.95. The machine doesn't have enough diskspace
to do a full bootstrap for two gcc versions.

It seems that both the libjava and the mauve testsuite don't have any
regressions which is good news.

The machine is now doing a normal 3.3 branch build and testrun. When
that finishes I will setup the machine to do a full bootstrap of the
mainline and then of the 3.3 branch. I just have to make sure that there
is enough disk space which means that removing each build before
starting the new one. I will report the results when that is done. 

Cheers,

Mark

Re: libjava testresults (Was: basic-improvements call for testers)

[Mark Wielaard]

Hi,

On Tue, 2002-12-17 at 13:15, Mark Wielaard wrote:
> The machine is now doing a normal 3.3 branch build and testrun. When
> that finishes I will setup the machine to do a full bootstrap of the
> mainline and then of the 3.3 branch. I just have to make sure that there
> is enough disk space which means that removing each build before
> starting the new one. I will report the results when that is done. 

Bootstrapping on powerpc-unknown-linux-gnu with java enabled succeeded.
I did see three regressions:

FAIL: Thread_Interrupt output - gij test
FAIL: Thread_Interrupt output - gij test
FAIL: Thread_Interrupt -O output - bytecode->native test

But these look like timing issues.

The Mauve testsuite didn't run (FAIL: Compile DejaGNUTestHarness.java)
because there is a bug in the test script (it looks for the wrong
libgcj.jar file).

Running a bootstrap of the 3.3 branch now, but the real problems on
powerpc with libjava on mainline seem to have beeen solved.

Cheers,

Mark

Re: libjava testresults

[Zack Weinberg]

Mark Wielaard <mark@klomp.org> writes:

> Hi (java@gcc.gnu.org added to the CC),
>
> On Sat, Dec 14, 2002 at 10:36:50AM -0800, Zack Weinberg wrote:
>> 
>> I have now committed a merge from trunk to the 3.4 basic-improvements
>> branch.  My tests show only one significant difference between
>> testsuite results on the mainline and the branch: that is an
>> additional failure of the libjava testsuite.  As the libjava test
>> suite is currently in bad shape with 65 unexpected failures on the
>> mainline, I am not inclined to hold the merge over it.
>
> That is strange. I tested both mainline and the 3.4-bi branch last night
> and the results don't look that bad.

How odd.  Perhaps there is something locally glitched with my system,
but as I am using essentially the same one you are...

I was seeing a great deal of failures of the form

FAIL: ArrayStore execution - gij test
FAIL: ArrayStore execution - gij test
FAIL: ArrayStore2 execution - gij test
FAIL: ArrayStore2 execution - gij test

See http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00548.html and
http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00547.html for the
full list.

However, the rebuild I did on 2002-12-16 shows only

FAIL: PR1343 compilation from bytecode
FAIL: PR1343 -O compilation from bytecode
WARNING: program timed out.
FAIL: SyncTest execution - gij test
WARNING: program timed out.
FAIL: SyncTest execution - gij test
WARNING: program timed out.
FAIL: SyncTest -O execution - bytecode->native test
FAIL: pr8823 execution - gij test
FAIL: pr8823 compilation from bytecode
FAIL: pr8823 execution - gij test
FAIL: pr8823 -O compilation from bytecode

(the WARNINGs appear to be related to the FAILs immediately after
them).

I'll do another build overnight and see what I get.

zw

Re: libjava testresults

[Tom Tromey]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

Zack> However, the rebuild I did on 2002-12-16 shows only
Zack> [ ... ]

FYI, this list is the (currently) ordinary set of errors.

Tom