On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: > > I executed the dg-extract-results.sh manually in the gcc/testsuite > > directory after a complete testsuite run which didn't give the correct > > results. Rev. 240429 gives the expected results, where rev 268511 fails. > > I'm on windows using msys2 with bash 4.4.23. > > > > I'm bootsrapping at the moment but that's really slow on windows. When > > the testsuite run is finished I try to assemble a reproducer. This will > > take a while. > > > > OK, thanks! Do you mean the problem happens on Windows only?
It is not on Windows only, I e.g. see the same problem on Linux too, unfortunately only when doing package builds. E.g. https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log In the ===TESTING=== section where it emits result of contrib/test_summary the results look reasonable (though, the ordering looks random-ish even when it is always LC_ALL=C, so if there are multiple FAILs, diffing them from one build to another has -FAIL and +FAIL lines for the same tests), but if you uudecode the file (with more recent uudecode one needs to extract the begin ... end part manually, what a progress :( ) in the tarball any *.log files changed with dg-extract-results.py contain just Running lines and no further details. Others like libgomp.log are complete, but those are not merged. I get those almost empty *.log files even after rm -f contrib/dg-extract-results.py (which should force the *.sh version). I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, the *.log files are complete there. And I have no idea if it was introduced with your change or earlier. Jakub
