This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libgo] Improve Solaris 2/SPARC support
On Thu, 31 Mar 2011, Mike Stump wrote:
> On Mar 31, 2011, at 9:05 AM, Ian Lance Taylor wrote:
> > Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> >> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
> >> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
> >> go/48242). If I get around to it, I'll probably replace gotest by a
> >> dg-based testsuite.
> >
> > Argh, no, I am trying to fight against that as long as possible. We
> > should be moving away from DejaGNU, not toward it.
>
> The way forward is simple. Create a dejagnu replacement in python (or
> other suitable language), excise all tcl code in the testcases into
If you want a replacement in python, QMTest already exists. It only has a
little built-in support for running some sorts of DejaGnu testcases, but
that's a feature, not a bug; relying on bits of DejaGnu such as dg.exp
that are too closely involved in the details of compiler testing has
caused plenty of problems when we'd like to modify those bits as part of
enhancing the GCC testsuite; putting things such as dg test parsing and
GCC diagnostic parsing directly in the GCC testsuite code is probably
better than relying on the bits of support present in core QMTest (but you
can subclass those bits to the extent that they are useful).
> driver fragments in the driver area (testsuite/lib), and slowly expand
> it out from native only to cross to canadian cross and across test
> suites. An ambitious person could convert the whole thing en mass I
Note that it's possible to use a DejaGnu board file with another test
harness (via a special testsuite that waits for "compile" and "run"
commands and wrapper scripts, run by the other test harness, that send
those commands). You probably don't get parallelization that way (where
it would be possible with a native QMTest host class) but the real issue
is not existing board files (which you can use more or less as well as you
can use them at present), it's all the Tcl code in the existing
testsuites.
> we want to be either. By migrating to dejagnu, you at least condense
> down to one infrastructure, which is good. We put all our eggs into one
Yes. And migrating those testsuites that still use .x files instead of
dg.exp to use dg.exp would similarly be good.
--
Joseph S. Myers
joseph@codesourcery.com