> 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 [EMAIL PROTECTED]
