This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C identifier lookup speedups, 1/2
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Wed, 16 Apr 2003 15:05:19 +0100
- Subject: Re: C identifier lookup speedups, 1/2
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> David Edelsohn <dje at watson dot ibm dot com> writes:
>
> >>>>>> Zack Weinberg writes:
> >
> > Zack> Yes. It is supposed to be XFAILed. Please find out why
> > Zack> builtin-noret-2.x isn't doing its job.
> >
> > It is XFAILED, but XFAIL applies to a FAIL. Because of the link
> > error, the case is UNRESOLVED. XFAIL try to build and execute it, but
> > expect FAIL.
>
> But the link error *is* the expected failure mode, so the XFAIL
> marker is applied to the compile phase. This works for me; why is
> dejagnu giving you an UNRESOLVED?
>
The compile test is XFAILing (at least, that's the behaviour on ARM); but
because the test failed to compile, the execution test can't run. Hence
the UNRESOLVED -- we don't know if the test runs correctly, because we
can't build it. Of course, after an XFAIL during compile, it could be
argued that the result of the execution test should be XUNRESOLVED...
R.