On Wed, Sep 13, 2006 at 12:44:56AM +0000, Joseph S. Myers wrote:
> On Tue, 12 Sep 2006, Eric Christopher wrote:
>
> > Joseph S. Myers wrote:
> > > On Tue, 12 Sep 2006, Eric Christopher wrote:
> > >
> > > > So, these are xfailed, but still produce quite a bit of noise on both
> > > > x86_64-darwin and x86_64-linux since they fail to produce a working
> > > > executable
> > > > and then xfail. Should we move them to skip or link only and xfail them.
> > > > With
> > > > link only they do manage to be quiet in the logs and we'll still notice
> > > > if
> > > > they start linking correctly and can move them to run then.
> > > >
> > > > thoughts? pre-approved? :)
> > >
> > > Add a means to XFAIL the link of an execute test, if such a means doesn't
> > > already exist in the testsuite infrastructure.
> >
> > As opposed to changing the test to a link, find a way to xfail at the link
> > stage instead of at the run stage?
>
> Yes. Some marking so that the compile/link is expected to fail (and so
> doesn't produce a WARNING) but if it succeeds (XPASS) then the execute
> test is run.
Eric, Do you mean that they're noisy because of the WARNINGs? I always
find warnings annoying, perhaps test_summary should filter them out.
A few things about XFAILs:
- The only way to XFAIL a run test is on the dg-do directive. If the
test also needs to specify a list of targets on which to run, that
must be moved to a dg-skip-if directive, where it can be negated by
using { ! { targets_to_run } }.
- dg-xfail-if only applies to the compile/assemble/link, not to the
execution. If the compile/assemble/link passes then it is reported
as an XPASS and the test is run. This is just what Joseph suggested
we need a way to do.
When playing with this I discovered something alarming. This test:
/* { dg-do run } */
/* { dg-xfail-if "link fails" { powerpc*-*-linux* } } */
extern int foo (void);
int
main ()
{
return foo ();
}
gets different output on powerpc64-linux depending on whether it's built
with -m32 or -m64:
elm3b145% /opt/gcc-nightly/trunk/bin/gcc -m32 linkfail.c
/tmp/ccY3gdwZ.o: In function `main':linkfail.c:(.text+0x14): undefined
reference to `foo'
collect2: ld returned 1 exit status
elm3b145% /opt/gcc-nightly/trunk/bin/gcc -m64 linkfail.c
/tmp/ccirb9Cu.o:(.text+0x14): undefined reference to `foo'
collect2: ld returned 1 exit status
Notice that for -m32, the message from the linker includes "In function
`main':"; this causes prune_gcc_output to remove that line of output,
which results in the failure not being recognized. I wonder how many
targets this affects, and how many link failures are not recognized
because of it.
Janis
