This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cleaning up the last g++ testsuite nit from 3.4
- From: "Kaveh R. Ghazi" <ghazi at caipclassic dot rutgers dot edu>
- To: gdr at integrable-solutions dot net, pinskia at physics dot uc dot edu
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 23 Dec 2005 13:09:06 -0500 (EST)
- Subject: Re: Cleaning up the last g++ testsuite nit from 3.4
- References: <200512231558.jBNFwOcf000915@caipclassic.rutgers.edu>
> The last diagnostic in 3.4.x I'm getting from g++ is this:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[ \\t]+_ZTIP9CTemplateIhE
> as shown here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html
>
> There are three xfails in the testcase, almost everybody passes the
> first two. But I can't be sure everyone does. I think I saw an hpux
> report where it only XPASSed one of the three.
>
> The testcase had the xfails removed later on, and Andrew referenced
> the testcase being fixed by some unnamed patch:
> http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00197.html
>
> I'd like to do something about this so I can get completely clean
> results. Either remove the first two xfails and risk someone still
> failing it, remove the testcase, or backport the patch that fixed it
> completely.
>
> But I can't figure out what patch fixed this to evaluate how hairy it
> is. Andrew do you remember?
Some more info, the reason hpux only showed one XPASS in 3.4 seems to
be that the regexp isn't correct to match the assembler syntax.
Patches were installed on mainline but not in 3.4 for mmix and hpux:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00323.html
The third xfail seems to have been fixed on or about July 29th 2004:
http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01290.html
http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01240.html
So it seems that if we backport the above patches and remove the first
two (passing) xfails we'd be result-clean. We could remove the third
(currently failing) xfail if we find and backport the patch that fixed
it.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu