3.3-branch QA assessment

Tom Tromey tromey@redhat.com
Sun Jan 26 09:09:00 GMT 2003


>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

Tom> PR1343 is a libtool problem.  The libtool currently in cvs can't
Tom> handle a file name with a `$' in it.  This has been failing for a long
Tom> time; nobody has the time and/or motivation to fix it.

Kaveh> I looked in the testcase libjava.compile/PR1343.java and don't see
Kaveh> anything obvious relating to a `$'.  What file contains it?  Is the
Kaveh> `$' related to what's being tested?  If not, can we rename the
Kaveh> particular file to avoid containing that?

In Java, a member class is given a name with a `$' in it.  This isn't
actually specified by the language, but we still need to do it for
compatibility.  I think changing this would be pretty hairy; we're
stuck with it.

Tom> pr8823 isn't really a regression.  It is a new test, for something
Tom> that never worked.  I've been meaning to xfail for 3.3 but haven't
Tom> found the time.

Kaveh> I could try.  I looked at the libjava testsuite and saw several files
Kaveh> named *.xfail.  They seem to contain directives as to what action is
Kaveh> expected to fail.  I'm assuming that I need to put something in a new
Kaveh> file libjava.lang/pr8823.xfail to do the right thing for these
Kaveh> failures:

Yes.

Kaveh> Would that be "xfail-byte"?

Yes.  Look in testsuite/lib/libjava.exp.  There is a comment before
`test_libjava' that explains what can go into the .xfail file.

Kaveh> Yes, I spoke with Jeff.  AFAICT on solaris2 if no thread
Kaveh> options is specified, it picks up posix threads by default.
Kaveh> See the various solaris2 entries in config.gcc.  I'm not sure
Kaveh> if the default determined in the gcc dir is passed along when
Kaveh> configuring libgcj or not.

libgcj's configure script uses the just-built gcc to figure out what
to do.  At least, when built natively; I'm not sure what happens for a
Canadian cross.

Kaveh> Sure, fire away.  I'll try and find some time.  But I'd really like to
Kaveh> clean up the basic tests first. :-)

I'll send more info later, probably Monday.

Tom



More information about the Gcc mailing list