This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: testsuite execution question
On Mon, Feb 28, 2005 at 08:45:17PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 28, 2005 at 04:14:12PM -0800, Janis Johnson wrote:
> > > DejaGnu's definition of ${tool}_load has an optional argument for flags
> > > to pass to the test program, but none of the procedures in DejaGnu or in
> > > gcc/testsuite/* are set up to pass such flags. It would be fairly
> > > straightforward to provide a local version of gfortran_load to intercept
> > > calls to the global one, and have it add flags specified with a new test
> > > directive to the DejaGnu version of ${tool}_load. That directive could
> > > be something like:
> > >
> > > { dg-program-options options [{ target selector }] }
> > >
> > > Would something like this be useful for other languages as well, or is
> > > Fortran the only one in GCC that has support to process a program's
> > > command line?
> > >
> > > I'm willing to implement something like this if it looks worthwhile.
> >
> > It's supposed to be possible to drop in replacements to DejaGnu in the
> > GCC testsuite; do other test frameworks of interest handle passing
> > arguments to the test program in a way that could support this? (Sorry
> > for talking to myself here.)
>
> I don't think that's the concern here - it's more a matter of whether
> the target, and DejaGNU, support this. Lots of embedded targets seem
> to have trouble with it. Take a look at "noargs" in the DejaGNU board
> files for a couple of examples, IIRC. GDB jumps through some hoops to
> test this, and gets it wrong in a bunch of places too.
Is command line processing relevant for embedded targets? (I have no
idea.) Tests that pass options to the test program could be skipped
for embedded targets and for other kinds of testing where it isn't
reliable. The dg-program-options directive could warn when it's used
in an environment for which it's not supported.
Janis