Hi, On Friday, 30 September 2022 04:02:25 CEST Jacob Bachmeyer wrote: > Please keep me informed about the results of looking into those; if > this has actually exposed bugs in the GCC testsuite, I may add (as a > testsuite debugging aid) an option to run ${tool}-dg-prune in an > extra pass before analyzing the output. I am tentatively considering > a variable DG_PRUNE_EARLY_AND_OFTEN that could be set on the runtest > command line to arrange for this. I think this is actually a false positive when comparing, as it was an XFAIL turned into an XPASS (but, again, it was attempting to detect a note: that got pruned because pruning happened earlier). There's five relevant files, if you'd like to look yourself, in the gcc/testsuite directory inside the GCC tree: - c-c++-common/pr69543-3.c - g++.dg/other/error8.C - g++.dg/template/dtor7.C - g++.old-deja/g++.pt/overload7.C - gcc.dg/uninit-pr89230-1.c
> This is still the plan, although I must ask if you know of a reason > (other than inertia) not to continue aggregating results until the > very end of the dg-test procedure. I didn't mean to be very specific there, the very end is fine, too; at least, as far as I can tell. > My apologies for the delay: developing unit tests for dg.exp has > proven to be more involved than initially expected. (Starting with > writing a pure-Tcl VFS shim for the internal unit test support > infrastructure because a getdirs test in utils.test will fail if any > more subtrees are added to testsuite/runtest.libs. Why yes, I now > plan to eventually also make the other tests independent of the > actual filesystem now that I have had to write this shim.) No worries! That shim sounds quite neat. Thanks, -- Arsen Arsenović
signature.asc
Description: This is a digitally signed message part.