This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.3-branch QA assessment
> From: Tom Tromey <tromey@redhat.com>
>
> >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
>
> Kaveh> As an aside, there are a number of regressions in the libgcj tests in
> Kaveh> sparc-sun-solaris2 with the 3.3 branch (same in 3.4 BTW.) See
> Kaveh> http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01128.html
>
> Kaveh> Some of these regressions also occur on other platforms, e.g. PR1343
> Kaveh> and pr8823 appear on x86-linux-gnu. Various other examples abound.
>
> PR1343 is a libtool problem. The libtool currently in cvs can't
> handle a file name with a `$' in it. This has been failing for a long
> time; nobody has the time and/or motivation to fix it.
I looked in the testcase libjava.compile/PR1343.java and don't see
anything obvious relating to a `$'. What file contains it? Is the
`$' related to what's being tested? If not, can we rename the
particular file to avoid containing that?
> pr8823 isn't really a regression. It is a new test, for something
> that never worked. I've been meaning to xfail for 3.3 but haven't
> found the time.
I could try. I looked at the libjava testsuite and saw several files
named *.xfail. They seem to contain directives as to what action is
expected to fail. I'm assuming that I need to put something in a new
file libjava.lang/pr8823.xfail to do the right thing for these
failures:
FAIL: pr8823 compilation from bytecode
FAIL: pr8823 -O compilation from bytecode
Would that be "xfail-byte"?
> Kaveh> Are (any of) these on your radar already in some fashion? Would you
> Kaveh> Tom like (or need) more info or assistance in reproducing these? (I
> Kaveh> haven't filed any PRs against these yet.)
>
> Thanks for the offer.
>
> I know for sparc that Jeff Sturm is looking into some of the problems;
> he sent email today saying he'd contacted you about them.
>
> One question is what threading model libgcj was built with. If it was
> `posix' then we have a problem; many of those thread tests should be
> working ok. (I thought we had updated the test suite to xfail those
> when threading was not on, but maybe I'm wrong or maybe there is a bug
> in the test suite. I never try that.)
Yes, I spoke with Jeff. AFAICT on solaris2 if no thread options is
specified, it picks up posix threads by default. See the various
solaris2 entries in config.gcc. I'm not sure if the default
determined in the gcc dir is passed along when configuring libgcj or
not. At Jeff's urging, just to be sure I tried --enable-threads and
still basically got the same failures here:
http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01078.html
The diffs from the previous link way above are basically that without
--enable-threads, some of the failing tests appear more than once.
I.e. TLtest, Thread_Join, Thread_Monitor and Thread_Wait_2 all appear
twice without --enable-threads and once with --enable-threads. I'm
not sure what that means.
> The `linking cxxtest' failure is probably a test suite bug. For this
> and other cases, the libjava.log output would be helpful.
I already zapped and restarted my 3.3 tests. I'll get you more info
tomorrow night.
> I think `FileHandleGcTest' test is just not reliable. Andrew and Hans
> know more about that. I haven't investigated SyncTest yet :-(
>
> If you have time and interest for java testing, I can tell you some
> other useful things to try. There are the Mauve and Jacks test suites
> (easy to try) and also some various applications we like to build
> (requires a bit more time).
> Tom
Sure, fire away. I'll try and find some time. But I'd really like to
clean up the basic tests first. :-)
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu